Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
SecureBoot - do it like debian, but how? [solved]
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Installing Gentoo
View previous topic :: View next topic  
Author Message
Banana
Veteran
Veteran


Joined: 21 May 2004
Posts: 1015
Location: Germany

PostPosted: Tue Nov 22, 2022 2:30 pm    Post subject: SecureBoot - do it like debian, but how? [solved] Reply with quote

Well, I do have a valid new ThinkPad T14 Gen2 and it is company "secured". SecureBoot with Windows 11 and BIOS with supervisor password (battery removal will NOT work)
Since the inhouse support is busy I'm gonna tinker with this myself for now.

Since I can not deactivate the SecureBoot to update the keys, I'm stuck with doing it somehow different. But how?

I've managed to install debian from a debian live USB-Stick to another USB3 attached SSD disk since debian can handle the SecureBoot stuff. shim and grub I assume. I will not touch the internal nvme until I'm sure I will not break anything. Bitlocker is not enabled and I could create a new partition but I'm not sure how windows 11 will handle this.

So my journey will be to find out how to get gentoo to work on the USB3 attached SSD and then maybe internally on the nvme.

Has anyone experience in this? Somehow it should work since debian does it.

And yes, I know the SecureBoot tutorials but all the ones I know have a task which disables the SecureBoot for some reboots. And this is something I can not do right now.

The closest information which could work would be this: https://forums.gentoo.org/viewtopic-t-1132536.html
But I'm not sure what is really needed. Grub, stub kernel ...?

tl:dr
[*]Use a distribution that can boot with Secure Boot enabled as your installation medium. Debian, Ubuntu or Fedora
[*]Install following the handbook. Leave out the initial setup part since you use another OS to create a chroot. Copy over the network config, mount the partition and perpare the chroot
[*]Build kernel with efi stub
[*]no grub or lilo
[*]install efibootmgr (as mentioned in the docs) and added a new entry (make sure to use the right partition number. I think the docs use a wrong one)
[*]installed shim pakage and copied the needed files
[*]made sure the new kernel image is copied to grubx64.efi
[*]requesting insecure mode from Gentoo's chroot with mokutil --disable-validation, and creating a password.
[*]Follow the rest of the handbook until reboot
[*]AFTER reboot, confirming insecure mode from MokManager's "Change Secure Boot state" menu item, and providing 3 random characters from the password
_________________
My personal space
My delta-labs.org snippets do expire


Last edited by Banana on Fri Dec 02, 2022 1:17 pm; edited 4 times in total
Back to top
View user's profile Send private message
GrandeGrabois
n00b
n00b


Joined: 16 Oct 2019
Posts: 38

PostPosted: Thu Nov 24, 2022 12:25 am    Post subject: Reply with quote

Maybe this can help
https://www.rodsbooks.com/efi-bootloaders/secureboot.html#initial_shim
See after "using a signed bootloader".

And this
https://wiki.debian.org/SecureBoot

Gentoo provides the sys-boot/shim package, which should boot with the keys preinstalled in your machine.
shim then uses MOK to verify your bootloader and kernel. So you would have to create your own keys and put then in the MOK area.

But I can't give the specifics, as I've never encountered a situation in which I couldn't just replace all the keys.
Back to top
View user's profile Send private message
Banana
Veteran
Veteran


Joined: 21 May 2004
Posts: 1015
Location: Germany

PostPosted: Thu Nov 24, 2022 3:53 pm    Post subject: Reply with quote

Thanks. The rodsbooks links are quite a good read.

Know I need to figure out how does this work with this shim package.
_________________
My personal space
My delta-labs.org snippets do expire


Last edited by Banana on Fri Nov 25, 2022 1:14 pm; edited 1 time in total
Back to top
View user's profile Send private message
GDH-gentoo
Veteran
Veteran


Joined: 20 Jul 2019
Posts: 1002
Location: South America

PostPosted: Thu Nov 24, 2022 9:37 pm    Post subject: Re: SecureBoot - do it like debian, but how? Reply with quote

Banana wrote:
Since I can not deactivate the SecureBoot to update the keys, I'm stuck with doing it somehow different. But how?

[...]

Has anyone experience in this? Somehow it should work since debian does it.

I don't have experience, but since this happens to be my preferred setup for using Gentoo with Secure Boot enabled if I was forced to, I've spent some time reading and looking at code to try to figure out how to do it.

