I’m using Gentoo with systemd and a customized kernel, and additionally I have the /usr partition LUKS encrypted.
Because /usr is absolutely essential for systemd to function, I configured dracut to make a specially crafted initrd which activates the luks lvm and prompts for the password to decrypt and mount /usr on startup before systemd init tries to run.
About a year or two ago, some update to dracut or some other dependency (assumption) caused the dracut generated initrd’s to kernel panic. After multiple days of troubleshooting, I discovered that just copying forward an older initrd in /boot and naming it to match the new kernel, e.g. initramfs-6.6.38-gentoo.img , allows the system to boot normally .
So, my Gentoo is booting a kernel 6.6.something with a ramdisk generated in the 5.9 kernel era. I am dreading the day when this behavior breaks and I can no longer update my kernel 😳
I’m using Gentoo with systemd and a customized kernel, and additionally I have the
/usr
partition LUKS encrypted. Because/usr
is absolutely essential for systemd to function, I configured dracut to make a specially crafted initrd which activates the luks lvm and prompts for the password to decrypt and mount/usr
on startup before systemd init tries to run.About a year or two ago, some update to dracut or some other dependency (assumption) caused the dracut generated initrd’s to kernel panic. After multiple days of troubleshooting, I discovered that just copying forward an older initrd in
/boot
and naming it to match the new kernel, e.g.initramfs-6.6.38-gentoo.img
, allows the system to boot normally .So, my Gentoo is booting a kernel
6.6.something
with a ramdisk generated in the5.9
kernel era. I am dreading the day when this behavior breaks and I can no longer update my kernel 😳