[SOLVED] UKI and Secure Boot with kernel-install...

ectospasm · 2024-01-18 04:29:51

SOLVED: So, to fix this all I had to do was install systemd-ukify. I didn't realize until a few minutes ago that it's a separate package. I wonder why it was working before?

I'm installing the standard Arch package linux, and prior to 6.7.0-arch3-1 my setup was fine (6.6.x). This is a fairly new laptop installation, and here's how it's set up:

I'm using kernel-install, with sbctl for signing the resulting UKI images. I haven't specifically configured the uki_generator, so I think it defaults to ukify. My ESP is mounted at /efi, and when I rebooted after installing 6..7.0-arch3-1, and I was presented with the systemd-boot menu and the only option is to boot the UEFI firmware menu (no kernel). I don't think I really need systemd-boot since I'm supposed to boot the UKI directly (normally the UKI boots without the systemd-boot menu even showing). Since I can't boot, I enabled UEFI Setup Mode so I could boot the Arch ISO.

I entered the arch-chroot, after I booted the Arch ISO and unlocked my LUKS2 container and mounted all my Btrfs subvolumes and ESP. When I check my /efi/EFI/Linux/ directory, it's empty (no UKI and no previous UKIs). So when I reinstall the kernel with pacman from within the arch-chroot, I see the following:

warning: linux-6.7.arch3-1 is up to date -- reinstalling
resolving dependencies...
looking for conflicting packages...

Packages (1) linux-6.7.arch3-1

Total Installed Size:  130.57 MiB
Net Upgrade Size:        0.00 MiB

:: Proceed with installation? [Y/n] checking keyring...
checking package integrity...
loading package files...
checking for file conflicts...
checking available disk space...
:: Processing package changes...
reinstalling linux...
:: Running post-transaction hooks...
(1/6) Arming ConditionNeedsUpdate...
(2/6) Updating module dependencies...
(3/6) Removing kernel and initrd from $BOOT... (kernel-install)
+kernel-install remove 6.7.0-arch3-1 /usr/lib/modules/6.7.0-arch3-1/vmlinuz
/usr/lib/kernel/install.d/91-sbctl.install failed with exit status 1.
(4/6) Installing kernel and initrd to $BOOT... (kernel-install)
+kernel-install add 6.7.0-arch3-1 /usr/lib/modules/6.7.0-arch3-1/vmlinuz
==> Starting build: '6.7.0-arch3-1'
  -> Running build hook: [systemd]
  -> Running build hook: [autodetect]
  -> Running build hook: [modconf]
  -> Running build hook: [kms]
  -> Running build hook: [keyboard]
==> WARNING: Possibly missing firmware for module: 'xhci_pci'
  -> Running build hook: [sd-vconsole]
  -> Running build hook: [block]
  -> Running build hook: [sd-encrypt]
  -> Running build hook: [filesystems]
  -> Running build hook: [fsck]
==> WARNING: Possibly missing '/bin/sh' for script: /usr/bin/fsck.btrfs
==> Generating module dependencies
==> Creating zstd-compressed initcpio image: '/tmp/kernel-install.staging.rD9htf/initrd'
==> Image generation successful
Error: /usr/lib/modules/6.7.0-arch3-1/vmlinuz is missing .efi suffix.
/usr/lib/kernel/install.d/90-uki-copy.install failed with exit status 1.
(5/6) Check if daemons need restart after library/binary upgrades

Failed to retrieve available kernel versions.

The processor microcode seems to be up-to-date.

No services need to be restarted.

No containers need to be restarted.

User sessions running outdated binaries:
 root @ /dev/tty1: arch-chroot[16367], unshare[16382], zsh[749]
 root @ /dev/tty2: zsh[12104]

No VM guests are running outdated hypervisor (qemu) binaries on this host.
(6/6) Signing EFI binaries...
Generating EFI bundles....
File has already been signed /efi/EFI/BOOT/BOOTX64.EFI
File has already been signed /efi/EFI/systemd/systemd-bootx64.efi

Step 5 is from needrestart, so I don't think that's relevant. So the main question I have, in step 4: how do I generate the .efi executable from /usr/lib/modules/6.7.0-arch3-1/vmlinuz? This seems like it should be done by some kernel-install script, and maybe that script is missing or there's been a change so it doesn't get called? I'm not sure which script that would be (I'm still learning a lot of the ins and outs of UKI and Secure Boot).

Last edited by ectospasm (2024-01-20 01:04:05)

cgb_spender · 2024-01-19 01:40:56

Sorry that I cannot suggest something concrete, but I would disable Secure Boot and try installing four kernels simultaneously and test each of them. If some of them get installed successfully, then you can try to re-enable Secure Boot.

ectospasm · 2024-01-20 00:14:52

cgb_spender wrote:

Sorry that I cannot suggest something concrete, but I would disable Secure Boot and try installing four kernels simultaneously and test each of them. If some of them get installed successfully, then you can try to re-enable Secure Boot.

Thank you for your suggestion, but I don't think you understand, or I must misunderstand what you're trying to convey. I had to enable Setup Mode to boot off the Arch ISO. The keys to sign what needs to be signed on the ISO were in my LUKS2 volume, and I can't get to that if there's no kernel to boot from, nor can I boot an unsigned boot image without enabling Setup Mode which is the proper way to disable Secure Boot (if in normal operation you want Secure Boot active).