Yes, Debian and other distributions use the Shim, signed with a key approved by Microsoft. Last time I checked, Gentoo's sys-boot/shim package seemed to install an unsigned Shim, so if that's the case, it won't work, and you'd have to borrow a signed Shim from another distribution. I believe this essentially amounts to copying that distribution's shimx64.efi and mmx64.efi (the MokManager) files to \EFI\gentoo in the NVMe's EFI System Partition (ESP).

Yes, the reference documentation for this setup would be the section on the Shim in https://www.rodsbooks.com/efi-bootloaders/secureboot.html. I believe that this translates to following the Handbook in Gentoo's case, with these differences:

1) You have to use a distribution that can boot with Secure Boot enabled (e.g. the Debian live USB drive that you mentioned) as your installation medium.
2) You have to add the --no-nvram option to the grub-install command each time, so that GRUB does not modify EFI variables.
3) You have to do a one time manual invocation of efibootmgr to tell the UEFI firmware to boot the Shim. Something like efibootmgr --create --label "Shim" --disk NVMe-device [--part ESP-partition-number] --loader '\EFI\gentoo\shimx64.efi'.
4) You then have two choices:
  • Install sys-boot/mokutil, use it to tell the Shim to boot in insecure mode, and confirm it using the MokManager. This should mostly be like installing Gentoo on UEFI with Secure Boot disabled —the Shim will not do any signature verification once the firmware gives it control of the boot process—, without actually disabling it in the firmware.
  • Create a machine owner key (MOK) with OpenSSL for signing Gentoo's build of GRUB, use the MokManager to enroll the corresponding public key certificate, and sign lots of stuff as the documentation says... You probably don't do this with Debian because it is a binary-based distribution (nothing is built on your computer) and likely ships bootloaders and kernels already signed with a private key whose corresponding public key certificate is embedded in their build of the Shim. But that's not an option for Gentoo.
Which alternative do you want to try?
_________________
NeddySeagoon wrote:
I'm not a witch, I'm a retired electronics engineer :)
Back to top
View user's profile Send private message
Banana
Veteran
Veteran


Joined: 21 May 2004
Posts: 1015
Location: Germany

PostPosted: Fri Nov 25, 2022 1:27 pm    Post subject: Reply with quote

Quote:
Yes, Debian and other distributions use the Shim, signed with a key approved by Microsoft. Last time I checked, Gentoo's sys-boot/shim package seemed to install an unsigned Shim, so if that's the case, it won't work, and you'd have to borrow a signed Shim from another distribution.

As far as I can tell the https://packages.gentoo.org/packages/sys-boot/shim does download the sources from fedora: https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-boot/shim/shim-15.6.ebuild

Quote:
1) You have to use a distribution that can boot with Secure Boot enabled (e.g. the Debian live USB drive that you mentioned) as your installation medium.

Yes, this is what I did.

Quote:
2) You have to add the --no-nvram option to the grub-install command each time, so that GRUB does not modify EFI variables.

Do I need to use grub? I'm bootloadfree for a long time

Quote:
3) You have to do a one time manual invocation of efibootmgr to tell the UEFI firmware to boot the Shim. Something like efibootmgr --create --label "Shim" --disk NVMe-device [--part ESP-partition-number] --loader '\EFI\gentoo\shimx64.efi'.

I would manual call the boot menu fromt he bios anyway, so this isn't really needed?

Does step 4, variant one, work if I'm not able to deactivate SecureBoot?


Let me summarize what I would do:
Install gentoo as usual until first reboot. I would build the kernel and copy the result to /boot/efi/boot.efi and then use the uefi boot menu to select what to boot.
But this is where I do not have a clear idea what to do:
- install the shim package and NOT copy the boot image to /boot/efi/boot.efi. But how does the shim page know which kernel to boot?
- Install grub too?
_________________
My personal space
My delta-labs.org snippets do expire
Back to top
View user's profile Send private message
GDH-gentoo
Veteran
Veteran


Joined: 20 Jul 2019
Posts: 1002
Location: South America

PostPosted: Fri Nov 25, 2022 7:52 pm    Post subject: Reply with quote

Banana wrote:
As far as I can tell the https://packages.gentoo.org/packages/sys-boot/shim does download the sources from fedora:
Yes. But the contents of Fedora's RPM confused me. I looked again, and I might have been wrong thinking that it installed an unsigned Shim. All right, it's worth trying this package first.

Banana wrote:
Do I need to use grub? I'm bootloadfree for a long time
Oh. Do you want to use an EFI stub kernel then? That should be supported, as long as you install it in the directory of the ESP that contains shimx64.efi, and you name it grubx64.efi, even if it isn't actually GRUB. That name is hardcoded in Fedora's build of the Shim.

