| 18 Apr 2023 |
 @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 |
| @elvishjerricco:matrix.org | What else is left for these to be merged? flokli?
- https://github.com/NixOS/nixpkgs/pull/226237
- https://github.com/NixOS/nixpkgs/pull/169116
| 20:16:27 |
| 21 Apr 2023 |
 @jkarlson:kapsi.fi | is there a systemd channel? | 11:32:04 |
 @andreas.schraegle:helsinki-systems.de | #systemd:nixos.org? | 11:32:19 |
| @jkarlson:kapsi.fi | thanks | 11:33:21 |
 @hexa:lossy.network | merged! 😄 | 16:46:57 |
| @elvishjerricco:matrix.org | Whoo! | 16:47:14 |
 flokli | In reply to @elvishjerricco:matrix.org
What else is left for these to be merged? flokli?
- https://github.com/NixOS/nixpkgs/pull/226237
- https://github.com/NixOS/nixpkgs/pull/169116
I just hit the big green button on the networkd - figured we should also get that in, and not block it on the other one to be merged. Thanks for the work :-) | 16:49:29 |
| @elvishjerricco:matrix.org | Yea I left a comment on the other one that now there's a couple of things to do before merging it relating to networking :P | 16:50:33 |
| @hexa:lossy.network | yes, it was one of the things I really wanted in 23.05 😄 | 16:50:43 |
