| 18 Apr 2023 |
 @elvishjerricco:matrix.org | I'm made more confident about this given a comment I received from poettering suggesting that root fs formatting is the job of repart | 21:40:46 |
| @elvishjerricco:matrix.org |
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
| 21:45:07 |
| @elvishjerricco:matrix.org | (in fact that's how fileSystems.<name>.autoResize works with systemd initrd enabled) | 21:46:40 |
| @elvishjerricco:matrix.org | I maintain that there is no excuse for mounting the root FS before running systemd-repart in initrd. | 21:47:46 |
| @elvishjerricco:matrix.org | ah wait I misunderstood the example | 21:49:29 |
| @elvishjerricco:matrix.org | hmm | 21:49:51 |
| @elvishjerricco:matrix.org | well that use case would still be taken care of by running systemd-repart before mounting /sysroot | 21:50:39 |
 @nikstur:matrix.org | 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.
Well there is also this: "On systems where usr= is not used this target is ordered after sysroot.mount and thus mostly equivalent to initrd-root-fs.target." https://www.freedesktop.org/software/systemd/man/systemd.special.html#initrd-usr-fs.target which means the default Before= in the systemd-repart.service is essentially equivalet to Before=initrd-root-fs.target and then there is also this comment in the code: https://github.com/systemd/systemd/blob/main/src/partition/repart.c#L6109 | 21:51:10 |
| @nikstur:matrix.org | So I fully agree that it would be awesome to even be able to create the root fs with systemd-repat (which means it has to run before sysroot.mount) but we don't have a /sysuser. So the only thing we can really do is bake the configs into the initrd, which I don't love but I'd be willing to offer it as an option. My argument is not that the current solution is the end-all be-all but that it has a purpose and we should not get rid of it, but we might add on to it. | 21:53:10 |
| @nikstur:matrix.org | * So I fully agree that it would be awesome to even be able to create the root fs with systemd-repart (which means it has to run before sysroot.mount) but we don't have a /sysuser. So the only thing we can really do is bake the configs into the initrd, which I don't love but I'd be willing to offer it as an option. My argument is not that the current solution is the end-all be-all but that it has a purpose and we should not get rid of it, but we might add on to it. | 21:53:19 |
| @elvishjerricco:matrix.org | As far as I can tell, any usecase that requires systemd-repart being run in initrd is a use case where it's perfectly acceptable to put the config files in the initrd | 21:55:37 |
| @elvishjerricco:matrix.org | when the purpose is to mess with the root fs before mounting, initrd is the correct place | 21:55:57 |
| @elvishjerricco:matrix.org | and if the purpose has nothing to do with the root fs, it almost certainly can/should be done in stage 2 | 21:57:19 |
| @nikstur:matrix.org | Even if I agree with that (and I'm not too far away) then the fact still remains that systemd-repart thinks its sensible to operate also on /sysroot. I think we should give the users the option to use the tool as close to the default as possible (even if there are compromises because NixOS works differently than other distros). All the users that think repart should exclusively run in stage 2 can still configure it that way. The module already offers this flexibility. | 22:01:35 |
| @elvishjerricco:matrix.org | The docs don't say repart works on a mounted /sysroot by default. repart is designed to work on unmounted devices. | 22:03:22 |
| @elvishjerricco:matrix.org | When they say it defaults to /sysroot, they mean it works on the device that will be eventually mounted as /sysroot | 22:04:05 |
| @nikstur:matrix.org | But it finds config files in the sysroot. How can it find config files in the sysroot if it is not mounted? | 22:04:41 |
| @elvishjerricco:matrix.org | that's a good question :P I'm not sure why they have code that checks that unless it's just for robustness | 22:05:21 |
| @elvishjerricco:matrix.org | but given that poettering himself has told me that repart is meant to be used for partitioning the root disk, I'm heavily inclined to believe that's what it's for in initrd | 22:06:13 |
| @nikstur:matrix.org | I'm like 90% certain that it works on a mounted sysroot but maybe I'm also losing my mind. | 22:06:37 |
| @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 | 22:06:40 |
| @nikstur:matrix.org | 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 It definetely is. There is no contradiction. It can just do more than that | 22:06:58 |
| @elvishjerricco:matrix.org | I mean it very well might, even if that's just additional functionality | 22:07:06 |
| @elvishjerricco:matrix.org | but the point remains that it's clearly incorrect to mount /sysroot before running repart | 22:07:35 |
| @nikstur:matrix.org | This is not at all clear to me | 22:08:19 |
| @elvishjerricco:matrix.org | 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 ^ | 22:08:35 |
| @elvishjerricco:matrix.org | seems pretty clear from that | 22:08:40 |
| @nikstur:matrix.org | Maybe this helps to clear up this misunderstanding: systemd-repart can also work on a mounted filesystem. You can call systemd-repart right now and it will alter the partition table of your running system. | 22:19:22 |
| @elvishjerricco:matrix.org | I don't see how that affects anything, except proving that more can be done in stage 2 instead | 22:21:55 |
| @elvishjerricco:matrix.org | From a practical perspective, I see (almost) no reason to use systemd-repart in initrd unless you're doing things that have to happen before /syroot is mounted | 22:22:48 |