Banana wrote:
Quote:
3) You have to do a one time manual invocation of efibootmgr to tell the UEFI firmware to boot the Shim. Something like efibootmgr --create --label "Shim" --disk NVMe-device [--part ESP-partition-number] --loader '\EFI\gentoo\shimx64.efi'.

I would manual call the boot menu fromt he bios anyway, so this isn't really needed?

Isn't the boot menu protected by the password that you don't know? You have to if the firmware's user interface can't add items to the menu, or won't let you do it (or even access the UI) without a password. Be sure to add shimx64.efi to the boot menu, not grubx64.efi or any other PE32+ binary.

Banana wrote:
Does step 4, variant one, work if I'm not able to deactivate SecureBoot?

As far as I can tell, it should. See later.

Banana wrote:
Let me summarize what I would do:
[...] I would build the kernel and copy the result to /boot/efi/boot.efi [...]

I consider overwriting \EFI\BOOT\BOOTX64.EFI bad practice unless the firmware is really bad. That binary should normally be the computer manufacturer's last resort boot manager and left alone. See this post.

Banana wrote:
But this is where I do not have a clear idea what to do:

As far as I can tell from all my reading, it should go something like this:

1) Follow the Handbook, using a distribution that can boot with Secure Boot enabled as the installation medium, except section "Configuring the bootloader". This includes building your EFI stub kernel.

2) Instead of installing sys-boot/grub, install sys-boot/shim and sys-boot/mokutil.

3) Assuming that the ESP is mounted at /boot/efi, copy your kernel to /boot/efi/EFI/gentoo/grubx64.efi, the BOOTX64.EFI file in /usr/share/shim to /boot/efi/EFI/gentoo/shimx64.efi, and the mmx64.efi file in /usr/share/shim to /boot/efi/EFI/gentoo/ with the same name. Adjust pathnames if you mount the ESP somewhere else.

4) Disable the Shim's signature verification using mokutil. That should be something like:
Code:
# mokutil --disable-validation
You should be asked to create a password, and specify it twice. Remember it. The efivars filesystem should be mounted read-write for this to succeed; mokutils, the Shim and the MokManager communicate using EFI variables in nonvolatile storage.

5) Convince the firmware to boot EFI\gentoo\shimx64.efi. With efibootmgr, or after reboot with its user interface if it lets you.

6) Exit the chroot, unmount filesystems and reboot, as per the Handbook. If everything went well, the Shim should start the MokManager, and you should see a "Change Secure Boot state" item in the main menu. Select it.

7) MokManager should ask you to enter three characters of the password that you created in step 4). If it sees that they match, it should ask you to confirm that you want to "disable Secure Boot" (which is misleading, MokManager isn't actually disabling it). If you say yes, the main menu should offer you to reboot the computer.

8 ) If everything went well, the Shim should display a "Booting in insecure mode" message, and then hopefully proceed to boot the Gentoo kernel.
_________________
NeddySeagoon wrote:
I'm not a witch, I'm a retired electronics engineer :)
Back to top
View user's profile Send private message
Banana
Veteran
Veteran


Joined: 21 May 2004
Posts: 1015
Location: Germany

PostPosted: Fri Nov 25, 2022 8:35 pm    Post subject: Reply with quote

woha thank you for the detailed writeup!

Quote:
Isn't the boot menu protected by the password that you don't know?

This laptop model has a supervisor password. This kind of password let you change some settings in the bios and also call the boot menu and manually select which entry to boot. But I can't change secureboot or any of the keys.

Quote:
1) Follow the Handbook, using a distribution that can boot with Secure Boot enabled as the installation medium, except section "Configuring the bootloader". This includes building your EFI stub kernel.

check

Quote:
Instead of installing sys-boot/grub, install sys-boot/shim and sys-boot/mokutil.

check

Quote:
3) Assuming that the ESP is mounted at /boot/efi, copy your kernel to /boot/efi/EFI/gentoo/grubx64.efi, the BOOTX64.EFI file in /usr/share/shim to /boot/efi/EFI/gentoo/shimx64.efi, and the mmx64.efi file in /usr/share/shim to /boot/efi/EFI/gentoo/ with the same name. Adjust pathnames if you mount the ESP somewhere else.

what do you mean with ESP?
My folder structure looks like this
Code:
/boot
/boot/efi/EFI/grubx64.efi
/boot/efi/EFI/BOOTX64.efi
/boot/efi/EFI/mmx64.efi

The grubx64.efi is the kernel I build.

Quote:
4) Disable the Shim's signature verification using mokutil.

