| 5 Jun 2023 |
 oddlama | Hmm your hunch was right, setting flushBeforeStage2 = true; works around the issue | 18:52:44 |
 @elvishjerricco:matrix.org | oddlama: interesting. Can you open an issue and include your configuration? | 18:53:27 |
| oddlama | Just noticed that the systemd-networkd.service: Deactivated successfully also happens in stage2 not stage1, the log order is just also wrong there :D | 19:09:29 |
| oddlama | In reply to @elvishjerricco:matrix.org
oddlama: interesting. Can you open an issue and include your configuration? Not sure how I can include my configuration easily. It's publicly available on github, but too complicated to copy out a single snipped, especially because I don't really know what causes this. I can make a commit and refer to that if it helps | 19:12:40 |
| @elvishjerricco:matrix.org | oddlama: Well maybe write a little test with the nixos test framework to reproduce the problem if that proves easy enough to do? If not don't worry about it and just describe the problem as best you can | 19:14:28 |
| oddlama | Alright, I wrote a test for this :D | 20:38:56 |
| oddlama | https://github.com/NixOS/nixpkgs/issues/236146 | 20:38:57 |
| @elvishjerricco:matrix.org | oddlama: If I remove your check-flush service, and wait_for_unit on network.target instead of multi-user.target, the test passes | 20:57:14 |
| @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 |
