| 18 Apr 2023 |
 @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 |
| @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 /sysroot is mounted | 22:23:31 |
| @nikstur:matrix.org | From reading the systemd issue you posted, I understand why you are frustrated with the current implementation of the module because this exact use case Lennart describes as a solution to your problem is not (yet) available. | 22:28:30 |
| @elvishjerricco:matrix.org | Sorry, no, the current implementation just doesn't make sense to me. If it can be done after /sysroot is mounted, there's like a 95% chance it can be done in stage 2 instead. But there are plenty of reasonable use cases that must come before /syroot is mounted. The time in between, when /sysroot is mounted and we haven't transitioned to stage 2, is the most unlikely time for systemd-repart to be useful | 22:33:04 |
| @nikstur:matrix.org | So let's make this concrete: What do you propose? Currently you can (1) use systemd-repart in stage 1 after the sysroot is mounted and (2) you can use it in stage 2. Do you want to get rid of (1) and replace it entirely with baking the configs into the initrd or do you want to add the ability to bake the configs in the initrd as a third option? | 22:37:51 |
| @elvishjerricco:matrix.org | I would argue that if systemd-repart is in initrd, the config files should be as well, so ordering after sysroot.mount would be incorrect. | 22:39:41 |
| @elvishjerricco:matrix.org | Having systemd-repart in stage 1 but needing /sysroot to already be mounted seems like an esoteric situation to me | 22:40:21 |
| 20 Apr 2023 |
|  @shawn8901:matrix.org joined the room. | 17:22:13 |
