I noticed that you drop the chroot-realpath package already in the first commit, but then only convert the usage sites to nix-init in the third. Maybe you should delete the package as part of the third commit then?

I'll try it out and give a more thorough review later, as I'm on mobile currently.

Great work in any case, looking forward to getting this merged!

Maybe you should delete the package as part of the third commit then?

That got lost in the wrong commit during rebasing. Thanks for catching it!

Fixed now.

I'm guessing the reason most of this couldn't be handled by initrd-systemd directly is because doing so would require a new initrd every generation?

If that's the case, what would be the actual requirements for systemd to load? I'm fairly certain it refuses to boot without /usr/bin/env, but it seems perfectly fine without /bin/sh, and that should be safe to generate with systemd-tmpfiles. tmpfiles also supports being given literal text to write directly to a target file, which could potentially work for modprobe and the firmware if they aren't needed immediately when switching root.

I booted my laptop with this patch included and everything looks fine. One weird thing is that none of the log::info! calls from the switch-root service made it into the system journal. I do see a log line from the find-etc service though. I didn't yet figure out the difference between the two services.

(Thanks for the ping and for the great work, hoping to take a look at this soon!)

I'm guessing the reason most of this couldn't be handled by initrd-systemd directly is because doing so would require a new initrd every generation?

That's one of the reasons.

If that's the case, what would be the actual requirements for systemd to load? I'm fairly certain it refuses to boot without /usr/bin/env, but it seems perfectly fine without /bin/sh

The hard hard requirements are (1) setting up /run/current-system, (2) setting up /etc and (3) setting up /usr/bin/env.

that should be safe to generate with systemd-tmpfiles

We've had discussions about this in the community. The issue is that the system() call from libc relies on /bin/sh and this could be called by any binary very very early in the boot process. Indeed we had this in kbd which called system() in systemd-vconsole-setup.service. Now solved by #434001. However, I haven't observed any more of these cases in my testing. I'm open to eventually do this, but for this PR I don't want to change the scope anymore.

tmpfiles also supports being given literal text to write directly to a target file, which could potentially work for modprobe and the firmware if they aren't needed immediately when switching root.

Here again, timing is the issue. You want to set these variables very very early but also not too earyl in the initrd. You only want to set them to their stage 2 paths just right before switching root.

I booted my laptop with this patch included and everything looks fine. One weird thing is that none of the log::info! calls from the switch-root service made it into the system journal. I do see a log line from the find-etc service though. I didn't yet figure out the difference between the two services.

Turns out that I was confused, because with this patch, nixos-init will be used to find the etc overlay image even if system.nixos-init.enable is set to false. So when building my system, I saw nixos-init being compiled and included, and I assumed that it was also used for the rest of the initrd stuff, but that wasn't the case.

I now enabled the option and booted again, and I do see the expected log messages. Everything looks fine, except that my nix store is not getting bind mounted. With the current code, when the nix store is not already a mount point, it does not get remounted. On my system /nix is a mount point but not /nix/store.

This patch fixes it, by also bind mounting the store if it wasn't a mount point: r-vdp@8463445 r-vdp@55ffd4c

So when building my system, I saw nixos-init being compiled and included, and I assumed that it was also used for the rest of the initrd stuff, but that wasn't the case.

That's still an important test case. You tested that everything works fine even when not enabling nixos-init.

This patch fixes it, by also bind mounting the store if it wasn't a mount point: r-vdp@8463445 r-vdp@55ffd4c

Thank you! Implemented the fix now.

The merge queue seems to be stuck. However, I see nothing wrong. Any objections to bypassing the merge queue rules?

doesn't look stuck to me?

doesn't look stuck to me?

I can only merge by bypassing the rules. It seems to be waiting for ofborg (which might never finish).

You can press "merge when ready", which adds it to the merge queue. It won't wait on ofborg, it just will never say anything different than "merge when ready" since enabling merge queues.

You can press "merge when ready", which adds it to the merge queue. It won't wait on ofborg, it just will never say anything different than "merge when ready" since enabling merge queues.

Ah Ok, I didn't know that thank you!