| 6 Jun 2023 |
 @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 |
| @elvishjerricco:matrix.org | * After and Before just create 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:28 |
| oddlama | True, I remember now. So the issue could be that nothing wants network-pre which means network is never started? | 13:49:04 |
| @elvishjerricco:matrix.org | No | 13:49:11 |
| oddlama | Im so lost 😂 sorry | 13:49:29 |
| @elvishjerricco:matrix.org | You only need to want network.target to start the network, and that is pulled in by multi-user.target | 13:49:35 |
| @elvishjerricco:matrix.org | network-pre.target is an optional target in case you need to create a unit that runs before networking is started | 13:50:05 |