Let me ask you to clarify: are you suggesting the .efi executable should ship with the kernel package, whether it be linux, linux-lts, or some other kernel package? If that is the case, then I should file a bug against the Arch Linux package (in my case, linux). But I haven't seen any documentation that this is indeed the problem and the proper course of action.

My guess is if you have a standard vmlinuz compressed kernel, it should be straightforward to generate the .efi executable yourself. My problem is this didn't happen automatically as I expected, and I don't know where the deficiency lies. If this (rather than the kernel package) is the proper way to handle this, then ukify (the default uki_generator I'm using) is lacking a script to do so automatically. So I should file a bug against systemd (which ukify is a component of).

I did pose this topic in #archlinux@libera around the same time I posted here on the forums. Someone linked to this bug report, but this isn't my problem (ukify did not place the .efi kernel in /boot; my ESP is mounted at /efi). So not the same root cause, but the overall effect or symptom is the same; i.e., the UKI doesn't get built because the .efi executable can't be found.

ectospasm · 2024-01-20 01:00:36

So I haven't been able to look into this for a few days. I see that systemd-ukify is a separate package, not included with systemd itself. I'm installing it now, and I'll try to install the kernel again. I do find this strange, everything I've read while troubleshooting this suggests ukify is the default uki_generator if you don't specify one (which I'm not). It was working before without it, so this is really weird.

And that worked! Not sure why it was working before, but hot damn I'm a happy man!

Head_on_a_Stick · 2024-01-20 11:45:53

It was working before because the ukify command was part of the systemd package and was called automatically by kernel-install. The new systemd version changed the kernel-install's call to /usr/bin/systemd-ukify but that is only present if the extra package is installed.

I've added the new information to the installation section of the kernel-install ArchWiki page. If this sort of thing happens again it would be great if you could do that yourself next time.

Last edited by Head_on_a_Stick (2024-01-20 11:46:21)

ectospasm · 2024-01-20 15:28:35

Head_on_a_Stick wrote:

I
I've added the new information to the installation section of the kernel-install ArchWiki page. If this sort of thing happens again it would be great if you could do that yourself next time.

Thanks! I was actually planning on doing that today, it was rather late last night when I discovered that systemd-ukify was a separate package. Thanks for getting to it before I could, and I apologize for not doing it right away.

If that didn't work, my other alternative was going to be use mkinitcpio as my UKI generator (uki_generator=mkinitcpio), but this explains very well why it broke. I thought I was on systemd 255.2 when I originally installed this laptop; was the package split out as part of an Arch pkgrel?

ectospasm · 2024-01-20 15:36:41

So yeah, systemd-ukify is still tracked on GitLab as a component of systemd. I didn't originally install this laptop until December 27, so it looks like it would have been version 225.2-2 originally installed. I don't see a specific change splitting systemd-ukify as a separate package; though an earlier change suggests it had already been split out.

I'm at a loss for why it was working before, unless I'm just missing the change that split it out.

ectospasm · 2024-01-20 15:58:57

Oh, I see. Kernel-install has its own wiki article. I don't think I ever saw that; the notice that the UKI#kernel-install section is a candidate for merging into the standalone wiki article didn't appear until January 9, 2024. I had started drafting my plan to install this laptop as far back as September 2023 (when my new laptop actually arrived), so there was no way I could know that (unless I searched for "kernel-install" directly).

Head_on_a_Stick · 2024-01-20 16:11:02

My apologies, looks like I was completely wrong in my last post. I was under the impression only the most recent release had split ukify out to a separate package but that isn't the case at all. Sorry for the noise.

ectospasm · 2024-01-20 16:23:07

Head_on_a_Stick wrote:

My apologies, looks like I was completely wrong in my last post. I was under the impression only the most recent release had split ukify out to a separate package but that isn't the case at all. Sorry for the noise.

Oh, no worries at all! When I started on this UKI journey, I had no idea it was so new. ukify was only listed as non-experimental in systemd 255 if I'm reading things correctly, which is the current stable major version.

This is what we get for being bleeding edge!

Erus_Iluvatar · 2024-01-20 17:37:19

ectospasm wrote:

I wonder why it was working before?

It's actually the release 37.2 of mkinitcpio that includes a change which makes it only run when it's set as the generator, instead of running in all cases previously.

Arch Linux

#1 2024-01-18 04:29:51

[SOLVED] UKI and Secure Boot with kernel-install...

#2 2024-01-19 01:40:56

Re: [SOLVED] UKI and Secure Boot with kernel-install...

#3 2024-01-20 00:14:52

Re: [SOLVED] UKI and Secure Boot with kernel-install...

#4 2024-01-20 01:00:36

Re: [SOLVED] UKI and Secure Boot with kernel-install...

#5 2024-01-20 11:45:53

Re: [SOLVED] UKI and Secure Boot with kernel-install...

#6 2024-01-20 15:28:35

Re: [SOLVED] UKI and Secure Boot with kernel-install...

#7 2024-01-20 15:36:41

Re: [SOLVED] UKI and Secure Boot with kernel-install...

#8 2024-01-20 15:58:57

Re: [SOLVED] UKI and Secure Boot with kernel-install...

#9 2024-01-20 16:11:02

Re: [SOLVED] UKI and Secure Boot with kernel-install...

#10 2024-01-20 16:23:07

Re: [SOLVED] UKI and Secure Boot with kernel-install...

#11 2024-01-20 17:37:19

Re: [SOLVED] UKI and Secure Boot with kernel-install...

Board footer