… never touch a running system - but I’d like to see how this is done
I can try often and can easily recover from failed attempts using chroot/systemd-nspawn to revert any non-working change.
… as I tried four times already, with different arrangements/different order of the parameters in /etc/mkinitcpio.conf
Perhaps someone has done this/has got this working?
The task seems to be more complex than just to adapt the HOOKS in /etc/mkinitcpio.conf
When I boot, I don’t get a prompt to input my password to unlock the encrypted container.
I have a UEFI system with two partitions.
Grub is my bootloader. /dev/sda1 is unencrypted /boot /dev/sda2 is the LUKS encrypted rest of the system - no LVM inside it
Here is the relevant part of my /etc/mkinitcpio.conf :
the commented line is the one I tried and which is not working
the first line is the flawlessly working configuration - but without systemd HOOKS
It seems that there is something to be done to/with /etc/crypttab
… which I didn’t need so far
It is there, I have that file, but just with default content all commented out.
I have been educating myself on encrypted systems - but it is a while ago - I don’t have the need but gaining knowledge - even if unusable - has always been something
For what I know - the sd modules is only needed when you use systemd-boot.
But from my reading and my experiments the order in which they appear in mkinitcpio.conf is important.
I didn’t catch anywhere in the Arch documentation that these systemd HOOKS are to be used with booting via systemd-boot only.
But that might be reason why they don’t work with Grub.
Maybe I’ll better try that in a VM instead of on my real system first.
Exchanging Grub for systemd-boot is not something I’d want to do - I know it works, but it is not as well integrated and as easy to maintain when upgrading/installing kernels.
That’s what I remember having read.