-
-
Notifications
You must be signed in to change notification settings - Fork 13.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
boot.initrd.secrets fixes #210812
boot.initrd.secrets fixes #210812
Conversation
@GrahamcOfBorg test grub installer.fullDiskEncryption |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not super happy about the bind mount thing but I don't see a better way.
Could you rebase on master and change
nixpkgs/nixos/tests/installer.nix
Line 52 in 2d798b3
boot.initrd.secrets."/etc/secret" = /etc/nixos/secret; |
to a relative path?
Yeah, as I wrote in the commit message the proper solution is to build the system within chroot, but that has several problems too and it's a lot of work. It could be something for the future, but for now it's important to just get rid of this bug.
Ok! |
5acebe6
to
dc81448
Compare
There are conflicts now |
The build of initrd-secrets can routinely fail for old boot entries if the secrets have been removed or renamed in a later generation. This always happens for generation 1, because it's built from the NixOS installer and the paths differs by the mount point (i.e. /mnt). The error is very confusing because it fails to mention it's about an older generation and that it's somewhat harmless. This commit turns the error into a warning for all generations but the current, adds the name of the failed entry to the message and a note explaining why it can happen.
When installing NixOS in the target filesystem /mnt, paths relative to configuration.nix in `initrd.secrets` are turned by Nix into absolute paths that reference /mnt. While building the system derivation works, installing the bootloader fails because the latter process takes place inside the chroot environment where /mnt does not exist. Ideally, we would also build the system within chroot, but this greatly complicates the matter as it requires manually copying over Nix, its runtime dependencies and all channels. Possibly, this would also break several assumptions users have about how nixos-install works. A simpler and safer (but less neat) solution is to temporarily bind mount all mount points in /mnt under /mnt/mnt to keep the paths functional while the bootloader is being installed. This is essentially the workaround described in issue NixOS#73404.
This tests a common full disk encryption setup: https://gist.github.com/ladinu/bfebdd90a5afd45dec811296016b2a3f
dc81448
to
9bb888c
Compare
Fixed the conflicts and re-run the tests. |
This (commit 9fc47e6) broke our EDIT: local testing e.g. by nix build -f nixos/release-combined.nix nixos.amazonImage.x86_64-linux |
say STDERR "warning: failed to create initrd secrets for \"$name\", an older generation"; | ||
say STDERR "note: this is normal after having removed or renamed a file in `boot.initrd.secrets`"; | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You may also be interested in this fix, please take a look:
#209156
Aaand another installer test regression from this PR, also blocking the nixos-unstable channel: https://hydra.nixos.org/build/206057315
|
That's because we have exposed the fact relative paths have never worked before. I have to make the failure a warning in systemd-boot as well. |
I'm confused by this failure. Why is append-initrd-secrets seeing a path that starts with EDIT: I think I see. When constructing the boot menu we have to process the old generation in addition to the new one, and appending its secrets using its append-initrd-secrets fails because it refers to the old path. It's unclear to me why we need to re-invoke append-initrd-secrets for old generations though. |
Fair point, in this way it's neither fully stateless nor stateful. |
This sounds tangentially related to #209156
Theorizing: as with the kernel and initrd: it has the effect of reinstating the available kernels under /boot if they have been removed or modified. It does seem unfortunate though that the secrets were not by-system but instead by-initrd which doesn't make sense when you consider that you might have two system versions with incompatible secrets, and possibly want to boot into either. I tried to fix this in #209156 by naming the append-initrd-secrets after the system instead. |
Description of changes
A couple of fixes for making the user experience of
boot.initrd.secrets
less miserable.This completely fixes #73404.
Things done
sandbox = true
set innix.conf
? (See Nix manual)nixosTests.installer.fullDiskEncryption
nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"
. Note: all changes have to be committed, also see nixpkgs-review usagenixos/doc/manual/md-to-db.sh
to update generated release notes