check

Quote:
5) Convince the firmware to boot EFI\gentoo\shimx64.efi. With efibootmgr, or after reboot with its user interface if it lets you.

Check with a modification EFI\gentoo\BOOTX64.efi
Or does it really need to be named shimx64.efi?

Quote:
6) Exit the chroot, unmount filesystems and reboot, as per the Handbook.

Check.

BUT:
I can select the new entry in the boot menu. Then it just "blinks" and does nothing. As I select the USB-Debian LIVE Image I get messages that EFI paths can not be found and mokutil fails
Did the # mokutil --disable-validation write, or whatever it does, it to the wrong disk?
After rebuilding the USB stick the message still comes...

The Debian-LIVE USB-Image can not be booted anymore. The efi and mokutil error stays.
Windows does still boot fine. No problem there....
_________________
My personal space
My delta-labs.org snippets do expire
Back to top
View user's profile Send private message
GDH-gentoo
Veteran
Veteran


Joined: 20 Jul 2019
Posts: 1002
Location: South America

PostPosted: Sat Nov 26, 2022 2:14 am    Post subject: Re: SecureBoot - do it like debian, but how? Reply with quote

Banana wrote:
what do you mean with ESP?
My folder structure looks like this
Code:
/boot
/boot/efi/EFI/grubx64.efi
/boot/efi/EFI/BOOTX64.efi
/boot/efi/EFI/mmx64.efi

The ESP is the partition with a FAT filesystem of the disk of your Gentoo installation that fdisk shows with type "EFI System", and that contains the kernel. See this. Based on your output, you probably have it mounted at /boot/efi, which is the customary mountpoint.

Banana wrote:
Or does it really need to be named shimx64.efi?

Not really, but it usually is, unless you are installing to a removable medium.

Banana wrote:
As I select the USB-Debian LIVE Image I get messages that EFI paths can not be found and mokutil fails
Did the # mokutil --disable-validation write, or whatever it does, it to the wrong disk?

[...]

The Debian-LIVE USB-Image can not be booted anymore. The efi and mokutil error stays.

mokutil --disable-validation does not write to a disk. It creates an EFI variable named MokSB in the UEFI firmware's non-volatile storage, with the password and the desired signature verification state ("disabled" in this case). What I think that is happening with the live USB image is that Debian's Shim is noticing the presence of MokSB, tries to start MokManager (don't confuse with mokutil), and fails. Windows doesn't care about the MokSB variable. Are the messages you see like these?
Code:
Failed to load image ...
Failed to start MokManager: ...
Something has gone seriously wrong: import_mok_state() failed: ...

The Internet suggests that some distributions' live media don't ship with the MokManager (mmx64.efi). That might be the case for Debian. The Debian on your external disk might have it, though:

Banana wrote:
I've managed to install debian from a debian live USB-Stick to another USB3 attached SSD disk [...]

Do you still have that disk? Does it boot? If MokManager's menu does show, and you see the "Change Secure Boot state" item, select it and say no to "Disable Secure Boot". That should undo what mokutil did, delete the MokSB variable, and restore the previous state, so the live USB drive should boot again. Then it would be possible to diagnose what went wrong with Gentoo.

MokManager's main menu should look like this:
Code:
Continue boot
Change Secure Boot state
Enroll key from disk
Enroll hash from disk

_________________
NeddySeagoon wrote:
I'm not a witch, I'm a retired electronics engineer :)
Back to top
View user's profile Send private message
Banana
Veteran
Veteran


Joined: 21 May 2004
Posts: 1015
Location: Germany

PostPosted: Sat Nov 26, 2022 7:50 pm    Post subject: Reply with quote

Quote:
The ESP is the partition with a FAT filesystem of the disk of your Gentoo installation that fdisk shows with type "EFI System", and that contains the kernel. See this. Based on your output, you probably have it mounted at /boot/efi, which is the customary mountpoint.

No I mount it always directly to /boot

Quote:
The Internet suggests that some distributions' live media don't ship with the MokManager (mmx64.efi). That might be the case for Debian. The Debian on your external disk might have it, though:

This is the case, but also my USB stickt died...
Since I do not have access to the initial installed debian on the USB3-Disk I've created another one on a different PC just to make sure nothing else is wrong. Still the same error
Code:
Failed to open \EFI\BOOT\mmx64.efi - Not Found
Failed to load image \EFI\BOOT\mmx64.efi: Not Found
Failed to start MokManager: Not Fond
Something has gone seriously wrong: import_mok_state() failed


