Does that make kernel updates a more manual process? Are you building your own? Are you signing and using secure boot?
I'd be interested in giving this a try.
I'd be interested in giving this a try.
Kernel upgrades are just copying .config from the old kernel to the new kernel.
sudo make olddefconfig && sudo make && sudo make modules_install && install_kernel
The contents of install_kernel
KERNEL=`readlink /usr/src/linux`
NUMBER=${KERNEL##linux-}
NUMBER=${NUMBER%%-gentoo}
sudo cp arch/x86_64/boot/bzImage /boot/EFI/Gentoo/vmlinuz-${NUMBER}-gentoo.efi
sudo efi bootmgr -c -L "Gentoo ${NUMBER}" -l "\\EFI\\Gentoo\\vmlinuz-${NUMBER}-gentoo.efi" -d /dev/nvme0n1
Yet if you don't use sudo, some make/compiles fail with random permissions errors.
I mean I see the reasoning, but in 2020 I think the Linux desktop security model is sufficiently broken that it doesn't matter.
In Debian/Ubuntu it should be on by default, and has been for almost a decade:
https://askubuntu.com/questions/510009/does-the-ubuntu-kerne...
That means you can run your kernel directly as a UEFI-target and it will support secure-boot.
EDIT: I managed to create the target, with efibootmgr and boot it partly but it panics. I assume that's due to FDE so I'll have to look into how to configure it to support that (if it's possible without a bootloader).
A linux-aware bootloader will usually load the initramfs itself and pass linux the memory address where it's loaded, in UEFI the kernel gets "executed" like a normal executable, so it has a commandline but not a pre-loaded initramfs.
My efibootmgr entry looks like this (root is btrfs on LUKS):
HD(disk-id)/File(\vmlinux-5.6.0-2-rt-amd64) initrd=\initrd.img-5.6.0-2-rt-amd64 ro root=/dev/mapper/cryptpv0