Mint UEFI partition suddenly not recognized by UEFI anymore - after booting Windows 7 once

Question

I am dealing with a PC, some off-the-shelve HP office box, a few years old. I had been using it for a while with different flavors or Linux mostly for computing stuff headless. At some point, I had to install Windows 7 x86_64, so I removed all previous hard drives from the machine, found another SSD, plugged it in, wiped it blank and installed Windows 7 (all defaults) on it. From what I can tell, it was installed in UEFI boot mode (i.e. the SSD has a small FAT32 partition with set boot flag).

Time goes by, I need to run Linux on this machine again, I plug out the SSD and install Linux Mint (i.e. Ubuntu), most recent version as of 2 weeks ago, onto a USB flash drive. The Mint installer throws error messages at me, telling me that there is another OS on this PC which runs as in legacy BIOS mode and installing Mint in UEFI mode is a bad idea. Remember, the SSD was plugged out. Ok ... I can not convince the Mint installer not to crash over this error message, so I partition my USB flash drive manually with GParted. 512 MByte FAT32 with BOOT flag set plus an ext4 system partition, GPT partition table. I run the Mint installer again and point it to those partitions. It throws another warning at me but does not crash. Mint installs (in UEFI mode) and works. Kernel and Grub updates work.

Time goes by, again, and I need Windows again. I still have my SSD around, so I plug it in. The USB flash drive is also present, I thought it would not matter ... I boot the PC, Windows works just fine, I shut it down. Well, now I want to start Mint. UEFI does not find it. Period. I unplugged the SSD. I tried every available USB port. I switched Secure Boot on (just for fun) and off again. I switched to BIOS boot only mode and back to UEFI / legacy combined. I switched to UEFI only mode. It just wont recognize Mint. Going through the boot menu of UEFI does not list the USB flash drive as an UEFI boot option, only as a Legacy BIOS option (I remember it was listed as an UEFI option when I installed Mint onto it).

The Mint UEFI boot partition is untouched, as far as I can tell (change dates match with the date of the last Grub update). The BOOT flag is set. There really is not anything wrong with it, as far as I can tell. My only "mistake" was booting Windows once while the USB flash drive containing Mint was plugged into the PC.

What can I do to debug and/or resolve this issue? What am I possibly overlooking?

---

EDIT (1): This is what gdisk tells me:

# gdisk -l /dev/sdc
GPT fdisk (gdisk) version 0.8.8

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdc: 30464000 sectors, 14.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): ***
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 30463966
Partitions will be aligned on 2048-sector boundaries
Total free space is 4029 sectors (2.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1050623   512.0 MiB   EF00  
   2         1050624        30461951   14.0 GiB    0700  

Code EF00 for partition 1 is irritating. Should not it be EE00?

---

Also posted in the Mint Forums.

Answer 1

My first guess would be that you've lost the NVRAM boot variable for Mint. Perhaps the firmware removed it when it noticed it refers to a disk/SSD that is no longer present in the system.

With UEFI, each operating system can write its own bootloader specification to the system's list of bootable things. The specification includes basically the GUID identifier of the EFI System Partition that contains the bootloader, and the pathname of the bootloader file. For Mint, the pathname would probably be something like \EFI\Mint\grubx64.efi since it uses an UEFI version of GRUB2.

The trick is that you can access these UEFI boot variables from within the OS... but only if that OS is booted in UEFI mode. When legacy boot mode is used, the UEFI run-time services necessary for accessing the boot variables will be disabled to make the system more closely match legacy systems.

For removable media, there is another UEFI convention: if there are no applicable UEFI boot variables, or the system is told to boot in UEFI mode from a disk it has never seen before, then the UEFI firmware looks for a partition with a FAT32 filesystem that would contain a file named \EFI\BOOT\BOOTx64.efi (for 64-bit x86 hardware; the ARM architectures have their own boot file names.)

So there's two ways you could fix this:

1.) Access the Mint disk using any operating system that is capable of understanding a GPT partition table and a FAT32 filesystem. Find the bootloader file (\EFI\Mint\grubx64.efi or similar) and copy it to \EFI\BOOT\BOOTx64.efi on the same disk. If the directory containing the original bootloader file contains anything that looks like configuration files, copy them too.

Now UEFI should recognize the disk as UEFI-bootable even if the NVRAM boot variables are gone. (This might prevent the problem from reoccurring if/when you have to swap SSDs again.)

2.) Boot the system in UEFI mode into any sort of live-Linux or rescue environment. Locate the boot filename, and use the efibootmgr command to re-write the the boot variable for Mint. The required command would be something like:

# efibootmgr -c -d /dev/sdX -l \\EFI\\Mint\\grubx64.efi -L "Linux Mint"

Replace /dev/sdX with the actual disk device name: efibootmgr will automatically look up the corresponding GUID. Note the doubled backslashes in Windows-style pathname: this is because backslash is a special escape character for the Linux shell. The last parameter is a label that may appear on boot selection menus and the like; you can write any short text you want.