You are not logged in.
Pages: 1
Hey all,
I'm trying to get to boot my laptop with secure boot enabled. After having run without it ever since I switched to UEFI, I noticed it is now relatively easy to switch, so I decided to give it a shot. I enabled Secure Boot again, booted the Arch Linux install image from USB and was indeed met with this warning message. I followed the steps outlined there and the system booted fine, after which I proceeded to install everything the usual way.
While in the chroot, I installed prebootloader as required. I then followed the steps outlined in this Reddit post, after having confirmed with Head_on_a_Stick on the Crunchbang Linux forums that these instructions are correct. In my search, I also found another webpage with the same instructions, albeit looking a bit more professional.
I followed the instructions outlined in both websites:
# cd /boot/EFI/systemd/
# cp /usr/lib/prebootloader/* .
# mv systemd-bootx64.efi loader.efi
# efibootmgr -c -d /dev/sda -p 1 -l /EFI/systemd/PreLoader.efi -L "PreLoader"
I confirmed that the new entry was indeed there, and set it as next boot option:
# efibootmgr
BootCurrent: 000C
Timeout: 0 seconds
BootOrder: 000C,000F,000A,0006,0007,0008,0009,000B
Boot0000 Setup
Boot0001 Boot Menu
Boot0002 Diagnostic Splash Screen
Boot0003 Lenovo Diagnostics
Boot0004 Rescue and Recovery
Boot0005 Startup Interrupt Menu
Boot0006* USB CD
Boot0007* USB FDD
Boot0008* ATA HDD0
Boot0009* ATA HDD1
Boot000A* USB HDD
Boot000B* PCI LAN
Boot000C* Preloader
Boot000F* Linux Boot Manager
After this, I restarted my laptop and was greeted with a warning saying "Image failed to verify with *ACCESS DENIED*. Press any key to continue.". This time, however, unlike with the Arch installation image, I was not presented with a menu to launch HashTool in order to enroll a hash: it skips straight to the usual bootloader menu, giving me my usual three options: Arch Linux, Default EFI or reboot into firmware. When I select Arch Linux, I get the same warning again after which my laptop proceeds to boot normally.
I can not figure out why I am not presented with the option to enroll a new hash. As you can see, my Preloader entry is set as the first in the boot order and my current boot is via the Preloader entry. I tried the whole setup again, thinking I did something wrong, but the outcome is exactly the same.
EDIT: Here is the output of bootctl:
# bootctl status
System:
Firmware: UEFI 2.31 (Phoenix Technologies Ltd. 4660.22136)
Secure Boot: enabled
Setup Mode: user
Loader:
Product: systemd-boot 226
Partition: /dev/disk/by-partuuid/903a6edd-74b5-4061-b2d3-5cf33a7092fb
File: └─/EFI/systemd/loader.efi
Boot Loader Binaries:
ESP: /dev/disk/by-partuuid/903a6edd-74b5-4061-b2d3-5cf33a7092fb
File: └─/EFI/systemd/HashTool.efi
File: └─/EFI/systemd/KeyTool.efi
File: └─/EFI/systemd/PreLoader.efi
File: └─/EFI/systemd/loader.efi (systemd-boot 226)
File: └─/EFI/Boot/BOOTX64.EFI (systemd-boot 226)
Boot Loader Entries in EFI Variables:
Title: Preloader
ID: 0x000C
Status: active, boot-order
Partition: /dev/disk/by-partuuid/903a6edd-74b5-4061-b2d3-5cf33a7092fb
File: └─/EFI/systemd/PreLoader.efi
Title: Linux Boot Manager
ID: 0x000F
Status: active, boot-order
Partition: /dev/disk/by-partuuid/903a6edd-74b5-4061-b2d3-5cf33a7092fb
File: └─/EFI/systemd/systemd-bootx64.efi
Can someone here point me towards some instructions, or tell me what I did wrong? In case it matters, the laptop I'm using is a Lenovo Thinkpad Edge E130. The second page with instructions I linked to mentions that Lenovo laptops refuse to boot when the entries aren't named after Microsoft or RedHat, but I don't think that is happening here considering my laptop does boot. Perhaps it is another Lenovo quirk I'm experiencing; I have no clue.
Thanks in advance!
Last edited by Unia (2015-09-21 15:55:20)
If you can't sit by a cozy fire with your code in hand enjoying its simplicity and clarity, it needs more work. --Carlos Torres
Offline
Well, according to the `bootctl` output, you *are* booted with Secure Boot enabled.
The only difference in my system is the existence of an NVRAM entry for the HashTool:
# efibootmgr -d /dev/sda -p 1 -c -L "HashTool" -l /EFI/systemd/HashTool.efi
With the boot order set to Preloader, then HashTool then systemd-boot ("Linux Boot Manager"):
empty@Arch ~ % efibootmgr
BootCurrent: 0007
Timeout: 0 seconds
BootOrder: 0007,0008,0006,0009,0000
Boot0000* USB Stick
Boot0006* Linux Boot Manager
Boot0007* PreLoader
Boot0008* HashTool
Boot0009* UEFI OS
With this set up, the Prebootloader screen showed up first boot and I enrolled prebootloader.efi, hashtool.efi, loader.efi, $ESP/EFI/Boot/Bootx64.efi and the kernel image & initramfs (better safe than sorry).
My system now boots without errors:
empty@Arch ~ % sudo bootctl status
System:
Firmware: UEFI 2.31 (American Megatrends 4.654)
Secure Boot: enabled
Setup Mode: user
Loader:
Product: systemd-boot 226
Partition: /dev/disk/by-partuuid/53aa6ebb-7a0a-4053-82cf-ce09029de47e
File: └─/EFI/systemd/loader.efi
Boot Loader Binaries:
ESP: /dev/disk/by-partuuid/53aa6ebb-7a0a-4053-82cf-ce09029de47e
File: └─/EFI/systemd/HashTool.efi
File: └─/EFI/systemd/systemd-bootx64.efi (systemd-boot 226)
File: └─/EFI/systemd/KeyTool.efi
File: └─/EFI/systemd/PreLoader.efi
File: └─/EFI/systemd/loader.efi (systemd-boot 226)
File: └─/EFI/Boot/BOOTX64.EFI (systemd-boot 226)
Boot Loader Entries in EFI Variables:
Title: PreLoader
ID: 0x0007
Status: active, boot-order
Partition: /dev/disk/by-partuuid/53aa6ebb-7a0a-4053-82cf-ce09029de47e
File: └─/EFI/systemd/Preloader.efi
Title: HashTool
ID: 0x0008
Status: active, boot-order
Partition: /dev/disk/by-partuuid/53aa6ebb-7a0a-4053-82cf-ce09029de47e
File: └─/EFI/systemd/HashTool.efi
Title: Linux Boot Manager
ID: 0x0006
Status: active, boot-order
Partition: /dev/disk/by-partuuid/53aa6ebb-7a0a-4053-82cf-ce09029de47e
File: └─/EFI/systemd/systemd-bootx64.efi
Title: UEFI OS
ID: 0x0009
Status: active, boot-order
Partition: /dev/disk/by-partuuid/53aa6ebb-7a0a-4053-82cf-ce09029de47e
File: └─/EFI/BOOT/BOOTX64.EFI
Para todos todo, para nosotros nada
Offline
Adding an entry for HashTool does sadly not resolve my issue:
# efibootmgr
BootCurrent: 000C
Timeout: 0 seconds
BootOrder: 000C,000D,000F
Boot0000 Setup
Boot0001 Boot Menu
Boot0002 Diagnostic Splash Screen
Boot0003 Lenovo Diagnostics
Boot0004 Rescue and Recovery
Boot0005 Startup Interrupt Menu
Boot0006* USB CD
Boot0007* USB FDD
Boot0008* ATA HDD0
Boot0009* ATA HDD1
Boot000A* USB HDD
Boot000B* PCI LAN
Boot000C* Preloader
Boot000D* HashTool
Boot000F* Linux Boot Manager
# bootctl status
System:
Firmware: UEFI 2.31 (Phoenix Technologies Ltd. 4660.22136)
Secure Boot: enabled
Setup Mode: user
Loader:
Product: systemd-boot 226
Partition: /dev/disk/by-partuuid/903a6edd-74b5-4061-b2d3-5cf33a7092fb
File: └─/EFI/systemd/loader.efi
Boot Loader Binaries:
ESP: /dev/disk/by-partuuid/903a6edd-74b5-4061-b2d3-5cf33a7092fb
File: └─/EFI/systemd/HashTool.efi
File: └─/EFI/systemd/KeyTool.efi
File: └─/EFI/systemd/PreLoader.efi
File: └─/EFI/systemd/loader.efi (systemd-boot 226)
File: └─/EFI/Boot/BOOTX64.EFI (systemd-boot 226)
Boot Loader Entries in EFI Variables:
Title: Preloader
ID: 0x000C
Status: active, boot-order
Partition: /dev/disk/by-partuuid/903a6edd-74b5-4061-b2d3-5cf33a7092fb
File: └─/EFI/systemd/PreLoader.efi
Title: HashTool
ID: 0x000D
Status: active, boot-order
Partition: /dev/disk/by-partuuid/903a6edd-74b5-4061-b2d3-5cf33a7092fb
File: └─/EFI/systemd/HashTool.efi
Title: Linux Boot Manager
ID: 0x000F
Status: active, boot-order
Partition: /dev/disk/by-partuuid/903a6edd-74b5-4061-b2d3-5cf33a7092fb
File: └─/EFI/systemd/systemd-bootx64.efi
Maybe I should try booting directly into HashTool? Or perhaps there is an equivalent to an executable bit on the ESP partition that isn't set? My `ls` output shows nothing strange:
# ls -l /boot/EFI/systemd/
total 408
-rwxr-xr-x 1 root root 100656 21.09.2015 16:59 HashTool.efi
-rwxr-xr-x 1 root root 130057 21.09.2015 16:59 KeyTool.efi
-rwxr-xr-x 1 root root 101160 21.09.2015 16:59 PreLoader.efi
-rwxr-xr-x 1 root root 80142 08.09.2015 19:57 loader.efi
Also, HoaS, have you noticed the File entries in our `bootctl` outputs are different? (E.g. `PreLoader` in mine versus `Preloader` in yours)
If you can't sit by a cozy fire with your code in hand enjoying its simplicity and clarity, it needs more work. --Carlos Torres
Offline
After upgrading to linux 4.2 yesterday, I had to rehash vmlinuz-linux. This time I did get the HashTool prompt and signed vmlinuz-linux, HashTool, KeyTool, PreLoader and loader. However, I am still getting the warning saying "Image failed to verify with *ACCESS DENIED*. Press any key to continue.".
Seems like it is not related to things being signed or unsigned... what else can it be?
If you can't sit by a cozy fire with your code in hand enjoying its simplicity and clarity, it needs more work. --Carlos Torres
Offline
I had a kernel update yesterday and I had to enrol the new kernel image using the Preloader (it loaded automatically) then it continued to boot without error.
OTOH, I tried to enable Secure Boot on my other laptop and it wouldn't work at all (the Preloader showed and enrolled the hashes but the system wouldn't boot).
I think we have to put this down to buggy & inconsistent firmware implementation.
AFAICT, your system seems to be booting with Secure Boot enabled so you may just have to ignore the error message.
Para todos todo, para nosotros nada
Offline
I think we have to put this down to buggy & inconsistent firmware implementation.
I think that is a reasonable assumption to make. I just checked my BIOS settings again and found nothing out of the ordinary. I guess I'll have to live with those two warnings and no automatic boot
If you can't sit by a cozy fire with your code in hand enjoying its simplicity and clarity, it needs more work. --Carlos Torres
Offline
I use a combined efi stub, kernel and initramfs, combined in a single file, which is then signed with my key.
This is the makefile and some explanation I used:
Offline
Thanks for the tip, but I have reverted to booting without secure boot enabled.
If you can't sit by a cozy fire with your code in hand enjoying its simplicity and clarity, it needs more work. --Carlos Torres
Offline
Bumping this topic to add a little more:
I have found that using the default UEFI loader location for {PreLoader,HashTool}.efi & loader.efi removes the need for a custom NVRAM entry to boot PreLoader.efi
More here:
https://wiki.archlinux.org/index.php/Un … led_system
Para todos todo, para nosotros nada
Offline
I have the same issue on Lenovo X1 Carbon 2nd gen. I also think it's a bug in the UEFI implementation but sadly no new BIOS update is available for this model.
Offline
Pages: 1