Systemd hooks in initramfs, boot a system with encrypted root, unencrypted /boot - no passwd prompt

… 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

HOOKS=(base udev autodetect modconf block encrypt filesystems shutdown keyboard resume)
# HOOKS=(base systemd autodetect modconf block keyboard sd-vconsole sd-encrypt filesystems fsck)

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.

dm-crypt/System configuration - ArchWiki

I can’t really make heads or tails of it - not yet.
If that’s even the right info to consider to get this to work …

That is why I ask whether someone already has such a setup working.

Thank you for reading - I hope I made my issue clear.
It’s nothing urgent.
If someone knows something, please share!

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 :slight_smile:

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.

E.g. this works for GRUB

HOOKS="base udev encrypt block keyboard autodetect modconf filesystems fsck"

If you use systemd-boot you need something like this (the order of precedence is important)

HOOKS="systemd keyboard keymap sd-vconsole block sd-encrypt autodetect modconf filesystems fsck"

My notes is either in the archived forum or on root.nix.dk

Thank you!
I shall read through your notes.

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.

Thank’s again!

I figured it out.
It now works.
It’s a different syntax in the boot loader config when you want to use systemd HOOKS

If using the “standard” encrypt HOOKS

Grub config looks like this:
GRUB_CMDLINE_LINUX="cryptdevice=UUID=73213ab9-5c8c-4c2a-a397-aa321ebfd4ec:cryptroot ro"
the corresponding /etc/mkinitcpio.conf
HOOKS=(base udev autodetect modconf block encrypt filesystems shutdown keyboard resume)

If using the systemd HOOKS

Grub config looks like this:
GRUB_CMDLINE_LINUX="luks.name=73213ab9-5c8c-4c2a-a397-aa321ebfd4ec=cryptroot ro"
the corresponding /etc/mkinitcpio.conf
HOOKS=(base systemd autodetect modconf block sd-vconsole sd-encrypt filesystems fsck)

cryptdevice=UUID=73213ab9-5c8c-4c2a-a397-aa321ebfd4ec:cryptroot
vs
luks.name=73213ab9-5c8c-4c2a-a397-aa321ebfd4ec=cryptroot

As a bonus, you get some feedback (stars) while typing in the password …

1 Like

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