Rather than continuing to discuss this tangent on the PR,

As for the link units, the PR that added this comment also linked to an issue, but that issue was closed by this way before that PR was even made. I'm wondering why that systemd change isn't enough to resolve the problem. Surely you're not expected to do your interface renaming in stage 1. In fact, the comments in the issue suggest that the udev rules to rename the interface in stage 2 should happen before networkd is even notified the interface is ready.

In reply to @elvishjerricco:matrix.org
And fwiw, if I remove the line that adds the link units to systemd stage 1 and enable systemd stage 1 in the nixosTests.networking.networkd.rename test, the test doesn't fail even after 20 tries.

In reply to @elvishjerricco:matrix.org
like, if we're going to require the stage 2 fs to be set up, then we should do it in stage 2, not stage 1. And if we're doing it in stage 1, just put the config files in stage 1

In reply to @elvishjerricco:matrix.org
like, if we're going to require the stage 2 fs to be set up, then we should do it in stage 2, not stage 1. And if we're doing it in stage 1, just put the config files in stage 1

This is, however, just the design of systemd-repart

No? The docs say nothing of the sort. --root is just something that a lot of systemd utils support; it's not saying that's the only way to work with not-the-current-root-fs

The use case for systemd-repart in stage 1 is 100% for formatting and resizing the root fs. This is a major reason why /sysusr exists at all; systemd-repart finds the config files in what will become /usr and uses that to format what will become /. /sysusr exists so that /sysroot doesn't have to be mounted first, precisely because things like systemd-repart are meant to alter that stuff

The docs say this is the default: "By default when invoked on the regular system this defaults to the host's root file system /. If invoked from the initrd this defaults to /sysroot/, so that the tool operates on the configuration and machine ID stored in the root file system later transitioned into itself.". I tried to stay as close as possible to the default.

systemd-repart actually does not only look into sysusr. It also looks for configs in /sysroot/etc. E.g. see the conditions for the service:

ConditionDirectoryNotEmpty=|/sysroot/usr/lib/repart.d
ConditionDirectoryNotEmpty=|/sysroot/usr/local/lib/repart.d
ConditionDirectoryNotEmpty=|/sysroot/etc/repart.d
ConditionDirectoryNotEmpty=|/sysusr/usr/lib/repart.d
ConditionDirectoryNotEmpty=|/sysusr/usr/local/lib/repart.d

If I understand it correctly, your point is that the nix store might not be on sysroot but instead mounted later (alongside the other partitions marked with x-initrd.mount in the fstab). Thus, it would only be available after initrs-fs.target is reached. Then instead of sysroot.mount, we should use initrd-fs.target to order the systemd-repart service. That makes sense to me.

I also agree that /sysusr/ is the preferred/ideal way to store the config files in the systemd world. However, I don't see a way to imitate that in NixOS.

On the top of my head I can think of at least one solid use case where systemd-repart has to run in the initrd. Imagine you have disk images that only contain the Nix Store on the root fs without even space in the root fs to accomodate the rest of the / subtree created during activation. Repart can then make the space in the root fs after sysroot.mount (or even initrd-fs.target) but before activation.

I don't really love baking configuration (i.e. the repart configs) into the initrd if it can be avoided. And again, I think the current module is closer to how systemd-repart operates by default than the alternative of baking the configs into the initrd. But maybe we can give users the option in the module.

The docs say this is the default: "By default when invoked on the regular system this defaults to the host's root file system /. If invoked from the initrd this defaults to /sysroot/, so that the tool operates on the configuration and machine ID stored in the root file system later transitioned into itself.". I tried to stay as close as possible to the default.

systemd-repart actually does not only look into sysusr. It also looks for configs in /sysroot/etc. E.g. see the conditions for the service:

ConditionDirectoryNotEmpty=|/sysroot/usr/lib/repart.d
ConditionDirectoryNotEmpty=|/sysroot/usr/local/lib/repart.d
ConditionDirectoryNotEmpty=|/sysroot/etc/repart.d
ConditionDirectoryNotEmpty=|/sysusr/usr/lib/repart.d
ConditionDirectoryNotEmpty=|/sysusr/usr/local/lib/repart.d

If I understand it correctly, your point is that the nix store might not be on sysroot but instead mounted later (alongside the other partitions marked with x-initrd.mount in the fstab). Thus, it would only be available after initrs-fs.target is reached. Then instead of sysroot.mount, we should use initrd-fs.target to order the systemd-repart service. That makes sense to me.

I also agree that /sysusr/ is the preferred/ideal way to store the config files in the systemd world. However, I don't see a way to imitate that in NixOS.

On the top of my head I can think of at least one solid use case where systemd-repart has to run in the initrd. Imagine you have disk images that only contain the Nix Store on the root fs without even space in the root fs to accomodate the rest of the / subtree created during activation. Repart can then make the space in the root fs after sysroot.mount (or even initrd-fs.target) but before activation.

I don't really love baking configuration (i.e. the repart configs) into the initrd if it can be avoided. And again, I think the current module is closer to how systemd-repart operates by default than the alternative of baking the configs into the initrd. But maybe we can give users the option in the module.

If invoked from the initrd this defaults to /sysroot/, so that the tool operates on the configuration and machine ID stored in the root file system later transitioned into itself

I think you're leaning heavily on this line as the only indication of how the docs want it to work in initrd. But I still think it's a misinterpretation. By defaulting to /sysroot, that includes the required disk formatting, and therefore comes before sysroot.mount and not after.

On the top of my head I can think of at least one solid use case where systemd-repart has to run in the initrd. Imagine you have disk images that only contain the Nix Store on the root fs without even space in the root fs to accomodate the rest of the / subtree created during activation. Repart can then make the space in the root fs after sysroot.mount (or even initrd-fs.target) but before activation.

Partitions can often be resized online. e.g. Look at how systemd-growfs works. The partition table is not part of the FS, so that can be changed without consequence. Then the FS can be adjusted to consume the whole partition online ala growfs

In reply to @elvishjerricco:matrix.org

If invoked from the initrd this defaults to /sysroot/, so that the tool operates on the configuration and machine ID stored in the root file system later transitioned into itself

I think you're leaning heavily on this line as the only indication of how the docs want it to work in initrd. But I still think it's a misinterpretation. By defaulting to /sysroot, that includes the required disk formatting, and therefore comes before sysroot.mount and not after.