no secrets on boot #45
Comments
|
Darn, I'm sorry that's happening to you! Don't jump to the conclusion that the missing file is the cyphertext, it could also be the decryption key, or something wrong with the Are you able to boot with your previous generation? One thing we should do in the future is make a module option that allows debugging these kinds of failures easily, but for you could try using this module instead which adds some debugging lines to the decryption activation scripts: Could you also share what options you are setting in the age module? And what version of the agenix repo you are using? |
|
So I've isolated the problem at least, but it's not really agenix fault after all, sorry aboout that. Before I posted the issue, I had first assumed it may be a problem with the impermanence module that I'm using to maintain some state on a clean root directory after each boot. First thing I tried was commenting the statement that resets the zfs root directory to an empty state at boot. When that didn't work I figured the problem must be elsewhere, but after looking more closely at the logs it looks like my /etc/ssh is still getting mounted after secrets are generated so they don't have access to my host key. Don't know how to fix yet, but I noticed that my persistent /var/log directory is the only one of my persistent directories to be mounted before secrets (during stage-1). I'm trying to figure out what's so special about it and why all the other persistent dirs only mount in stage-2. I'll close this since it's not really an issue with agenix, but I'll report back when I find a fix. |
|
This PR fixed it by allowing me to set proper mount dependencies on early boot: |
|
Great, I'm glad you figured it out! |
|
I'm experiencing this issue. It seems that |
|
I'm not sure it is obvious that the activation scripts should run after "etc" because it depends on users/groups existing, and sometimes users and groups depend on secrets existing to be set up correctly. Maybe we need a more flexible dependency graph. |
|
Maybe each secret should be its own activation script, then you could use the normal activation script ordering features to get the order you want. |
|
@andrevmatos, did you try to solution that worked for me? The above mentioned PR. It is available in nixpkgs-unstable, and it would probably even qualify for a backport |
|
@nrdxp Thank you for your response. I did check it, but it seems to be useful only for mountpoints. In my case, the persisted volume did get mounted properly on time, but my |
|
I tried pretty much everything with a zfs fully encrypted pool with something like this: {
# tried nixos-unstable with depends
fileSystems."/nix".depends = [ "/run" "/srv" "/tmp" ];
boot.initrd.postDeviceCommands = lib.mkAfter ''
zfs rollback -r rpool/root@blank
'';
boot.tmpOnTmpfs = true;
age.secrets.nextcloud-env = {
file = ./nextcloud/.env;
# my preferred path:
path = "/run/keys/secrets/nextcloud-env";
# or
path = "/tmp/secrets/nextcloud-env";
};
# even something like this, where the ssh key lies on the unencrypted boot (vfat):
age.sshKeyPaths = [ "/boot/ssh_host_ed25519_key" ];
}but the error is always the same: I'm still not sure if it fails to find the ssh key or to write the decrypted file... |
|
@Philipp-M are you also using impermanence? If not, you may not need the The only depends I have is: {
fileSystems."/etc/ssh" = {
depends = [ "/persist" ];
neededForBoot = true;
};
}due to impermanence. |
|
It was a simple {
fileSystems."/srv".neededForBoot = true;
}(where the ssh keys are) darn how could I have missed this 🤦♂️ Thanks! |
|
Just lost a few hours debugging a similar problem on my machine. Turns out my home wasn't mounted yet, and some keys were in it.
|
Wouldn't consider this solved, as if I use a flake that gets the keys from a private repo this would be the cleanest solution. I can create some workarounds but they'll be ugly. |
ghost
mentioned this issue
|
Also just lost a day or two on this, as my config was working fine after
Thankfully was able to recover, but could have saved a decent chunk of time with a warning about this in the README. |
|
|
|
|
environment.persistence = {
"/persist" = {
# ...
users.${config.users.main} = {
directories = [
".ssh"
];
};
};
};In my case |
There seems to be an issue after upgrading to latest nixos-unstable where the secrets don't get created properly on boot. Not sure what the root cause is yet, but I can tell you a simple
nixos-rebuild switchdoes successfully make the secrets so it's only a boot time issue.Strangely the files don't seem to exist on boot as the boot log is full of these message:
These files do in fact exist in the nix store and, as I said, all my secrets are properly created with a simple
nixos-rebuild switch. My only guess so far is that stage-2-init doesn't have proper access to the nix/store somehow, but I'm not sure why.The text was updated successfully, but these errors were encountered: