1

I have two SSD disks with Ubuntu 14.04.02 on both. They don't share the UUID or anything, and they are never plugged at the same time. This is a new disk I got last month and did a fresh install.

Here's what happen:

  1. Plug only disk 1, everything works fine. I can boot and no errors occur

  2. Unplug disk 1, plug disk 2 and I can boot this system too

  3. Unplug disk 2, plug disk 1, now disk 1 can't boot anymore. Depending on what boot entry (from the motherboard) I choose I get a "can't find such device", "grub rescue" or "insert media" error. I tried booting using the (U?)EFI option and it also doesn't work. It's not a boot priority problem, it just stops working.

After I run boot-repair on disk 1 it starts working again.

My motherboard is a http://www.asus.com/Motherboards/P8P67_LE/ and there's also no "Fast boot" option on the bios.

It's like it's caching the entries with the UUID or something. I also have two options stuck on the BIOS menu. They are from previous installs like "Ubuntu" and "Windows Bootloader". They show up even when no disks are plugged in.

1 Answer 1

2

EFI boot entries are stored in the computer's NVRAM. These entries refer to boot loaders, which are ordinary files stored on the hard disk's EFI System Partition (ESP). In order to uniquely identify these files, the NVRAM entries refer to the partitions on which the files reside by their GUID values, which are unique. Thus, the boot loader entries for your two installations are different and are not interchangeable.

The trouble is that some EFIs "helpfully" remove entries that they consider invalid. When the computer boots and can't find an entry, it's deemed invalid, and the firmware removes it. Thus, the moment you booted with your first disk unplugged, you lost its entry.

This damage is easily undone if you know how, but it's a hassle to fix, especially if you have cause to swap disks a lot. The best solution is to not swap disks on a regular basis. If you must, prepare a CD-R or USB flash drive with my rEFInd boot manager. When you need to boot from a disk whose boot loader entries are lost, use the rEFInd disk to boot Linux. You can then re-create the lost boot loader entry with efibootmgr, as in:

sudo efibootmgr -c -l \\EFI\\ubuntu\\grubx64.efi -L "ubuntu"

You might need more or different options, depending on how you partitioned the disk, whether you're booting with Secure Boot active, and perhaps other factors.

Another solution, which might or might not work depending on details of your configuration, is to copy your /boot/efi/EFI/ubuntu directory to /boot/efi/EFI/BOOT and rename the grubx64.efi or shimx64.efi file to bootx64.efi. The EFI/BOOT/bootx64.efi file on the ESP is the fallback boot loader -- it boots if nothing else can. Thus, copying GRUB (or Shim if you're using Secure boot) to that name may make it run automatically when its normal boot entry is lost. This workaround doesn't work on all systems, though.

2
  • Besides having to restore a /boot backup or maybe running boot-repair, do you think it's safe to remove entries from /boot/efi or using efibootmgr? I mean, can I do more damage than that by editing the entries? I plan to erase all the old entries that are on both disks, for some reason, like /boot/efi/Microsoft. Thanks again! Mar 10, 2015 at 12:58
  • The ESP (which is mounted at /boot/efi by default in Ubuntu) holds EFI boot loaders. If you delete files from there, it's entirely possible that a working OS will fail to boot. I don't recommend deleting such files unless you know what you're doing. Playing with efibootmgr can have the same effect, but a mistake with it is more easily recovered, since you can't lose a whole file by a mistake with efibootmgr; you can just lose the pointers to a file.
    – Rod Smith
    Mar 10, 2015 at 13:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .