Hi there,
I installed Nixos about 5 times today, without any errors that I noticed. Installation ends with the prompt for the root password, which I enter normally. However, I cannot login after reboot using this root password. I have gone from a complicated password at my first attempt to a very simple one like ‘1234abc’ at my last, with no avail. Root cannot login with the correct password. What am I possibly missing?
Is the keyboard actually working? Are you logging in via TTY or a display manager? Some GUI related things refuse root login, though I’m not sure which of the common display managers do.
It may be best to set up a normal user with security.sudo.enable permissions anyway. You’d want to add "wheel" to users.users..extraGroups for this user.
If you then end up just never logging in as root, consider using the --no-root-passwd switch for nixos-install as well. This will disable root login, which is just generally good practice. Your admin user can always sudo -s if you do need a root shell; there is almost never a good reason for logging in as root. Set systemd.enableEmergencyMode to false if you do; you’ll need to use nixos-enter from a live USB to fix drive mounting failures. A better solution for that is in the works from the systemd side.
Be aware that setting users.users..password is a bad idea, use users.users..passwordFile or set it imperatively after installation using nixos-enter.
Just today I set up NixOS on my new primary laptop - no issues logging in as root.
Are you by chance using a different keyboard layout between the installation and the final setup?
Thank you both for your input. I am following the guide here, which includes refreshing root zfs dataset by the additional setting below in configuration file:
{
boot.initrd.postDeviceCommands = lib.mkAfter ''
zfs rollback -r rpool/local/root@blank
'';
}
root@blank is an empty snapshot of root dataset (zfs) and the whole thing relies on replacing the whole root dataset with a blank one with every boot, in order to maintain freshness in the system. Would this possibly be responsible for losing the root password while rebooting after installation? I suspect it is. I am new and don’t truly know what exactly I am doing here, but wanted to follow the footsteps of the author of this guide, since the idea sounded quite attractive to me. I would appreciate even more if you can confirm my suspicions, and point how this may actually be achieved.
Thanks!
If you don’t manage your users declaratively (with users.mutableUsers = false), this will likely destroy/reset your /etc/shadow where your passwords are stored. You need to follow the persistence part of that guide to fix this (not sure if this is all you need to persist, have a look at the diffs).
I would leave the postDeviceCommands part disabled until you are sure that you have all state persisted that you need to start your system. You can always enable this later.
Thank you for your comment @polygon. Indeed, my next installation by leaving this part out worked as intended. I am pretty sure that the persistence part of that guide does not cover keeping the passwords persist, as far as I can tell at least. It is possible that the author may have thought that this was so obvious, whereas it wasn’t for me.
Thanks again for all your valuable thoughts and suggestions!
Glad I could help.
I was referring to the part in the guide named " Answering the question “what am I about to lose?” " towards the end. You can use tree -x / to get a list of things that will be deleted next reboot when you clean out your root folder.
By default, passwords are stored mutably. They are not stored in the Nix store. This is usually a good thing since these hashes are considered a secret and should not be in the store where they might be read by users that normally couldn’t. But that means they cannot be recreated from the store during activation either (which is the whole point of the article). Persisting your /etc/shadow will probably solve this issue.
As to why this is not mentioned in the guide, I do not know. But if this is indeed the issue that you are seeing, this would be a good addition to prevent this trap. Maybe you can try in a VM.
I just wanted to post an update here about this topic. I want to caution anybody who wants to follow this guide to achieve a stateless system that although the author is respectable, the guide is likely outdated and reproducibly leads to a broken system after the first reboot. As seen in the discussion above, /etc/shadow is among the several files/components that does not persist by default across reboots, and is not enough to keep system integrity so that users can re-login after a reboot. This aspect is not covered by this guide at all, likely due to some updates to Nixos since the guide was published. I emailed the author about this but so far got no response. I wish I could post this warning as a comment to his blog/article/guide but that wasn’t possible. I thought this may be the next best place to post this warning.
I doubt that particular behavior has changed in the past. It’s a fairly static thing across distros, and the shadow file is kept deliberately imperative for security reasons.
I think the principal thing to take away is that it’s a fairly advanced thing to do, and the guide isn’t really a guide as much as it is a blog post showing a cool pattern. While being explicit about it would of course be better, various ways of handling passwords declaratively exist and the post probably just assumes you’re experienced with nix, NixOS and linux systems in general and are using any of them.
Not great for someone who’s figuring it out of course, and you’re right an addendum would be nice 
While we’re at it, GitHub - nix-community/impermanence: Modules to help you handle persistent state on systems with ephemeral root storage [maintainer=@talyz] is worth a look for anyone wanting to do this, they also have a “further reading” section in the readme, which contains both @grahamc’ s post and a slightly more tutorial-ey one (that does explicitly tell you to use declarative password management - though it’s probably not actually a good idea because those passwords are always world-readable if they are declared that way).