This machine has a very peculiar firmware. The regular EFI variables are not honored. To register boot entries, you must:
Enter firmware (F2 during boot)
Set a firmware password, if not set yet, otherwise you can't change any of the settings below
Enable secure boot, if not enabled
Manually register a UEFI entry by choosing option "Select an UEFI file as trusted for executing", and then browsing to the UEFI binary of choice
Disable secure boot again, if desired
Disable firmware password, if desired
Exit firmware setup and save changes
It's possible to reorder the entries via the firmware setup. Once added, entries cannot be removed (even if the binary is no longer present in the ESP). It's necessary to reset the secure boot configuration to default, which will restore the Windows entry as the singe entry, and then manually register the desired ones using the process above.
Changes via efibootmgr are not honored: they are not shown in the firmware setup nor they are used during boot: during a reboot the entries from the firmware setup are synced back to the regular variables, so any changes get overwritten.
By inspecting the contents of /sys/firmware/efi/efivars it looks like that firmware setup is writing the boot entries in the following variable: ACUB-89cb0e8d-393c-4830-bfff-65d9147e8c3b.
I have reset the firmware to defaults, which restored the Windows boot loader as the single boot entry and then I registered a a new entry for rEFInd, and I have reordered them so rEFInd is the first one. This is what gets saved:
I know this is not a bug in efibootmgr, but it would be great if this variable could be reverse-engineered so efibootmgr works out of the box on these machines by detecting that the variable exists and changing its contents as well. I suspect that a number of other machines from Acer behave in the same way. I can help doing more experiments (registering new entries, reordering, resetting to defaults) so the structure of this variable can be deduced.
We the maintainers don't have any Acer/Insyde hardware to debug on. While we therefore can't do this work, we are willing to review patches to make this work.
Machine: Acer Swift SF314-43 BIOS: Insyde v1.04 (2021-07-28)
This looks very similar to: https://github.com/rhboot/efibootmgr/issues/19
This machine has a very peculiar firmware. The regular EFI variables are not honored. To register boot entries, you must:
It's possible to reorder the entries via the firmware setup. Once added, entries cannot be removed (even if the binary is no longer present in the ESP). It's necessary to reset the secure boot configuration to default, which will restore the Windows entry as the singe entry, and then manually register the desired ones using the process above.
Changes via
efibootmgr
are not honored: they are not shown in the firmware setup nor they are used during boot: during a reboot the entries from the firmware setup are synced back to the regular variables, so any changes get overwritten.By inspecting the contents of
/sys/firmware/efi/efivars
it looks like that firmware setup is writing the boot entries in the following variable:ACUB-89cb0e8d-393c-4830-bfff-65d9147e8c3b
.I have reset the firmware to defaults, which restored the Windows boot loader as the single boot entry and then I registered a a new entry for rEFInd, and I have reordered them so rEFInd is the first one. This is what gets saved:
I know this is not a bug in
efibootmgr
, but it would be great if this variable could be reverse-engineered soefibootmgr
works out of the box on these machines by detecting that the variable exists and changing its contents as well. I suspect that a number of other machines from Acer behave in the same way. I can help doing more experiments (registering new entries, reordering, resetting to defaults) so the structure of this variable can be deduced.