For that you’ll need after = [ ... "local-fs-pre.target" ]; (or just systemd-hibernate-resume.service, but local-fs-pre.target is just a more generic target for “after things that have to happen before file systems”), because systemd-hibernate-resume.service is the thing that actually resumes the system from hibernation
3 Likes
Oh, this is not what you want, sorry; thought I should clarify that. The resume kernel param is not the sole thing that determines whether the system resumes from hibernate, and the resume param can be present when the system won’t have anything to resume from. So yea, what I said before about ordering after systemd-hibernate-resume.service / local-fs-pre.target is the right thing to do.
But yea, I think the rest looks fine, and I’m happy to help 
2 Likes
Thank you for your insight!
I’ve noticed that ever since I’ve migrated to this setup, my Plymouth screen will occasionally get skipped. I’m using LUKS, so instead of the Plymouth password prompt, I’m shown the TTY prompt instead. Can this service somehow interfere with Plymouth in some way?
Since I have after = [ “initrd-root-device.target” ], I believe that the service should only run after the device is decrypted (e.g., /dev/mapper/root) which happens after Plymouth, but I’m not sure.
Yea I would not think that would interfere with Plymouth at all. Might need to look at some logs to figure out what’s going on there.
Hello,
I am not sure this is the right place to ask but are there any later modifications related to using the systemd boot process that might explain a change of behavior related to LUKS password retries when resuming from hibernation?
Until recently, when I typed a bad password on hibernation resume, I was asked to type the password again. But lately, it started switching to the emergency console and resuming from this step basically starts a new boot process.
To detail a bit more my configuration, LUKS currently encrypts my whole LVM PV which contains the swap device used for hibernation. I am using this layout for a few years now (see this github repo if you need more insight).
Again, my apologies if this is not the right place to ask, I can start a new thread if needed but as soon as I realized that boot.initrd.systemd.enable is now turned on by default, I noticed this thread.
EDIT: I just updated to the latest nixpkgs master and the behavior is now slightly different. It asks for the password again on error, if this second try fails, then the emergency console is started.
@gautaz At least some of that behavior is due to upstream systemd issues. See:
- systemd-cryptsetup: cached passwords should not count against tries · Issue #42103 · systemd/systemd · GitHub
- cryptsetup: Invalidate ineffective try_discover_key before trying by ElvishJerricco · Pull Request #42102 · systemd/systemd · GitHub
These can result in the user being prompted as few as one time instead of the intended three times, in some cases. You can set boot.initrd.luks.devices.<name>.crypttabExtraOpts = [ "tries=5" ]; as a workaround to gain more attempts before dropping to emergency mode.
You may need to add x-systemd.device-timeout=infinity to the fileSystems.<name>.options and swapDevices.*.options. systemd has no way to realize that the LVM volume group you’re using depends on the LUKS device, so those can timeout looking for them while waiting for a correct passphrase to be entered for LUKS.
3 Likes
Thank you so much @ElvishJerricco for your guidance!
I didn’t even realize that there was a timeout that could be reached during the LUKS password entry.
I have waited for it as a test and in fact it occurs after a few minutes.
Deactivating this timeout as you proposed solves the issue but it seems that it also removes the ability to reach the emergency console (I’ve kept the fix though).
As for the number of LUKS pw tries, I have also implemented your fix and it works pretty well 
.
Hm how so? The emergency mode should still work; it just won’t be launched unless a fatal error occurs (which the timeout was). You can go to it by force with rd.rescue on the kernel params.
As the systemd timeout is infinite on the LVM physical volume, it seems that the boot process never reaches the emergency console, it continues waiting for the device.
That’s at least the behavior I had if I enter only wrong passwords, I should probably check again, I may have misunderstood what was happening.
Right. Well, I assumed you didn’t want it to fail timing out waiting for you to enter a disk encryption passphrase, since that’s the typical behavior on most distros and on NixOS. The emergency mode is for fatal errors, and the user waiting a long time to enter their disk encryption password isn’t a fatal error. But like I said, you can trigger going to emergency mode with the rd.rescue parameter.
If you enter wrong disk encryption passwords, it should fatally fail and go to emergency mode after the number of tries configured with the tries= option I mentioned earlier.
2 Likes