Arch Linux

gcb

Member

Registered: 2014-02-12

Posts: 212

system crash when removing luks key device

All manuals I could find say the key is not needed after unlocking and the faster it is removed from other memory the better, but:

I have one server I unlock using a external USB device with a simple key. I wanted just to have something that easily allows it to boot, and attacks involving someone stealing the pendrive from my keychain are negligible.

kernel options have:

rd.luks.key=luks_uuid=/file.key:UUID=pendrive_partition_uuid

https://wiki.archlinux.org/title/Dm-cry … .luks.name

it works perfectly. But when i remove the pen drive, in a time between 15min and 8h, the host will simply shutdown (never got anything on logs because it only have local log and full disk encryption

I noticed that systemd REMOUNTS the key filesystem after boot (i.e., it mounts, get the key, unmounts, unlock root, boot and then mounts it again). Is this a known issue to work around whatever is causing this? anyone know where it is documented?

gcb

Member

Registered: 2014-02-12

Posts: 212

Re: system crash when removing luks key device

bump. Anyone knows why LUKS keep needing the keys after it is mounted?

I'm trying to avoid setting up remote/extra drives for logs just to debug this one issue

Strike0

Member

From: Germany

Registered: 2011-09-05

Posts: 1,489

Re: system crash when removing luks key device

You use "crash" (unclean) in the title and "system shutsdown" (clean) in verbose, that's contradictionary and in both cases there must be a tail in the journal which may give hints what went wrong - it could be unrelated.

When you setup the system, did you manually unmount the usb before unplugging it? This because it should refuse to unmount, if the pendrive is referenced anywhere. (When you do this test, the results may be useful for the bug report).

In any case, you can perhaps simply work-around by using one keyfile in /etc/ for the system crypttab, and use your pendrive as another keyfile for the initramfs. This way you get the protection and convenience when it's powered off (pen needed), but after unlocking systemd can access the /etc keyfile. edit: just make sure your setup does not copy the /etc keyfile into the initramfs, of course.

Last edited by Strike0 (2024-10-09 17:40:05)

gcb

Member

Registered: 2014-02-12

Posts: 212

Re: system crash when removing luks key device

there must be a tail in the journal...

I wish. Since it is using full disk encryption, a failure on luks means I get absolutely nothing on any journal or logs.

When you setup the system, did you manually unmount the usb before unplugging it?

Doesn't matter. Crash/SilentShutdown happens if it is unmounted, regardless of me unmounting it or simply removing the device. End result is the same. I moved some comments to a systemd bug that seems to be added by someone who knows why this behaviour happens but instead added a "remount" step surreptitiously instead of documenting things... https://github.com/systemd/systemd/issues/28021

The keyfile in etc is a nice workaround for my specific use-case! thank you for suggesting it!

Strike0

Member

From: Germany

Registered: 2011-09-05

Posts: 1,489

Re: system crash when removing luks key device

To clarify: the kernel device-mapper (cryptsetup backend) will refuse to unmount a device if there is anything left open. So, if you can manually unmount the pen after the system has fully booted, that proves the point of the systemd-cryptsetup autogenerator being culprit. The work-around of using .service files basically means you disable the autogenerator by setting up your specific unit. While this may sound good, I'm not sure how much it breaks for rolling updates to the bootchain.

What you might want to add to the systemd bug is to show the manual unmount of the pen exits cleanly in the booted system. Also note journalctl has a --flush operation, which will write the journal to persistent storage. Hence, if you (1) open a terminal with journalctl --follow (2) manually unmount the pen and watch the journal record it, (3) execute journalctl --flush,
and the system keeps running - that journal excerpt may be useful for the systemd bug.