UEFI Boot entry is lost after PBA authentication (with solution)

[juliandroid]

My setup is as follows:
Asus latop with "Aptio Setup Utility" by "American Megatrends, Inc.", version 2.15.1236
On the SSD I have installed UEFI64 PBA.

When I start the machine for the first time, the SSD loads the UEFI64, then I enter the passwords and the machine is rebooted again which leads directly to the BIOS settings, instead of booting my Linux.

Upon inspection of the Boot settings I see that I have only one Boot option left:
"Windows Boot Manager (P4: Samsung SSD 850 PRO)", while the other option ("Antergos" arch linux) is gone! This "Windows Boot Manager" is quite misleading, since I don't really have Windows OS installed. Basically, the "Antergos" boot entry vanishes after the PBA authentication.

Previously, I have noticed that if I remove the hard drive, then upon BIOS boot, this particular EFI entry is automatically removed! Later if I reintroduce the removed disk, unfortunately the BIOS won't reinstate the removed Boot entry!

Originally, the way this entry is added, is by using "grub-install", which in return calls the efibootmgr. This is the same tools used by the OS setup process. The grub setup creates the following EFI entry:
/boot/efi/EFI/antergos/grubx64.efi

The OS install setup is more generous and it actually creates a couple more "alias" like:
/boot/efi/EFI/BOOT/BOOTX64.efi/grubx64.efi
and
/boot/efi/EFI/Microsoft/Boot/bootmgfw.efi

I didn't realize at first what is all this for, but now I guess this is just a "hack", depending of your (broken) UEFI BIOS implementation, so your BIOS can find and boot at least one of those efi-s.

All this works just fine, but only with regular SSD (without Opal SED enabled mode).

One explanation could be:
Once the machine is started, UEFI Bios boots the UEFI64 PBA, by reading EFI\boot\bootx64.efi
unfortunately after the reboot the PBA hard drive "disappear" and the "real" drive comes in to play. Since the PBA hard drive is "gone" and my BIOS likes to remove boot entries for the missing devices, that cause the BIOS to open the setup instead.