Then I've managed to "fix" it by rename grubx64.efi to mmx64.efi on a new debian live usb image (There is a launchpad bug about it. It also works with debian image: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1798171 )

Now I can boot from the debian live usb image again and see grub. Select the kernel and now stuck at this:
Code:
error: shim_lock protocol not found.
error: you need to load the kernel first.

_________________
My personal space
My delta-labs.org snippets do expire
Back to top
View user's profile Send private message
GDH-gentoo
Veteran
Veteran


Joined: 20 Jul 2019
Posts: 1002
Location: South America

PostPosted: Sat Nov 26, 2022 10:40 pm    Post subject: Reply with quote

Banana wrote:
No I mount it always directly to /boot.

Then why do you have everything in /boot/efi/EFI/ instead of, e.g., /boot/EFI/gentoo/?

Banana wrote:
Now I can boot from the debian live usb image again and see grub. Select the kernel and now stuck at this:
Code:
error: shim_lock protocol not found.
error: you need to load the kernel first.

Yeah, the code path in the Shim that installs the shim_lock protocol (which GRUB uses to validate the kernel's signature if Secure Boot is enabled), install_shim_protocols(), is executed after import_mok_state() returns, and that doesn't happen with the grubx64.efi --> mmx64.efi hack. Because then, import_mok_state() doesn't return.

However, if you were able to manipulate the live image, can't you copy Debian's real, signed MokManger to \EFI\BOOT\? It is provided by package shim-helpers-amd64-signed and should be in /usr/lib/shim/:

https://packages.debian.org/bullseye/shim-helpers-amd64-signed
_________________
NeddySeagoon wrote:
I'm not a witch, I'm a retired electronics engineer :)
Back to top
View user's profile Send private message
Banana
Veteran
Veteran


Joined: 21 May 2004
Posts: 1015
Location: Germany

PostPosted: Sat Nov 26, 2022 11:23 pm    Post subject: Reply with quote

Quote:
Then why do you have everything in /boot/efi/EFI/ instead of, e.g., /boot/EFI/gentoo/?

Based on some internet findings and I thought the path would mean someting...

Quote:
However, if you were able to manipulate the live image, can't you copy Debian's real, signed MokManger to \EFI\BOOT\? It is provided by package shim-helpers-amd64-signed and should be in /usr/lib/shim/:

No, but I just tried to use another distro, before you wrote your response.

I used fedora live image and the mok manager did appear as described by you:
Quote:
If everything went well, the Shim should start the MokManager, and you should see a "Change Secure Boot state" item in the main menu. Select it.

