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.

In reply to @elvishjerricco:matrix.org
but given that poettering himself has told me that repart is meant to be used for partitioning/formatting the root disk, I'm heavily inclined to believe that's what it's for in initrd