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.