Now, to boot I have to go to the "Boot" tab and create manually a boot entry (you can browse for the .efi file on the detected partitions in my BIOS setup), Save and reboot again in order to boot the Linux at last.
Sadly, I have to do that every time I shutdown the PC (between reboots the BIOS doesn't forget the boot entry).

My first attempt to solve that problem was to create exactly the same path as you did for the UEFI64 PBA boot efi, i.e. to create on my linux: /boot/efi/EFI/boot/bootx64.efi in hope that path is somewhat magical to the BIOS, but I had no luck. The BIOS removes the boot entry immediately after the initial boot (from power off state). I guess the reason is that the hard drive "signature" is different (different size, count of partitions, UUID, or something else, between shadow and real ssd partitions).

Lucky for me I found the magic path for my BIOS and it was hinted by this "Windows Boot Manager" that always comes from thin air when I reboot after the PBA authentication.
What I did is actually to remove all directories from /boot/efi/EFI and keep just one .efi file under the path:
/boot/efi/EFI/Microsoft/Boot/bootmgfw.efi
For some reason it should be that file and then the BIOS will accept it as fallback (rationale: added support for Windows OS with UEFI).
This workaround should work, but it is (BIOS) implementation specific and I imagine this won't be universal solution. Besides grub creates .efi file by default under its own path and BIOS doesn't behave!

I guess tickets like this one will keep coming once the SED utility become better adopted. I.e. people with UEFI to not be able to boot their drive after the PBA authentication.

One suggestion might be to integrate the efibootmgr tool and use it with "boot" parameters, specified on the sedutil-cli --loadPBAimage line, after successful authentication.
So, the user should know the required arguments for the efibootmgr to create a boot entry. Once those arguments are stored inside the UEFI64 image and saved on the PBA partition then that information can be later used, before or after the user successfully enteres their password and thus the (re)boot process will succeed no matter how stupid the UEFI BIOS is.

[r0m30]

Hi, sorry it took so long to get back to you I was out of town.
One thing you might try is to mount the UEFI image and move the PBA to the same path as your Arch install. Something like this (untested):
mkdir $MOUNTPOINT/boot/efi/EFI/antergos
mv $MOUNTPOINT/EFI/boot/* $MOUNTPOINT/boot/efi/EFI/antergos/
mv $MOUNTPOINT/boot/efi/EFI/antergos/bootx64.efi $MOUNTPOINT/boot/efi/EFI/antergos/grubx64.efi

Then unmount the image and reload it using loadPBAimage.

The BIOS should find /boot/efi/EFI/antergos/grubx64.efi no matter if the drive is unlocked or shadowed and shouldn't delete the boot entry.

[juliandroid]

I didn't have a chance to test this, so I have no idea whether your suggestion is working.

[Venemo]

@r0m30 I'm also affected by this issue. Your suggestion to have the same path for the EFI boot entry didn't work.

I have a similarly dumb system as @juliandroid ― but I have an Asus Zenbook UX31A and I use Fedora.
Fedora has \EFI\BOOT\BOOTX64.efi on /dev/sda1 and the PBA has the same path.

Here's what happens:
After a shutdown, the machine forgets the boot entry for Fedora. I can manually add a boot entry, and then the PBA boots. After that the machine forgets the boot entry again, and it no longer lets me add it manually. However after this if I boot from USB and then reboot again it now lets me add the boot entry and can boot Fedora.

So it seems to me that certain BIOSes are just too buggy...

[Venemo]

According to the BIOS the drive has a different signature when it is locked and unlocked, and I think that's why it forgets the previous EFI boot entries.

[Venemo]

Modifying both the PBA and the unlocked EFI partition so that they both contain a /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi fixed it for me ― looks like the Asus firmware always checks whether this magic filename exists and can boot to it if it does.

[r0m30]

I think all the vendors will probably look for the Windows boot manager, if they fail to boot Windows then they won't sell many units.
A note on the file structure, the path @Venemo uses '/boot/efi' is the mount point and '/EFI/Microsoft/Boot/bootmgfw.efi' is the path on the ESP partition.

[cristim]

If this is such a standard path, I guess we could also use it in the PBA image, by having a copy of BOOTX64.efi available there as well.

[r0m30]

Yes, it's really a shame the ESP is a fat filesystem. A few simple symlinks could fix a host of boot issues.

[Venemo]

@r0m30 Is there a space constraint on the PBA? Couldn't you just add the same file under the path /EFI/Microsoft/Boot/bootmgfw.efi?

[r0m30]

The current PBA is 35mb, the max size is 128mb, so we could add a fake windows boot manager. I'm not certain that would be the end of the "fixes" though.

[mesiu84]

I have exactly the same problem, Windows 10 and Ubuntu installed on nvme, after enabling opal and executing password laptop reboots into Windows, to login into Ubuntu Linux I have to restart from Windows 10, and then by pressing F12 select ubuntu from UEFI list. Ubuntu is not visable on UEFI list until I do that reboot from Windows.

Here is my solution:
Login into Linux and run following commands as root

1. cd /boot/efi/EFI
2. mv Microsoft MS
3. mkdir -p Microsoft/Boot
4. cd Microsoft/Boot
5. cp -RpH /boot/efi/EFI/ubuntu/* .
6. cp shimx64.efi bootmgfw.efi # this is the file used by ubuntu to startup
7. vim /etc/grub.d/40_custom # add the modified Windows section from /boot/grub/grub.cfg at the end of file, in my situation it is:

menuentry 'Windows Boot Manager (on /dev/nvme0n1p2)' --class windows --class os $menuentry_id_option 'osprober-efi-3690-FC37' {
insmod part_gpt
insmod fat
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root 3690-FC37
else
search --no-floppy --fs-uuid --set=root 3690-FC37
fi
chainloader /EFI/MS/Boot/bootmgfw.efi
}

please notice that I changed the chainloader to new path /EFI/MS instead /EFI/Microsoft

You need to add this section because when running update-grub Windows will be no longer detected, probably some changes need to be done in /etc/grub.d/30_os-prober but I didn't have time for it.

Now all you need to do is run update-grub and check if all is working. For me after Opal is unlocked system reboots and I see grub with Ubuntu and Windows on the list, and both are working.

If you ever turn Opal off you just need to replace /boot/efi/EFI/Microsoft with /boot/efi/EFI/MS and clean /etc/grub.d/40_custom file and of course run update-grub once again.

Update 2017.10.27

I was trying to install Windows 10 1709 update. It looks like during some big updates it is required to restore old /boot/efi/EFI/Microsoft because without it you will see an error during installation of updates. After the update is installed you can again update EFI.

[drvolpe]

Modifying both the PBA and the unlocked EFI partition so that they both contain a /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi fixed it for me ― looks like the Asus firmware always checks whether this magic filename exists and can boot to it if it does.

I've an ASUS UX32VD (should have the same motherboard as yours, @Venemo ) and the same issue. Can you please explain how you make it work? Thanks!

[Venemo]

@volpegit I just did what the other people in this thread said. But if you can't get it to work I can tell you more in detail.

[drvolpe]

@Venemo That would be very appreciated! Thanks for helping :)

[Venemo]

@volpegit

So basically the magic location is /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi which is always found by the ASUS motherboard. So you have to make sure that in both the PBA and your OS, the boot loader is located in this location.

On Fedora, this means:

cp -r /boot/efi/EFI/fedora /boot/efi/EFI/Microsoft/Boot
cp /boot/efi/EFI/Microsoft/Boot/grubx64.efi /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi

I also changed the PBA to have a copy of its bootloader at that path. How exactly I did this, I don't remember exactly anymore, it was almost a year ago and I haven't touched it since. What I remember is there were some documentation on how to modify the PBA or build a custom PBA. Basically the only thing you need to customize is to add a copy of the bootloader to the given location. Once you did that you can set it up the same way as the guide here says.

[nuku97]

@r0m30 can you please tell me how to mount the UEFI image in order to do the changes you suggested? I really would like to try your suggestion. Thanks!

Running "mount UEFI64.img /mnt/test" outputs the following errors for me:

NTFS signature is missing.
Failed to mount '/dev/loop0': Das Argument ist ungültig
The device '/dev/loop0' doesn't seem to have a valid NTFS.
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?

I also tried mount -t msdos and -t vfat, but it didn't help neither.

Hi, sorry it took so long to get back to you I was out of town.
One thing you might try is to mount the UEFI image and move the PBA to the same path as your Arch install. Something like this (untested):
mkdir $MOUNTPOINT/boot/efi/EFI/antergos
mv $MOUNTPOINT/EFI/boot/* $MOUNTPOINT/boot/efi/EFI/antergos/
mv $MOUNTPOINT/boot/efi/EFI/antergos/bootx64.efi $MOUNTPOINT/boot/efi/EFI/antergos/grubx64.efi

Then unmount the image and reload it using loadPBAimage.

The BIOS should find /boot/efi/EFI/antergos/grubx64.efi no matter if the drive is unlocked or shadowed and shouldn't delete the boot entry.

[r0m30]

This is from the build script.....
The losetup command will show you the loop device i.e. $LOOPDEV
$BUILDIMG is the PBA in uncompressed format

mkdir image
sudo losetup --show -f -o 1048576 ${BUILDIMG}`
sudo mount $LOOPDEV image
sudo chmod 777 image

[nuku97]

Thank you @r0m30 for the mount information and excuse my late reply. I have the same situation as the original issue poster (Dual-boot Windows & Linux; after PBA all UEFI entries are lost and system boots /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi), using an MSI B450 Mortar Max mainboard.

With your instructions I was able to mount the UEFI image, modify it as you suggested in your first comment (Renamed the "boot" folder to "gentoo" and renamed the file "bootx64.efi" to "grubx64.efi" in order to match Gentoo's GRUB location /boot/efi/EFI/gentoo/grubx64.efi) and transferred it with sedutil to the disk.

Unfortunatly, this did not help. This way my Mainboard was not able to boot the PBA image from the locked disk. Also the "gentoo" UEFI entries disappeared again.

Seems I have to stick to the workaround of replacing /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi with Gentoo's grubx64.efi for now.

Unfortunatly, as others have noted, the last big Windows update overwrote the file /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi and I had to replace it again with grub. While I can live with this workaround, it is still bothersome. Hope one day someone will come up with a permanent solution.

[pedrib]

@volpegit

So basically the magic location is /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi which is always found by the ASUS motherboard. So you have to make sure that in both the PBA and your OS, the boot loader is located in this location.

On Fedora, this means:

cp -r /boot/efi/EFI/fedora /boot/efi/EFI/Microsoft/Boot
cp /boot/efi/EFI/Microsoft/Boot/grubx64.efi /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi

I also changed the PBA to have a copy of its bootloader at that path. How exactly I did this, I don't remember exactly anymore, it was almost a year ago and I haven't touched it since. What I remember is there were some documentation on how to modify the PBA or build a custom PBA. Basically the only thing you need to customize is to add a copy of the bootloader to the given location. Once you did that you can set it up the same way as the guide here says.

Confirmed this as a workaround in my laptop computer with Debian.

After booting the PBA, unlocking the drives, the EFI boot manager entries are wiped out. If I do the rename trick above, the BIOS will find the "Microsoft" boot image and boot into Linux.

Unfortunately seems quite a common problem. Not a problem for me as I don't have Windows installed!

[jcul]

I had this issue on my framework laptop, with Samsung 980 Pro running arch Linux.
All I did was add the --removable option to grub_install, which causes grub to install to EFI/BOOT/BOOTX64.EFI.
All worked fine then.

See: https://wiki.archlinux.org/title/GRUB#UEFI_systems

[stuckj]

I know this is an old topic. But, I ran into this recently as well. I figured I'd provide a script for those who are confused about how to modify the PBA image. Ultimately, this didn't fix the issue for me (the boot order STILL changed after entering the password), but perhaps it will work for some people's UEFI firmware.

You have to run this as root. This moves everything from /EFI/boot to the path you specify (based on your installed Linux flavor) and renames bootx64.efi to whatever you specify as the EFI executable for your Linux flavor. E.g., to /EFI/ubuntu/shimx64.efi for Ubuntu. It will also (optionally) put in a fake Windows entry. You can try ordering your Linux boot first from the PBA, put in your password, and see if your UEFI firmware is smarter than mine and keeps the order. Mine likely doesn't 'cause the PBA partition looks like a different drive from the unencrypted disk data to the firmware.

I'll have to try the hack @mesiu84 suggested and deal with the Windows update issues if they happen again.

#!/bin/bash

set -euo pipefail

function help() {
  echo
  echo "Usage $(basename ${0}) <options>"
  echo
  echo "  -p,--pbaImg - The pre-boot authorization image (uncompressed!) to patch."
  echo
  echo "  -m,--mntPoint - The mount point where the PBA image will be temporarily mounted."
  echo
  echo "  -l,--linuxPath - The path (and filename) of your linux EFI boot executable from"
  echo "                   your ESP partition. E.g., /EFI/ubuntu/shimx64.efi for Ubuntu."
  echo
  echo "  [-w,--winHack] - If present, this will copy the PBA bootx64.efi file to"
  echo "                   /EFI/Microsoft/Boot/bootmgfw.efi to trick the BIOS into thinking"
  echo "                   it's a Windows boot entry."
  echo "                   NOTE: You can't boot from this entry."
  echo
  echo "  NOTE: This must be run as root."
  echo
}

ARGS=$(getopt --options 'p:m:l:w' --longoptions 'pbaImg:,mntPoint:,linuxPath:,winHack' -- "${@}") || ( help; exit 1 )
eval "set -- ${ARGS}"

while true; do
  case "${1}" in
    (-p | --pbaImg)
      PBA_IMG="${2}"
      shift 2
    ;;
    (-m | --mntPoint)
      MNT_POINT="${2}"
      shift 2
    ;;
    (-l | --linuxPath)
      LINUX_PATH="${2}"
      shift 2
    ;;
    (-w | --winHack)
      WINHACK=true
      shift
    ;;
    (*)
      break
    ;;
  esac
done

if [[ -z "${PBA_IMG-}" ]] || [[ -z "${MNT_POINT-}" ]] || [[ -z "${LINUX_PATH-}" ]]; then
  help
  exit 1
fi

LINUX_EFI_DIR="$(dirname "${LINUX_PATH}")"

mkdir -p "${MNT_POINT}"
LOOPDEV=$(losetup --show -f -o 1048576 "${PBA_IMG}")
mount ${LOOPDEV} "${MNT_POINT}"
#mkdir -p "$(dirname "${MNT_POINT}${LINUX_PATH}")"
#cp "${MNT_POINT}/EFI/boot/bootx64.efi" "${MNT_POINT}${LINUX_PATH}"
mv "${MNT_POINT}/EFI/boot" "${MNT_POINT}${LINUX_EFI_DIR}"
mv "${MNT_POINT}${LINUX_EFI_DIR}/bootx64.efi" "${MNT_POINT}${LINUX_PATH}"

if [ -n "${WINHACK-}" ]; then
  mkdir -p "${MNT_POINT}/EFI/Microsoft/Boot"
  cp "${MNT_POINT}${LINUX_PATH}" "${MNT_POINT}/EFI/Microsoft/Boot/bootmgfw.efi"
fi

umount "${MNT_POINT}"
losetup -d ${LOOPDEV}

[stuckj]

Note, I had one problem with @mesiu84's solution above. Hibernation stopped working in Windows. I think it relies on the BCD entries in the Microsoft entry of the EFI partition (or, something in there). I didn't have the problem he had with the ubuntu option not showing up, so I did a slightly modified solution that let hibernation continue to work in Windows:

Rename /EFI/Microsoft/Boot/bootmgfw.efi to /EFI/Microsoft/Boot/bootmgfw.efi.bak. Then, assuming you have a custom grub entry to boot windows in /etc/grub.d/40_custom, edit the entry and change /EFI/Microsoft/Boot/bootmgfw.efi to /EFI/Microsoft/Boot/bootmgfw.efi.bak. Grub doesn't care that the extension isn't .efi and renaming it to .bak prevents the UEFI firmware from picking up the MS boot entry. So, my computer now only sees ubuntu after unlocking the SED and boots to grub where I can boot to either ubuntu or Windows.

[asfernandes]

@stuckj how to make update grub looks for this renamed windows efi?

[asfernandes]

I Figured it out based in what os-prober was adding.

[stuckj]

Yeah, I neglected to put those details in my previous comment. I ran grub update with osprobe enabled before renaming the windows efi file. Then copied the autogenerated entry to the custom section as I mentioned in the comment (with the renamed filename). Then disabled osprobe, renamed the windows efi file and re-ran grub update. That removes the autogenerated entry and creates an entry with the custom entry you added.

[nuku97]

I finally found a workaround for the problem that Windows Update will corrupt the grub bootloader, which I had to place at /EFI/Boot and /EFI/Microsoft/Boot locations due this being the default fallback paths, while moving the Windows bootloader to a different directory, e.g. /EFI/Windows. Moving grub to that path was nessesarry as discussed in this issue (see above, for example comment from mesiu84), because due to pre-authentification, the UEFI on my mainboard deletes all UEFI entries of unavailable partitions and therefore never boots grub at its default location (/EFI/gentoo in my case) but always falls back to this 'fallback paths' at /EFI/Microsoft/Boot or /EFI/Boot.

Now I figured out, that after pre-authentification and unlocking my drives, the UEFI will always try to boot from the EFI partition from the FIRST drive. In my setup, I have two identical drives, both with locking mechanism enabled.

So my idea was: What if I could move the Windows Boot Manager to a second EFI partition on the SECOND drive? So I could solely install grub on the EFI partition on the first drive and chainload the Windows Bootloader from the other EFI partition on the second drive. Windows Update however, would only update the second EFI partition and never touch my primary EFI partition with Grub again. And my UEFI would always boot grub from the EFI partition on the first drive after unlocking. And indeed, this seems to work; at least the last big Windows Update did not touch the EFI parition on the first drive and my Grub survived such an update for the first time!

This might also work with only one drive, by creating two separate EFI partitons. However, this might not be standards conform and I didn't try it.

Disk Layout when I started:

Disk 1:

• EFI
• Windows
• Linux (System)

Disk 2:

• Linux (Data)

What I did:

1. Resized (shrinked) Linux partition on Disk2 with gparted

2. Created a new (empty) EFI partition on Disk2 with fdisk (using partition type 1), according to Gentoo Handbook

3. Booted to Windows

4. Startet "cmd" as Administrator

5. Mounted the new EFI partition on Disk2 using 'diskpart' program to drive letter "Z":

• Use 'list disks' to see list of disks and numbers
• Use 'sel disk ' to select drive with new EFI partition
• Use 'list par' to see list of partitions of selected disk
• Use 'sel par ' to select the EFI partition (partition of type "System")
• Use 'assign letter="z"' to assign a drive letter
• Use 'exit' to close diskpart

6. Write Windows Bootloader to new EFI partition on Z Drive with 'bcdboot' tool (included with Windows):

bcdboot c:\windows /l de-de /s z: /f UEFI

7. Remove drive letter with diskpart

• Use 'sel disk ' to select drive with new EFI partition
• Use 'sel par ' to select the EFI partition (partition of type "System")
• Use 'remove letter="z"' to remove the drive letter
• Use 'exit' to close diskpart

8. Boot linux

9. Mount original EFI partition on Disk1

10. Delete all files from original EFI parition on Disk1

11. Reinstall grub on original EFI partition on Disk1 including removable mode

grub-install --target=x86_64-efi --efi-directory=<mount point of EFI parition on Disk1>
grub-install --target=x86_64-efi --efi-directory=<mount point of EFI parition on Disk1> --removable

12. Configure grub to Chainload the windows bootloader from the second (new) EFI partition on Disk2

• Use 'lsblk' to find the UUID of the second UEFI partition. In my case it is 6276-B891
• have a grub config like this:

menuentry 'Windows 11 (disk2, /Microsoft/)' --class windows --class os $menuentry_id_option 'osprober-efi-6276-B891' --unrestricted '' {
        insmod part_gpt
        insmod fat
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root  6276-B891
        else
          search --no-floppy --fs-uuid --set=root 6276-B891
        fi
        chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}

[pedrib]

@nuku97 this looks like a great workaround, but I suspect it is system dependant.
In my laptop I have two m2 SSD drives, one with Windows and another with Linux. It doesn't matter which m2 slot the drives are, the UEFI will always try to boot from the Windows one if it's there.

@stuckj workaround works perfectly on my system.

[nuku97]

@pedrib Did you try to place Grub's EFI file in all the "magic" locations on your first drive's EFI partition, which seem to be:

• /EFI/BOOT/BOOTX64.EFI
• /EFI/Microsoft/Boot/bootmgfw.efi

This might trick your UEFI to think there is a Windows boot loader installed on that drive and chose it over the second drive with Window's EFI partition.
But you are right, this might all be system dependent. I am using a MSI B450 Mortar Max mainboard.