[Bug 1229488] Re: 13.10 USB to USB Install on UEFI Secure Boot Machine Left Host Unbootable

[Ubfan]

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!

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to grub2 in Ubuntu.
https://bugs.launchpad.net/bugs/1229488

Title:
  13.10 USB to USB Install on UEFI Secure Boot Machine Left Host
  Unbootable

Status in “grub2” package in Ubuntu:
  New

Bug description:
  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 bootloader target was the UEB's EFI partition.  The USB
  installation boots successfully, but the laptop no longer boots from its
  hard disk, leaving you at the grub prompt.  The cause was the installation
  improperly changed the hard disk's grub.cfg

  Expected change to hard disk's /EFI/ubuntu/grub.cfg -- None.
  Actual change to hard disk's /EFI/ubuntu.grub.cfg -- The uuid in the
  "set root" just before the configfile command was reset from the hard
  disk to the (no longer present) target USB.

  Additionally, no NVRAM changes were expected from installing to a USB
  stick, but a new boot entry was created.  This boot entry was a correct
  (for secure boot) -- /EFI/ubuntu/shimx64.efi.  NVRAM is a finite
  resource, which when used up leaves your machine bricked, or relying on an
  untested vendor supplied reset, so any unnecessary additions are highly
  undesirable.

  Editing the hard disk's improper grub.cfg file by putting in the correct
  UUID allowed the laptop to boot successfully.  The EFI menu now has an
  additional ubuntu entry, which also boots successfully.  To summarize,
  creating or updating a USB installation should not change anything in
  NVRAM nor on the hard disk's EFI partition.  This 13.10 installation did both.
  (The update reference was to a 12.10 USB update, which changed the NVRAM
  shim boot entry's disk code and removed it from the boot order (no bug
  filed), so these issues are not new to 13.10.)

  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.  The original Ubuntu selection's path is
  actually grubx64.efi, which is incorrect for secure boot, but
  in /EFI/Boot is a copy of shim.efi named bootx64.efi and grubx64.efi, which must be a
  fallback, because the boot succeeds anyway. The original shim Ubuntu
  selection was improperly changed/removed from boot order and the EFI
  menu by a USB 12.10 update (and never added back since a working EFI choice
  existed).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1229488/+subscriptions