In the interest of maximizing battery life, I’ve set up suspend-then-hibernate on my laptop. Using a discrete window manager, so I have a systemd unit that locks the screen when I close the lid. After an hour, it automatically goes into hibernation.

All is well, until I have to boot up from hibernation. I’m prompted to unlock LUKS, then I’m hit with a redundant lock screen once resumed. I’ve tried setting up systemd units referencing suspend-then-hibernate.target and hibernate.target, but I can’t get it to kill the screen locker when resuming from hibernation only, so I don’t have to type in my password twice. Is there any way to have systemd discriminate between the suspend and hibernate parts of suspend-then-hibernate?

  • @just_another_person@lemmy.world
    0•7 hours ago

    You don’t want anything like what you’re attempting.

    1. Bypassing either password challenge for simplicity’s sake is just defeating the purpose of having LUKS on the full disk anyway. Just encrypt your home of that’s a problem for you and simplify things.
    2. Killing your lock screen from the session manager is going to cause all kinds of problems, so that’s not going to help. It’s not JUST a plain old process to kill, it’s the session manager. You kill it, and it’s going to ask you again anyway, and likely destroy your existing session.

    Instead, look into Clevis. Pair it with your TPM, and set it to handle the lower level LUKS challenge. Learn about it to understand the tradeoffs in security, but it’s going to be more secure than what you’re attempting.

    • monovergentOP
      1•6 hours ago

      This is for a SeaBIOS system without functional TPM.

      Bypassing either password challenge for simplicity’s sake is just defeating the purpose of having LUKS on the full disk anyway. Just encrypt your home of that’s a problem for you and simplify things.

      Could you explain this? I do not see how it would compromise the security model since the lock screen would be dismissed only after the LUKS password is entered. The screenlocker is only relevant when suspended to RAM as the LUKS key is no longer in RAM once hibernated.

      Killing your lock screen from the session manager is going to cause all kinds of problems, so that’s not going to help. It’s not JUST a plain old process to kill, it’s the session manager. You kill it, and it’s going to ask you again anyway, and likely destroy your existing session.

      I am using slock, which is separate from my session manager (startx in ~/.profile), and in my testing, I was able to kill it without issue.

      • jutty
        2•6 hours ago

        If killing your lock screen unlocks the system, that signals there is actually little protection. Killing a lock screen should kill the session and log you out, or at least render the session unusable.

        If you still want to go that route, you could wrap your hibernation process in a script or use a slightly more complex service setup to kill it once, by inspecting system/service state and enqueued systemctl operations, you determine hibernation is done (not pending)

      • @just_another_person@lemmy.world
        1•6 hours ago

        If you don’t care about the session manager password challenge, then set it to allow you to automatically login. Then you only have the LUKS challenge, and if you’re comfortable with that, go for it.