Multiple UKIs with mkinitcpio?

Support System Updates
1

I modified the vanilla manjaro installation to use shim + systemd-boot in order to get secure boot working to comply with my comanies PC policies. In order to do that I used Unified Kernel Images as per arch wiki.

I know that mkinitcpio comes with a pacman script to generate .preset files (/etc/mkinitcpio.d/<kernel base>.preset) which is placed under /usr/share/libalpm/scripts/mkinitcpio and called by the according pacman hook after updates to certain usr/lib directories and of course /usr/lib/modules/*/vmlinuz. Since I want to have a fully automated setup when I install a newer kernel I edited /usr/share/mkinitcpio/hook.preset (which is used by the mkinitcpio script to generate the actual presets). But this file is changed by pacman during updates to mkinitcpio.

Now my question is: Is there an easy way to automate the process of installing new kernel images while using UKIs? I know there is this special /etc/mkinitcpio.d/linux.preset which won’ be overwritten during updates to the mkinitcpio.d package but this will only allow me to have a single kernel present since there are no placeholders for the kernel version.

2

I speculated - as I use an encrypted root and verifying boot by enrolling the certificate in TPM using secureboot - do I really want to maintain more than one kernel?

I came to the conclusion - I do not want that.

Yes - that is how it works.

If you want to override use /etc/mkinicpio.d.

I use a somewhat similar setup - by using sbctl to generate a signed efistub with a generic name which I symlink to the kernel I am using - usually LTS.

1 Like
3

Yes, you can add a line to pacman.conf:

NoUpgrade = usr/share/mkinitcpio/hook.preset

This prevents mkinitcpio updates from overwriting or resetting your custom hook.present.

However, this is not recommended, as major mkinitcpio changes could break compatibility with your permanent custom config without you realizing where a issue is.

1 Like
4

However, this is not recommended, as major mkinitcpio changes could break compatibility with your permanent custom config without you realizing where a issue is.

Yeah I’m not sure I want to do that :'D

@linux-aarhus:

I use a somewhat similar setup - by using sbctl to generate a signed efistub with a generic name which I symlink to the kernel I am using - usually LTS.

How do u symlink the kernel? Any scripts u can share? With the linux-xxx packages the kernel that’s installed will have a suffix (e.g. vmlinuz-6.12) for the version which won’t work with a .preset that references a generic name (vmlinuz)

5

The process is documented with [root tip] [Utility Script] Encrypted Manjaro Linux using Verified Boot

I know I can do better - thus I have a long term intention of revisiting this - possibly improving - but not having the time to do it yet.

You know - when you have a working setup - it can always wait :slight_smile:

My $esp is mounted at /efi and boot is inside a luks encrypted volume

 $ lsblk -f
NAME        FSTYPE      FSVER LABEL  UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
loop0       crypto_LUKS 2     fh     a14cc19c-f9cd-48a8-9e9a-7a731a5032a5                
└─home-fh   btrfs             fh     f83e721d-8233-4af6-a964-3416a99ae2a8  245,3G    13% /home/fh
nvme0n1                                                                                  
├─nvme0n1p1 vfat        FAT32 EFI    B867-3C85                             371,7M    27% /efi
├─nvme0n1p2                                                                              
│ └─swap    swap        1     swap   924417a5-5b5a-4d07-9d45-2bdef04f1c47                [SWAP]
└─nvme0n1p3 crypto_LUKS 2            a79fc6ed-c0ba-4c85-9301-88e273a19daf                
  └─system  btrfs             system 8f8a0469-0d6d-4f10-adb6-fb397e4afe01  108,1G    75% /home
                                                                                         /

I don’t use grub - I don’t use systemd-boot - instead I have a unified kernel named main.efi

 $ ls -l /efi
total 142492
drwxr-xr-x 3 root root      4096 Jan 23 10:04 EFI
drwxr-xr-x 2 root root      4096 Feb 20 12:46 loader
-rwxr-xr-x 1 root root 145903224 Feb 20 08:14 main.efi

main.efi is generated by sbctl - by unifying the files vmlinuz-linuxand initramfs-linux.img and this is where the symlink comes in.

Only when I need to switch kernel - like from 6.6LTS to 6.12LTS - I change the symlink reference.

 $ ls -l /boot
total 271492
-rw-r--r-- 1 root root    153600 Feb 12 01:25 amd-ucode.img
-rw------- 1 root root 132018654 Feb 20 08:14 initramfs-6.12-x86_64-fallback.img
-rw------- 1 root root 132018654 Feb 20 08:14 initramfs-6.12-x86_64.img
lrwxrwxrwx 1 root root        25 Feb  2 08:44 initramfs-linux.img -> initramfs-6.12-x86_64.img
-rw-r--r-- 1 root root        22 Feb 18 21:10 linux612-x86_64.kver
-rw-r--r-- 1 root root  13793912 Feb 20 08:14 vmlinuz-6.12-x86_64
lrwxrwxrwx 1 root root        19 Feb  2 08:44 vmlinuz-linux -> vmlinuz-6.12-x86_64

There is no magick or scripting involved - my scripting dates back to earlier sbctl so I could utilize the sbctl configuration to achieve the same thing (/var/lib/sbctl) - that is what I meant above - the improving by looking closer into - that I have not got around to do.

I linked below resources in another thread on secure boot using repo only

See → Unified Extensible Firmware Interface/Secure Boot - ArchWiki
See → Unified kernel image - ArchWiki
See → GitHub - Foxboron/sbctl: 💻 🔑 Secure Boot key manager

1 Like
6

All right thanks so far @linux-aarhus :slight_smile: The part about the symlinking is the one that I want to automate since I know I’ll forget about that when switching to a new kernel :'D

I’ll move this problem to future me since I don’t have time for that now. I’ll update the post when I find a solution.

7

Ignore the symlinking - use this PoC instead - it is much simpler this way

8

Yes I saw that (I think I even stumbled upon that in my initial research) in your former post but unfortunately I’m on a Lenovo Thinkpad T14, which, last time I checked the lenovo support forums, might break if one uses custom secure boot keys :frowning:

Edit: found the link here Reports of custom secure boot keys bricking recent X, P, and T series laptops

Btw I think a disclaimer for this would be nice in your tutorial that enrolling custom secure boot keys can brick some laptops.

9

Hmm - I cannot say if it is valid or it just boils down to incorrect handling.

The topic you linke is from October 2021 - I think they have fixed the issue by now.

I use a Thinkpad X13 AMD gen4 - removed all keys from Secure Boot and added my own.

I did same thing with a Tuxedo InfinitiBookPro 14.

No problems encountered.

I could add but the warning would only be applicable if you do not enroll microsoft keys using the –microsoft argument.

Just scrolling over the topic you linked - it looks like systems where the Key Management does not exist in the firmware are the ones which may brick.

10

Okay you’re right seems I misread. It’s only an issue when you replace all the keys including Microsoft’s and only using your own.

Thanks for the link I’ll give it a try :slight_smile:

11

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.