7) MokManager should ask you to enter three characters of the password that you created in step 4). If it sees that they match, it should ask you to confirm that you want to "disable Secure Boot" (which is misleading, MokManager isn't actually disabling it). If you say yes, the main menu should offer you to reboot the computer.


I've managed to do the steps and the live image does boot. Haven't tried debian yet.
So I have now a working live usb boot but the gentoo install does not boot yet. It does nothing if I select it in the boot menu.
What did I wrong or miss?
_________________
My personal space
My delta-labs.org snippets do expire
Back to top
View user's profile Send private message
GDH-gentoo
Veteran
Veteran


Joined: 20 Jul 2019
Posts: 1002
Location: South America

PostPosted: Sun Nov 27, 2022 3:51 pm    Post subject: Reply with quote

Banana wrote:
Quote:
Then why do you have everything in /boot/efi/EFI/ instead of, e.g., /boot/EFI/gentoo/?

Based on some internet findings and I thought the path would mean someting...
Per the UEFI specification, "OS loaders" such as GRUB, the Shim or an EFI stub kernel should be in a subdirectory of \EFI. So [GNU/]Linux distributions usually follow the convention \EFI\distribution\OS-loader (i.e. grubx64.efi, shimx64.efi, vmlinuz-version.efi, etc.). If the ESP is mounted at /boot, that translates to e.g. /boot/EFI/gentoo/vmlinuz-version.efi.

Banana wrote:
I used fedora live image and the mok manager did appear as described by you:
Quote:
If everything went well, the Shim should start the MokManager, and you should see a "Change Secure Boot state" item in the main menu. Select it.

7) MokManager should ask you to enter three characters of the password that you created in step 4). If it sees that they match, it should ask you to confirm that you want to "disable Secure Boot" (which is misleading, MokManager isn't actually disabling it). If you say yes, the main menu should offer you to reboot the computer.


I've managed to do the steps and the live image does boot.

Excelent! Did you say "yes" or "no" to "Change Secure Boot state"?

Banana wrote:
So I have now a working live usb boot but the gentoo install does not boot yet. It does nothing if I select it in the boot menu.
What did I wrong or miss?

Remind me how this laptop is set up. You have an NVMe with Windows, a USB drive with a Debian live image, at some point an USB3 external disk with a full Debian, and... where is Gentoo?

Can you enter the Gentoo chroot from the live medium now? If yes, could you temporarily install sys-boot/efibootmr and post the outputs of:
Code:
$ mount
$ ls /boot/* /boot/efi/*
$ ls /sys/firmware/efi/efivars
$ efibootmgr -v

_________________
NeddySeagoon wrote:
I'm not a witch, I'm a retired electronics engineer :)
Back to top
View user's profile Send private message
Banana
Veteran
Veteran


Joined: 21 May 2004
Posts: 1015
Location: Germany

PostPosted: Sun Nov 27, 2022 7:21 pm    Post subject: Reply with quote

Quote:
Per the UEFI specification, "OS loaders" such as GRUB, the Shim or an EFI stub kernel should be in a subdirectory of \EFI. So [GNU/]Linux distributions usually follow the convention \EFI\distribution\OS-loader (i.e. grubx64.efi, shimx64.efi, vmlinuz-version.efi, etc.). If the ESP is mounted at /boot, that translates to e.g. /boot/EFI/gentoo/vmlinuz-version.efi.

Thanks, good to know. Currently just a make install in the kernel source directory just copies the result to /boot.

Quote:
Excelent! Did you say "yes" or "no" to "Change Secure Boot state"?

I did say yes. It now says booting in insecure mode as I start he fedora live USB-Stick

Quote:
Remind me how this laptop is set up. You have an NVMe with Windows, a USB drive with a Debian live image, at some point an USB3 external disk with a full Debian, and... where is Gentoo?

Because this is a new device I want to play it save. I still do not have any feedback if I can disable SecureBoot or not. Also I don't want to loose windows 11 (which is company configured) yet.
This is why I do have debian live USB-Stick, debian install on a USB-SDD, Fedora live USB-Stick, Gentoo install in a USB-SDD to keep the exsiting config and install out of harms way.

After I know that everything, or the most important things do work, I decide if I dualboot on the same nvme with windows or keep dualboot windows in nvme and linux external

Quote:
Can you enter the Gentoo chroot from the live medium now? If yes, could you temporarily install sys-boot/efibootmr and post the outputs of:

Code:
ls -l /boot
config-5.15.75-gentoo
System.map-5.15.75-gentoo
vmlinuz-5.15.75-gentoo


Code:
ls -l /boot/efi/EFI/
BOOTX64.EFI
grubx64.efi
mmx64.efi


eifbootmgr -v : http://delta-labs.org/sp/Ifk
_________________
My personal space
My delta-labs.org snippets do expire
Back to top
View user's profile Send private message
GDH-gentoo
Veteran
Veteran


Joined: 20 Jul 2019
Posts: 1002
Location: South America

PostPosted: Sun Nov 27, 2022 8:54 pm    Post subject: Reply with quote

Banana wrote:
Quote:
Excelent! Did you say "yes" or "no" to "Change Secure Boot state"?

I did say yes. It now says booting in insecure mode as I start he fedora live USB-Stick

Great. This was the important part.

Banana wrote:
This is why I do have debian live USB-Stick, debian install on a USB-SDD, Fedora live USB-Stick, Gentoo install in a USB-SDD to keep the exsiting config and install out of harms way.

[...]
Code:
ls -l /boot
config-5.15.75-gentoo
System.map-5.15.75-gentoo
vmlinuz-5.15.75-gentoo


Code:
ls -l /boot/efi/EFI/
BOOTX64.EFI
grubx64.efi
mmx64.efi


eifbootmgr -v : http://delta-labs.org/sp/Ifk

Code:
BootCurrent: 001D
Timeout: 2 seconds
BootOrder: 0002,0000,0001,001A,001B,001C,001D,001E,001F,0020,0021,0022
Boot0000* debian   HD(1,GPT,3e2e01fb-fe65-e841-8ecd-02caaf289503,0x1000,0x96000)/File(\EFI\debian\shimx64.efi)
...
Boot0001* Windows Boot Manager   HD(2,GPT,94eb64eb-350b-4168-bb63-43648e26d47f,0xfa000,0x100000)/File(\EFI\Microsoft\Boot\bootmgfw.efi) ...
Boot0002* Gentoo   HD(2,GPT,2dcb5082-14af-6245-9f58-9812a9fe2b36,0x80800,0x773800)/File(\EFI\BOOTX64.EFI)
...
Boot001D* USB HDD   VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,33e821aaaf33bc4789bd419f88c50803)

I still don't understand. You have Gentoo on an USB-attached external disk, and this disk has an EFI System Partition that you mount at /boot. Then, the output of the ls /boot command that you posted seems incomplete. This is what I believe is the ESP's file hierarchy:

Code:
\
|
+-- config-5.15.75-gentoo
+-- System.map-5.15.75-gentoo
+-- vmlinuz-5.15.75-gentoo  <-- the Gentoo kernel
+-- \efi
    |
    +-- BOOTX64.EFI  <-- according to the value of EFI variable Boot0002... Does this actually exist?
    +-- \EFI
        |
        +-- BOOTX64.EFI <-- the signed Shim from Fedora
        +-- grubx64.efi <-- a renamed copy of the Gentoo kernel (\vmlinuz-5.15.75-gentoo)
        +-- mmx64.efi   <-- the signed MokManager from Fedora

Am I right? Because if yes, you seem to have told the UEFI firmware to boot the wrong PE32+ file, it should be \efi\EFI\BOOTX64.EFI.
_________________
NeddySeagoon wrote:
I'm not a witch, I'm a retired electronics engineer :)
Back to top
View user's profile Send private message
Banana
Veteran
Veteran


Joined: 21 May 2004
Posts: 1015
Location: Germany

PostPosted: Sun Nov 27, 2022 9:24 pm    Post subject: Reply with quote

Quote:
I still don't understand. You have Gentoo on an USB-attached external disk, and this disk has an EFI System Partition that you mount at /boot. Then, the output of the ls /boot command that you posted seems incomplete.

This could be the case, since I did not really and still not really do understand the pathes here.

so this is what it should look like?
Code:
/boot <-- this is where the extra boot partition is mounted
/boot/config-5.15.75-gentoo
/boot/System.map-5.15.75-gentoo
/boot/vmlinuz-5.15.75-gentoo
/boot/EFI/BOOTX64.EFI <-- file from https://packages.gentoo.org/packages/sys-boot/shim
/boot/EFI/grubx64.efi <-- the kernel copy which I do need to update too as the kernel gets recompiled, right?
/boot/EFI/mmx64.efi <-- file from https://packages.gentoo.org/packages/sys-boot/shim


And the boot menu entry should be this:
Code:
Boot0002* Gentoo   HD(2,GPT,2dcb5082-14af-6245-9f58-9812a9fe2b36,0x80800,0x773800)/File(\EFI\BOOTX64.EFI)

_________________
My personal space
My delta-labs.org snippets do expire
Back to top
View user's profile Send private message
GDH-gentoo
Veteran
Veteran


Joined: 20 Jul 2019
Posts: 1002
Location: South America

PostPosted: Sun Nov 27, 2022 10:07 pm    Post subject: Reply with quote

Banana wrote:
so this is what it should look like?
Code:
/boot <-- this is where the extra boot partition is mounted
/boot/config-5.15.75-gentoo
/boot/System.map-5.15.75-gentoo
/boot/vmlinuz-5.15.75-gentoo
/boot/EFI/BOOTX64.EFI <-- file from https://packages.gentoo.org/packages/sys-boot/shim
/boot/EFI/grubx64.efi <-- the kernel copy which I do need to update too as the kernel gets recompiled, right?
/boot/EFI/mmx64.efi <-- file from https://packages.gentoo.org/packages/sys-boot/shim


And the boot menu entry should be this:
Code:
Boot0002* Gentoo   HD(2,GPT,2dcb5082-14af-6245-9f58-9812a9fe2b36,0x80800,0x773800)/File(\EFI\BOOTX64.EFI)

To be tidy, especially if you eventually want Gentoo to be on the laptop's NVMe with Windows, I would recommend this:
Code:
/boot                            <-- mountpoint of the EFI System Partition
/boot/config-5.15.75-gentoo      <-- installed by 'make install' when you build a kernel from sys-kernel/gentoo-kernel
/boot/System.map-5.15.75-gentoo  <-- installed by 'make install' when you build a kernel from sys-kernel/gentoo-kernel
/boot/vmlinuz-5.15.75-gentoo     <-- the compiled Gentoo kernel, installed by 'make install' when you build it from sys-kernel/gentoo-kernel
/boot/EFI/gentoo                 <-- created manually with 'mkdir'
/boot/EFI/gentoo/BOOTX64.EFI     <-- a copy of Fedora's signed Shim installed by sys-boot/shim, copied from /usr/share/shim/
/boot/EFI/gentoo/grubx64.efi     <-- a renamed copy of the compiled Gentoo kernel, copied from /boot/vmlinuz-5.15.75-gentoo
/boot/EFI/gentoo/mmx64.efi       <-- a copy of Fedora's signed MokManager installed by sys-boot/shim, copied from /usr/share/shim/

Then, the File() part of the boot entry should be File(\EFI\gentoo\BOOTX64.EFI)

Yes, when you uprgrade or recompile your kernel with a changed configuration, you need to copy the new /boot/vmlinuz-version-gentoo file to /boot/EFI/gentoo/grubx64.efi.
_________________
NeddySeagoon wrote:
I'm not a witch, I'm a retired electronics engineer :)
Back to top
View user's profile Send private message
Banana
Veteran
Veteran


Joined: 21 May 2004
Posts: 1015
Location: Germany

PostPosted: Mon Nov 28, 2022 11:21 am    Post subject: Reply with quote

Finally, GDH-gentoo thank you very very much! :D Great responses and good explenations. Well done!

I can boot my Gentoo installed on an external USB Stick. To summarize:

  • booted with a Live USB Image which can handle SecureBoot enabled. Like Debian or Fedora
  • Did the official install but BEFORE reboot:
  • - kernel with efi stub
  • - no grub or lilo
  • - installed efibootmgr (as mentioned in the docs) and added a new entry (make sure to use the right partition number. I think the docs use a wrong one)
  • - installed shim pakage and copied the needed files
  • - made sure the new kernel image is copied to grubx64.efi


Did the usage of mokutils result of my errors or is this a needed step in this kind of situation?

Next step: Try to partition the nvme on which windows is on.
_________________
My personal space
My delta-labs.org snippets do expire
Back to top
View user's profile Send private message
GDH-gentoo
Veteran
Veteran


Joined: 20 Jul 2019
Posts: 1002
Location: South America

PostPosted: Mon Nov 28, 2022 1:08 pm    Post subject: Reply with quote

Banana wrote:
Finally, GDH-gentoo thank you very very much! :D

And thank you for providing a testing environment :) I was quite confident that Gentoo had to work with the Shim, but couldn't try it myself so far.

Banana wrote:
Did the usage of mokutils result of my errors or is this a needed step in this kind of situation?

It is a needed step. Note that you didn't have to create a machine owner key and sign your kernel with it, as Rod Smith's website describes. That's because you put the Shim in "insecure mode", and that is a two-step procedure:

1) BEFORE reboot, requesting insecure mode from Gentoo's chroot with mokutil --disable-validation, and creating a password.

2) AFTER reboot, confirming insecure mode from MokManager's "Change Secure Boot state" menu item, and providing 3 random characters from the password set in step #1.

You were able to do step #1 successfully, but had problems doing step #2:
  • You couldn't do it initially when booting Gentoo, I assume, because the EFI System Partition of Gentoo's disk had the wrong directory structure —in other words, mmx64.efi was there, but in the wrong place—, OR you told the UEFI firmware to boot the incorrect PE32+ file.
  • You couldn't do it with Debian's live medium, because it doesn't provide the MokManager —in other words, mmx64.efi wasn't there—.
  • You could complete the procedure with Fedora's live medium.

Banana wrote:
Next step: Try to partition the nvme on which windows is on.

If you do this, you don't have to do the mokutil --disable-validation step again. Insecure mode stays enabled on this computer until you manually disable it.
_________________
NeddySeagoon wrote:
I'm not a witch, I'm a retired electronics engineer :)
Back to top
View user's profile Send private message
Banana
Veteran
Veteran


Joined: 21 May 2004
Posts: 1015
Location: Germany

PostPosted: Tue Nov 29, 2022 7:09 am    Post subject: Reply with quote

Quote:
If you do this, you don't have to do the mokutil --disable-validation step again. Insecure mode stays enabled on this computer until you manually disable it.

Good to know. Windows 11 still does work and I've managed to resize the nvme, install gentoo on it and boot. Yay :-)

Gonna do a tl:dr or maybe a wiki page about it. Also the example partition number used in the install docs for the boot partition is wrong. Need to create a wiki account first. (talking about the gentoo wiki)

EDIT:
I hope those CVEs do not effect the shim packages:
https://twitter.com/ESETresearch/status/1597227770626523136
https://twitter.com/ESETresearch/status/1590279782318878720
_________________
My personal space
My delta-labs.org snippets do expire
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Installing Gentoo All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum