| 5 Jun 2023 |
 @elvishjerricco:matrix.org | oh but I see. The point is that I shouldn't need systemd-networkd to be running yet for the dont-flush case to have the network preconfigured by stage 1 | 20:59:00 |
| 6 Jun 2023 |
| @elvishjerricco:matrix.org | oddlama: Ok, so I think the test you made is accidentally discovering a different bug. If you change check-flush.service to have wantedBy = ["multi-user.target"]; instead of requiredBy, then the test succeeds because it doesn't cause multi-user.target to fail, and systemd-networkd.service starts just fine. So the different bug is that the network configuration is getting taken down between stages 1 and two, causing check-flush.service to fail. But systemd-networkd.service is starting fine | 00:39:02 |
| @elvishjerricco:matrix.org | oh, that might be because you didn't enable systemd initrd, or inherit the netdevs part from stage 2 :P | 00:46:55 |
| @elvishjerricco:matrix.org | Hm. That didn't fix it | 00:51:08 |
| @elvishjerricco:matrix.org | systemd-networkd[88]: extra-1: netdev could not be created: Operation not supported
Oh, well yea that would explain a thing or two
| 02:51:43 |
| @elvishjerricco:matrix.org | is a particular kernel module or something needed to create a Kind = "dummy" netdev? | 02:53:05 |
| @elvishjerricco:matrix.org | oddlama: Ok yea, so now I have the test passing, and it isn't because of the bug you were originally describing where systemd-networkd wouldn't come up | 03:20:00 |
| @elvishjerricco:matrix.org | I had to 1) Actually enable systemd stage 1, 2) Inherit the netdevs, 3) Add dummy to boot.initrd.availableKernelModules. And now it passes | 03:20:58 |
 oddlama | Damn, sorry. Seems like I failed to distill the actual issue here. On my real system where the issue happens, stage1 systemd is enabled, and there are no dummy netdevs needed. The interfaces that are missing are wireguard interfaces. And I specifically don't include them in the initrd. Yet, systemd-network is inactive after the switch | 10:52:02 |
| oddlama | * ElvishJerricco: Damn, sorry. Seems like I failed to distill the actual issue here. On my real system where the issue happens, stage1 systemd is enabled, and there are no dummy netdevs needed. The interfaces that are missing are wireguard interfaces. And I specifically don't include them in the initrd. Yet, systemd-network is inactive after the switch | 10:52:21 |
 @nikstur:matrix.org | Does the systemd-initrd not work with the netboot installer? Could it be the same reason it does not work with the ISO? | 11:30:25 |
| @elvishjerricco:matrix.org | nikstur: doesn't the NetBoot stuff use its own custom initrd or something? | 12:25:05 |
| @elvishjerricco:matrix.org | oddlama: yea so the test you wrote isn't reflecting that problem unfortunately :/ | 12:25:24 |
| @nikstur:matrix.org | In reply to @elvishjerricco:matrix.org
nikstur: doesn't the NetBoot stuff use its own custom initrd or something? It bascially only appends another cpio archive with the nix store as a squashfs. So it does use the "normal" initrd. | 13:05:38 |
| @elvishjerricco:matrix.org | ah | 13:06:12 |
| @elvishjerricco:matrix.org | interesting | 13:06:14 |
| oddlama | In reply to @elvishjerricco:matrix.org
oddlama: yea so the test you wrote isn't reflecting that problem unfortunately :/ The extra interfaces was the only idea I had for a cause. Do you by chance know any magic systemd stuff that allow me to log in more detail what is and isn't started? Then I can maybe just try to investigate on the actual system. | 13:35:33 |
| oddlama | What's also interesting is that I have multiple machines that share a lot of configuration, and the issue only appears on one of them. | 13:36:22 |
| @elvishjerricco:matrix.org | oddlama: You can set the SYSTEMD_LOG_LEVEL=debug environment variable on services that you want more logging from, and you can set systemd.log_level=debug to get more logging from PID 1 | 13:38:24 |
| @elvishjerricco:matrix.org | (rd.systemd.log_level=debug for stage 1 PID 1) | 13:38:43 |
| oddlama | I also don't understand why you suggested that wants = ["network-pre.target"]; would be a requirement. I naively would expect systemd-networkd to be started when I have some configuration for extra interfaces | 13:38:56 |
| @elvishjerricco:matrix.org | network-pre.target isn't pulled in by systemd-networkd.service by default | 13:39:17 |
| oddlama | Like would that imply that the network isn't started if there's no service depending on it? | 13:39:34 |
| @elvishjerricco:matrix.org | network-pre.target is just a target and doesn't actually do anything. On most systems, nothing comes with Before=network-pre.target, so it isn't useful to have. Things like systemd-networkd.service are still ordered After= it, but if nothing Wants= it, then it just won't be in the transaction | 13:40:44 |
| @elvishjerricco:matrix.org | so if you have something with Before=network-pre.target but nothing with Wants=network-pre.target, then that Before= ordering does nothing | 13:41:34 |
| oddlama | So if I understand correctly having e.g. sshd.service enabled would suffice because it has After=network.target, and network.target in turn has After=network-pre.target | 13:46:54 |
| @elvishjerricco:matrix.org | No. You're missing Wants=network-pre.target | 13:47:27 |
| @elvishjerricco:matrix.org | After != Wants | 13:47:34 |
| oddlama | Ah my bad, damn terminology | 13:47:55 |
| @elvishjerricco:matrix.org | After and Before just creating runtime ordering requirements in the event that both units are in the transaction. Wants, Requires, and BindsTo cause units to be pulled into the transaction | 13:48:20 |
