Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Acer Swift SF314-43: Boot entries overwritten on reboot #150

Open
lbschenkel opened this issue Sep 19, 2021 · 1 comment
Open

Acer Swift SF314-43: Boot entries overwritten on reboot #150

lbschenkel opened this issue Sep 19, 2021 · 1 comment

Comments

@lbschenkel
Copy link

lbschenkel commented Sep 19, 2021

Machine: Acer Swift SF314-43
BIOS: Insyde v1.04 (2021-07-28)

This looks very similar to: #19


This machine has a very peculiar firmware. The regular EFI variables are not honored. To register boot entries, you must:

  1. Enter firmware (F2 during boot)
  2. Set a firmware password, if not set yet, otherwise you can't change any of the settings below
  3. Enable secure boot, if not enabled
  4. 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
  5. Disable secure boot again, if desired
  6. Disable firmware password, if desired
  7. 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:

# hexdump -C ACUB-89cb0e8d-393c-4830-bfff-65d9147e8c3b 
00000000  07 00 00 00 fb 02 00 00  00 00 00 00 30 00 00 00  |............0...|
00000010  00 00 00 00 47 01 00 00  00 00 00 00 b4 01 00 00  |....G...........|
00000020  00 00 00 00 21 02 00 00  00 00 00 00 8e 02 00 00  |....!...........|
00000030  00 00 00 00 42 44 50 30  17 01 00 00 00 00 00 00  |....BDP0........|
00000040  72 00 45 00 46 00 49 00  6e 00 64 00 00 00 00 00  |r.E.F.I.n.d.....|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000070  00 00 09 ae 01 00 00 00  01 00 00 00 00 00 00 00  |................|
00000080  00 42 00 6f 00 6f 00 74  00 30 00 30 00 30 00 31  |.B.o.o.t.0.0.0.1|
00000090  00 00 00 00 00 c3 2e 92  01 aa 00 00 00 00 00 00  |................|
000000a0  00 01 00 00 00 90 00 72  00 45 00 46 00 49 00 6e  |.......r.E.F.I.n|
000000b0  00 64 00 00 00 02 01 0c  00 d0 41 03 0a 00 00 00  |.d........A.....|
000000c0  00 01 01 06 00 04 02 01  01 06 00 00 00 03 17 10  |................|
000000d0  00 01 00 00 00 00 a0 75  01 2c a3 98 51 04 01 2a  |.......u.,..Q..*|
000000e0  00 01 00 00 00 00 08 00  00 00 00 00 00 00 20 03  |.............. .|
000000f0  00 00 00 00 00 0b 94 b0  3c 15 a1 46 42 b1 46 47  |........<..FB.FG|
00000100  35 8e 1a 04 5a 02 02 04  04 3a 00 5c 00 45 00 46  |5...Z....:.\.E.F|
00000110  00 49 00 5c 00 72 00 65  00 66 00 69 00 6e 00 64  |.I.\.r.e.f.i.n.d|
00000120  00 5c 00 72 00 65 00 66  00 69 00 6e 00 64 00 5f  |.\.r.e.f.i.n.d._|
00000130  00 78 00 36 00 34 00 2e  00 65 00 66 00 69 00 00  |.x.6.4...e.f.i..|
00000140  00 7f ff 04 00 41 30 31  20 09 ae 42 44 50 31 6d  |.....A01 ..BDP1m|
00000150  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001b0  00 00 00 00 00 00 00 00  42 44 50 32 6d 00 00 00  |........BDP2m...|
000001c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000220  00 00 00 00 00 42 44 50  33 6d 00 00 00 00 00 00  |.....BDP3m......|
00000230  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000290  00 00 42 44 50 34 6d 00  00 00 00 00 00 00 00 00  |..BDP4m.........|
000002a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000002f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00     |...............|
000002ff
# efibootmgr
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001,0000,2001,2002,2003
Boot0000* Windows Boot Manager
Boot0001* rEFInd
Boot2001* EFI USB Device
Boot2002* EFI DVD/CDROM
Boot2003* EFI Network

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.

@frozencemetery
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants