nixos/systemd-shutdown: use prebuilt shutdown ramfs derivation #216866
Conversation
I changed the shutdown ramfs to be built alongside the system config rather than be built on-the-fly at shutdown. See discussion starting at NixOS#185085 (comment) for details on motivation, but basically there's not much reason to only do this at shutdown (even if it's quick to run), dracut does not do this, and it requires building a cross rustc toolchain for make-initrd-ng even if no other Rust programs exist on the target image just to run the one script. This change technically could be breaking, but only if the user manually made a unit that dependend on `generate-shutdown-ramfs.service`, which doesn't seem like a use-case that would give someone any benefit anyway with the options available in the module. I can change the service name back to `generate` if someone feels otherwise that this will be a real problem. I opted not to unpack the booted initrd image for shutdown because unpacking it is a hard problem, and that would ignore the options already available in this module (and are already used at least by the ZFS module and some people's configs). It would be nice if we could try to use the same systemd version and other software versions that we booted with (just to ensure no issues), but that would involve modifying system top-level build and loading from something like `/run/booted-system/shutdownramfs`, which would on the whole be more complicated than the potential benefit I feel it would give.
|
@ofborg build nixosTests.systemd-shutdown |
|
Will isn't in the systemd team, so I've requested his review directly, for posterity if nothing else :) |
ofborg
bot
added
10.rebuild-darwin: 1-10
10.rebuild-darwin: 1
10.rebuild-linux: 1-10
labels
|
@lilyinstarlight I'm sure it's small, but could you comment the difference in system closure size caused by this? If we care about the shutdown ramfs matching the initrd, we could unpack it at boot instead of shutdown, and just leave it in there all boot long. This of course consumes extra system memory though. Tradeoffs, tradeoffs :) |
Yep, will do!
I also thought about that but idk how much I trust |
|
Okay I just checked and the closure size difference for So ~21.07 MiB increase Is that acceptable @ElvishJerricco? |
|
That's about what I expected. We should also probably confirm that this correctly fixes the cross compiling situation before we merge. |
|
So, funny thing about this... It does remove the need to cross compile |
Ah, neat (guess I waited too long to actually open this PR...). Well I'll probably rethink this change then if that's no longer a motivation What we really should be doing anyway is pivoting back to booted initrd Do you think we could keep the unpacked version of the initrd somewhere or at least the contents file reachable from toplevel? Or is there a reliable way to unpack an arbitrary |
|
We could always copy the files out of the initrd during initrd so that we don't have to think about any kind of archive format stuff. Of course that relies on those files remaining intact all along until shutdown. Could mount the tmpfs at |
Yeah I just worry that it may disappear while a user is mucking with mounts or something, but perhaps if they are mucking with that it's their own fault if shutdown can't pivot to back to initrd... (it's not like that's fatal, systemd just will silently not use it if
Yes and dracut does so via trying multiple different directories for the initrd associated with the running kernel version, using their own skipcpio executable (which I may extract to a separate output or even derivation from the dracut derivation in nixpkgs), and then trying different compression programs until one works Which seems fragile and we can probably do a lot better than that given we'll have So I'll look more at this soon and may just implement a sketchy |
This is an interesting thought. I don't think systemd will let you do that though; it literally wipes the old root if it can (I've read this is because the initrd's root fs can't actually be unmounted for some reason, but I have no idea where that idea comes from or if it's true) |
|
I'll go ahead and close this and open a new PR soon, since we'll try to do something more "correct" for this |
That's unfortunate. Maybe it's time to make cross-targeting
I don't like the idea of keeping shutdown-ramfs in memory all the time, even after cherry picking some of them from original initrd (~22M systemd-shutdown closure for me, larger if I'm not sure if there a better way to do this now. 😢 |
Yea |
|
I'm pretty sure (and/or hopeful) more rust will end up in low-level system services, so having to have a rustc in the build closure is probably not too bad after all :-) Agreed that we should probably see how we can get this to be a bit more enjoyable, and maybe have it in the binary caches for the most part. |
Noted. Thinking about it more, maybe just doing best-effort Status-quo isn't the most terrible too, since I mean it is effectively equivalent to what mkinitcpio does (mkinitcpio just sketches me out a lot in general, so I'm pretty apprehensive about replicating any decisions it makes...) |
|
I think that what we currently have is probably better than a "best effort" sort of thing. |
I've tried it once but soon gave it up. Despite we can prepend arbitrary binary content before initrd via
Yeah, especially now Linux also has some Rust code. I agree that the current solution is good enough. We should probably just keep it. The shutdown ramfs can always be disabled if necessary via |
Description of changes
I changed the shutdown ramfs to be built alongside the system config rather than be built on-the-fly at shutdown. See discussion starting at #185085 (comment) for details on motivation, but basically there's not much reason to only do this at shutdown (even if it's quick to run), dracut does not do this, and for cross systems it requires building a cross rustc toolchain for make-initrd-ng even if no other Rust programs exist on the target image just to run the one script.
This change technically could be breaking, but only if the user manually made a unit that dependend on
generate-shutdown-ramfs.service, which doesn't seem like a use-case that would give someone any benefit anyway with the options available in the module. I can change the service name back togenerateif someone feels otherwise that this will be a real problem.I opted not to unpack the booted initrd image for shutdown because unpacking it is a hard problem, and that would ignore the options already available in this module (and are already used at least by the ZFS module and some people's configs).
It would be nice if we could try to use the same systemd version and other software versions that we booted with (just to ensure no issues), but that would involve modifying system top-level build and loading from something like
/run/booted-system/shutdownramfs, which would on the whole be more complicated than the potential benefit I feel it would give.cc: @ElvishJerricco @oxalica
Things done
sandbox = trueset innix.conf? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)