EFI install to removable media not supported

This affects Ubuntu 14.04 64 bit also. Booting live media off USB2, installing to USB3 enclosure, resulted in an empty EFI partition on the target, and the new grub.cfg file copied to the host's internal EFI partition, leaving both target and host unbootable.
Same machine as above with secure boot disabled, target was a USB3 enclosure with a 256G SSD, partitioned with gdisk before the installation was attempted. The partitions were:
start 2048 4095 +1M grub-bios
efi 4096 614399 +300M boot
root1 614400 53043199 +25G
root2 53043200 105471999 +25G
Data 105472000 449404927 +163G
Not formatted before the installation. At installation, the grub-bios partition was unused (just present for future use), and while the efi partition was selected as efi, but the format button never became active, and the format checkoff never allowed a selection either. The root1 was selected for the /, and the bootloader device was selected as sdc (the target) BECAUSE THE SDC2 PARTITION was not even a choice (only sdc and sdc3 were choices). The installation finished normally, but had the following problems:
1) target's efi partition was left empty,
 2) host's efi files were updated, no problem for the .efi loaders, but the grub.cfg now used the hd2,gpt3 for the configfile command, which is not present after the target is removed.
 3)A NVRAM entry on the host was deleted. No changes at all were expected on the host, and while the removal of the shim boot entry did not cause any problems since I had a grubx64 entry also, this unwanted change is an error.
 4) The bootloader for a removable media like USB is not expected to have ANY nvram entry, and is expected to be in /EFI/Boot/bootx64.efi. A properly working install to USB should set up the shim or grubx64 that way.
    Easy enough to fix, copy the host's EFI files to the target (they were correct for the target after altering the disk number), and restore the host's grub.cfg file (I've learned to keep a copy around of the good file). Or use boot-repair I guess, since there are now 214 pages of forum activity there.
  Creating portable Ubuntu systems on USBs should never leave the UEFI host unbootable!

I have same issue with 17.04 full install to flash drive.
It overwrites my main working install's /EFI/ubuntu on sda.

If I then remove flash drive system is unbootable.

Status changed to 'Confirmed' because the bug affects multiple users.

So I made an attempt today to install and was more or less successful. The workarounds I had to do are detailed as follows:

1. Create a EFI (FAT32, 300MB) and root file system (ext4/btrfs, the rest of the drive) manually on the removable media.
2. Create a back up of the host system's EFI partition, with just a simple copy.
3. Install the system with the own partition layout. Set use EFI on the removable (although nothing will be done due to this bug and #1173457) and set the rootfs mount point on the removable.
4. Finish installation. Do not restart.
5. Copy the EFI directory in /dev/sda1 to /dev/sdX1 (the EFI partition you created). Possibly make another backup copy as well.
6. Make a directory on the removable's EFI partition called BOOT.
7. Copy over grubx64.efi and shimx64.efi from /mnt/removable-efi-partition/EFI/ubuntu* to /mnt/removable-efi-partition/EFI/BOOT, create the BOOT directory if not exists.
8. Rename shimx64.efi to BOOTX64.EFI if secure boot is enabled, otherwise I think you can just rename grubx64.efi to BOOTX64.EFI, although I'm not sure as I only tested with secure boot thus far.
9. Mount the root fs from the removable media, change /etc/fstab to disable the swapfile (somehow prevented boot on my system if enabled).
10. Use blkid to find out the UUID of /dev/sdX1 (the EFI partition on the removable).
11. In /etc/fstab again, the /boot/efi mount entry should have the UUID of the one above (i believe it by default filled the uuid from whatever /dev/sda1 is).
12. Copy the original backed up EFI partition back to the EFI partition on the internal hard drive.

One thing to note that may be confusing: ubuntu mounts the efi partition in /boot/efi. The partition itself should have a folder called EFI (/boot/efi/EFI), and the BOOT/ubuntu directories are contained under that folder (/boot/efi/EFI/BOOT). Don't just copy BOOT/ubuntu directly into the partition, the system won't boot. The some of the path fragments are the same, which could make this confusing.

*don't take this path literally, you need to mount that partition yourself.

Same issue as posted in #3 with new 18.04.

Install to flash drive, does not use ESP on flash drive, but installs to ESP on sda. Then system is not bootable without flash drive as it has overwritten my default boot on sda from /EFI/ubuntu.

I also have changed GRUB_DISTRIBUTOR as defined in /etc/default/grub to have unique UEFI and grub menu entries for my internal drive system.
Even though grub-install creates new /EFI/bionic_18_04 folder and entry in UEFI. And EFI folder had correct grub.cfg, the system only booted from grub.cfg in /EFI/ubuntu,
Or something in grubx64.efi is hard coded to only boot from /EFI/ubuntu/grub.cfg.

Better to fix grub not use use hard coded efi_distributor as ubuntu and fix kluge of kubuntu name change.

./debian/patches/install_efi_ubuntu_flavours.patch:Subject: Cope with Kubuntu setting GRUB_DISTRIBUTOR
./debian/patches/install_efi_ubuntu_flavours.patch:we probably need to split GRUB_DISTRIBUTOR into a couple of different

This bug also effects Mint 18, removing the USB that Linux was installed to causes host to drop into grub prompt at boot time!

Thankfully typing `exit` will cause system to boot to OS on host's internal drive... for now...

However, attempting to install Linux to a second USB has resulted in no-joy.

___

General steps used to install Linux to USB;

- Make installer USB (sdb) from ISO
- Reboot Win10 while holding shift
  - Select boot from USB
- While booting press [Esc] key
  - Then select compatibility mode from boot menu
- Once booted into Live session disable screen-saver, and other display blanking stuff
  - Use GParted to format second USB (sdc) that'll be targeted for installation
  - Use installer application to install to second USB
    - Select something else option
    - Select second USB (sdc) for installing boot stuff and OS to

I've tried this both with and without internet enabled on the installer Live USB (sdb), and though everything selected within the installer's options where targeting the other USB for installation (sdc), for some reason the internal host's drive was touched (sda)... in a very bad way!

What's really funky is that attempting to install onto a second USB (with the intention to replace the previously used media), causes the system to boot into grub shell too... for some reason the host is only happy when the USB from first install attempts is plugged in; without it or with only the other installed to USB plugged in I'm greeted with a grub prompt.

___

So far the best advice that I've seen is from a relatively recent guide on the subject...

https://forums.linuxmint.com/viewtopic.php?t=287353

... that mentions either removing the host's internal drive (sda), or removing various flags, or (probably the easiest) using Virtual Box to load up the installer ISO so that it never sees the host's internal drive(s).

___

If anyone's has gone through this and figured out how to un-bork the host's boot records I'd certainly appreciate some tips, because I don't relish the idea of re-installing Win10 just to get things booting without a specific USB plugged-in.

Additionally if someone would be so kind as to point me to the repo for the Installer application, I'd be happy to poke around a bit and experiment a little with getting it to do as it's told... at the very least it would be nice to have the installer pop a warning that states sda was detected and not chosen, but will be touched anyways, perhaps with some kind of message that tells users to figure out how to remove the drive or use VBox.