nixos/etc-overlay: avoid rebuilding the initrd every time the etc contents change #340722
Conversation
|
@ofborg test activation-etc-overlay-mutable activation-etc-overlay-immutable |
| set -uo pipefail | ||
|
|
||
| # Figure out what closure to boot | ||
| closure= | ||
| for o in $(< /proc/cmdline); do | ||
| case $o in | ||
| init=*) | ||
| IFS='=' read -r -a initParam <<< "$o" | ||
| closure="''${initParam[1]}" | ||
| ;; | ||
| esac | ||
| done | ||
|
|
||
| # Sanity check | ||
| if [ -z "''${closure:-}" ]; then | ||
| echo 'No init= parameter on the kernel command line' >&2 | ||
| exit 1 | ||
| fi | ||
|
|
||
| # Resolve symlinks in the init parameter | ||
| closure="$(chroot /sysroot ${lib.getExe' pkgs.coreutils "realpath"} "$closure")" | ||
| # Assume the directory containing the init script is the closure. | ||
| closure="$(dirname "$closure")" |
There was a problem hiding this comment.
This is basically the same exact logic as what we have for the activation service, where we find the path to prepare-root in the same way.
Maybe it would make sense to create a common service that does this once and makes the closure available in the initrd so that other units can use it?
There was a problem hiding this comment.
@ElvishJerricco I'd like to hear your thoughts on this. Would it make sense to pull this into a separate service that creates a link to the closure so that we can reuse this elsewhere?
| @@ -23,6 +23,15 @@ | |||
| specialisation.new-generation.configuration = { | |||
| environment.etc."newgen".text = "newgen"; | |||
| }; | |||
|
|
|||
| assertions = lib.mkIf (lib.length (lib.attrNames config.specialisation) > 0) [ | |||
There was a problem hiding this comment.
This mkIf is needed because otherwise this assertion is also added to the specialisations, which leads to an error because they don't have any specialisations themselves.
r-vdp
force-pushed
the
etc-overlay-no-initrd-rebuilds
branch
from
6c6e66d
to
08f7609
Compare
|
@nikstur would you be able to give this a review? I think it would be nice to get this in before 24.11 branch-off. |
…tents change Before this change, the hash of the etc metadata image was included in the mount unit that's responsible for mounting this metadata image in the initrd. And because this metadata image changes with every change to the etc contents, the initrd would be rebuild every time as well. This can lead to a lot of rebuilds (especially when revision info is included in /etc/os-release) and all these initrd archives use up a lot of space on the ESP. With this change, we instead include a symlink to the metadata image in the top-level directory, in the same way as we already do for things like init and prepare-root, and we deduce the store path from the init= kernel parameter, in the same way as we already do to find the path to init and prepare-root. Doing so avoids rebuilding the initrd all the time.
r-vdp
force-pushed
the
etc-overlay-no-initrd-rebuilds
branch
from
08f7609
to
fd801cf
Compare
r-vdp
changed the title
Description of changes
Before this change, the hash of the etc metadata image was included in the mount unit that's responsible for mounting this metadata image in the initrd.
And because this metadata image changes with every change to the etc contents, the initrd would be rebuild every time as well.
This can lead to a lot of rebuilds (especially when revision info is included in /etc/os-release) and all these initrd archives use up a lot of space on the ESP.
With this change, we instead include a symlink to the metadata image in the top-level directory, in the same way as we already do for things like init and prepare-root, and we deduce the store path from the init= kernel parameter, in the same way as we already do to find the path to init and prepare-root.
Doing so avoids rebuilding the initrd all the time.
Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.