EFI install to removable media not supported

[Ubfan]

Downloaded Sept. 20 daily build of 13.10, 64 bit, desktop ISO, md5sum
checked it, used "create startup disk" on 13.04 secure boot host to make
USB live media, rebooted from it, and successfully installed 13.10 to
another USB. Target USB had gpt partitioning, had an EFI partition set
up on it, and the user selected bootloader location was the USB's EFI partition. The USB installation does not boot (ESP is empty, bug 1173457) and the laptop no longer boots from its hard disk, leaving you at the grub prompt.

  The cause bootfailure was twofold:
1)The installation improperly changed the hard disk's grub.cfg (bug 1173457).
2)The NVRAM boot entry was improperly changed from shimx64.efi to grubx64.efi (this bug) which will not boot when secure boot is enabled.

No NVRAM changes or additions were expected from installing to a USB
stick. The existing NVRAM boot entry was correct for secure boot -- /EFI/ubuntu/shimx64.efi. The changed NVRAM was /EFI/ubuntu/grubx64.efi and
is incorrect for a secure boot, it doesn't work.

Additional notes: The shim entry which was changed to grub was not the default, Windows was the default boot entry.

Hardware: Toshiba Satellite S855-5378, Insydh20 firmware version 6.60,
8G memory, 750G hard disk, Intel HD4000 video, running dual boot W8 and
fully patched 64 bit 13.04 Ubuntu desktop with secure boot enabled. The only
secure boot issue with this machine is the inability to boot Windows
from grub (bug 1091464), so Windows is the default, and the EFI menu is used
to select Ubuntu to run shim/grub. In /EFI/Boot is a copy of shimx64.efi named bootx64.efi and a copy of grubx64.efi. This machine uses this as a
fallback, allowing Ubuntu to boot.

[Ubfan (ubfan1)]

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!

[oldfred (oldfred)]

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.

[Launchpad Janitor (janitor)]

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

[Shuhao (shuhao)]

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.

[oldfred (oldfred)]

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

[S0AndS0 (strangerthanbland)]

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.