Boot stops at the point where a luks passphrase is requested. Instead it’s just a blank screen.
I note that mkinitcpio.conf changed recently, maybe this is involved, I don’t know,
Sort of fixed.
I’ve got a bootable system again by adding sd-encrypt to the HOOKS array in mkinitcpio.conf. It should go between block and filesystems. This will give me a text version of the luks passphrase reqest at boot.
However, in the past I had a graphic version, I tried putting amdgpu in the MODULES array but no luck (yes, I regenerated the initramfs with imine-mkinitcpio (I think this is the correct way to do it).
And now fixed, hope this will help someone else. I needed to add plymouth to the HOOKSarray as well. I added it after systemd.
Did you by any chance overwrite your mkinitcpio.conf with mkinitcpio.conf.pacnew prior to having an unbootable kernel image?
Not exactly, I looked at the changes with pacdiff -s and I saw that udev had changed to systemd. I didn’t notice that encrypt and plymouth had disappeared so I accepted the change reasoning that I never set this up in the first place, so I trusted the update to work the same.
So yes, mea culpa.
Hi,
Can you go more in depth into the solution? I’ve recently updated the kernel from 7.0.3-1 to 7.0.5-1 and I had the same issue, I could not boot into the system (It wouldn’t even ask for the encryption password). I could boot into the system by loading one of the previous Limine snapshots. I’m not a Linux expert so extra information is very welcome.
You need to edit /etc/mkinitcpio.conf. Find the line that begins with HOOKS= and add plymouth and sd-encrypt into the list of modules on that line. Position is important, so check what I wrote earlier. To give you an idea, here’s the line from mine:
HOOKS=(base systemd plymouth autodetect microcode modconf kms keyboard sd-vconsole block sd-encrypt filesystems fsck)
Save the file then run:
sudo limine-mkinitcpio
Hopefully, that should get you booting again.
*edit
Once you’ve done this you should be safe to update the kernel to the latest.
Thanks a lot, it solved the problem!
If you have the time and energy, I was wondering:
- What steps did you follow to troubleshoot the problem?
- What made this change? Is it evitable or was it a bug from the latest update?
Have a nice weekend!
Great! Glad to help.
What steps did you follow to troubleshoot the problem?
That’s harder to answer than it seems. Although I’m new to Cachy I’ve been using Linux since 1999, and I’ve learned a lot in that time, using distros like Linux From Scratch and Gentoo helped me to understand quite a lot about the internals. Things have changed over time but it was clear to me that the initial ram filesystem was the most likely place to look. This is created when you run limine-mkinitcpio, and this uses the configuration in /etc/mkinitcpio.conf. So, I looked there and realised there was no hook for encryption, hence the boot process couldn’t decode the header of the encrypted volume and hung.
Sorry, I know this is not really that helpful to you but it really was experience that got me to where I needed to be.
What made this change? Is it evitable or was it a bug from the latest update?
There was a recent update to the mkinitcpio package and this installed /etc/mkinitcpio.conf.pacnew. Which is the updated version. Pacman doesn’t just overwrite conf files because you may have made changes that need to be merged, instead it installs these .pacnew files. I guess you must have copied the .pacnew file over the old .conf file, so the next time the kernel is updated a new initramfs is generated using this conf file. Trouble is the new conf file lacked those modules. I have no idea why they’re not included by default, they seem sensible to have in the file, even if they’re not needed.
Have a look at the pacdiff command, it helps you to merge these .pacnew files with your existing file but you do need to be careful doing it (as I proved!).