UEFI Boot entry is lost after PBA authentication (with solution) about sedutil HOT 25 CLOSED

@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.

from sedutil.

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.

from sedutil.

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

from sedutil.

@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...

from sedutil.

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.

from sedutil.

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.

from sedutil.

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.

from sedutil.

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.

from sedutil.

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

from sedutil.

@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?

from sedutil.

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.

from sedutil.

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.

from sedutil.

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!

from sedutil.

@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.

from sedutil.

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

from sedutil.

@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.

from sedutil.

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

from sedutil.

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.

from sedutil.

@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!

from sedutil.

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

from sedutil.

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}

from sedutil.

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.

from sedutil.

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

from sedutil.

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

from sedutil.

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.

from sedutil.