How can I access the boot logs in this situation? Setting rescue systemd.setenv=SYSTEMD_SULOGIN_FORCE=1 in the kernel parameters just gives me a prompt that doesn’t accept any input.
It’s rd.rescue for stage 1
Just SYSTEMD_SULOGIN_FORCE=1 works, though it seems systemd.setenv=SYSTEMD_SULOGIN_FORCE=1 also works.
The prompt on the screen is telling you to press enter 
Still nothing. 
No input from any key, and Enter just gives me the same prompt.
Is it prompting the same thing again, or just staying at the same prompt? If it’s staying at the same prompt, I wonder if the keyboard input isn’t going through. If it’s prompting the same thing again, do you have boot.initrd.systemd.emergencyAccess set or something?
Repeated prompts; I think it’s in the previous screenshots. And no, emergency access isn’t set, i.e., it’s false.
That’s pretty odd. It looks like you’re getting the Control-D behavior where it just tries the boot again. Now, it would also do that if the shell you would enter exits, but that wouldn’t make sense. Unless… you didn’t do something like boot.initrd.systemd.users.root.shell = "/bin/systemd-tty-ask-password-agent"; or anything, did you?
Would you look at that! That’s exactly what I did! … Plus the /usr at the beginning of the path. I think it was in one of the guides I saw? Or maybe it was a separate guide. Should I remove that option? Would I not need it for zpool password prompts or similar?
I think some wiki page somewhere may have recommended something like that at some point. But it’s not a good recommendation because the shell is used for more than just entering a disk encryption passphrase (as you’ve discovered here). In the past, people have recommended setting up remote disk unlock by enabling SSH in initrd and setting the root user’s shell up so that a remote client only has the ability to enter the password. But the shell is the wrong layer to do that at, because the shell is useful for more than remote login. To just restrict what remote clients can do, it makes more sense to use the SSH feature designed for exactly that: an authorized key can begin with command=... to make it so that, when that key is used to login, it only runs that command. That’s why the assertion that tells people to stop doing shell = "/bin/cryptsetup-askpass"; recommends this: nixpkgs/nixos/modules/config/users-groups.nix at ee86b0906c817298203746446ee5ca27e4d1ac35 · NixOS/nixpkgs · GitHub
2 Likes
Changing this did the trick. Is there a warning for setting the root shell to that password agent?
There is not; the assertion about cryptsetup-askpass was added because that is a known common pattern in scripted stage 1 that we wanted to head off with users being transitioned from scripted stage 1 to systemd stage 1; the same with systemd-tty-ask-password-agent was not expected to be common.
If it’s still being recommended for zfs root setups, though, should it be added if the root is on zfs?
Where do you see it recommended for ZFS setups?
Hmm… In retrospect, it might’ve been for secret management reasons… Fair enough. Either way, thanks for all the help!