| 6 May 2025 |
 m1cr0man | It might be worth poking around with resolvectl/systemd-resolved and see if something fishy is happening. The nspawn containers do funky things with the hosts file and nameserver setup, could be conflicting with bind | 22:14:41 |
 netpleb | thanks, I've been poking at that a bit. Will let you know if anything comes of it. | 22:36:06 |
| 9 May 2025 |
| netpleb | I have good news!! The issue is finally resolved. It turned out to be a much different problem than originally expected: ipv6 link local addressing was the cuplrit. Even though I had networking.enableIPv6 = false on both the host and the machine, systemd-network-wait-online was not reaching its target because systemd-network was trying to assign link local ipv6 addresses. Setting systemd.network.networks."eth0".networkConfig.LinkLocalAddressing = "no"; in my container config seemed to do the trick. | 21:47:12 |
| netpleb | * I have good news!! The issue is finally resolved. It turned out to be a much different problem than originally expected: ipv6 link local addressing was the cuplrit. Even though I had networking.enableIPv6 = false on both the host and the container, systemd-network-wait-online was not reaching its target because systemd-network was trying to assign link local ipv6 addresses. Setting systemd.network.networks."eth0".networkConfig.LinkLocalAddressing = "no"; in my container config seemed to do the trick. | 21:54:28 |
| 10 May 2025 |
 Arian | you can also configure systemd-network-wait-online to wait for either ipv4 or ipv6 | 07:19:36 |
| Arian | wait why did it fail to assign a link local address | 07:20:02 |
| Arian | that is the weird part here :P | 07:20:08 |
| Arian | link local addressing should be… instant | 07:20:17 |
| m1cr0man | In reply to @netpleb:matrix.org
I have good news!! The issue is finally resolved. It turned out to be a much different problem than originally expected: ipv6 link local addressing was the cuplrit. Even though I had networking.enableIPv6 = false on both the host and the container, systemd-network-wait-online was not reaching its target because systemd-network was trying to assign link local ipv6 addresses. Setting systemd.network.networks."eth0".networkConfig.LinkLocalAddressing = "no"; in my container config seemed to do the trick. Glad you figured it out :D What a weird one, I wouldn't have thought of ipv6 link local being the issue. | 12:15:20 |
| m1cr0man | In reply to @arianvp:matrix.org
link local addressing should be… instant It might not necessarily be an assignment issue, but rather a routing issue. With my time on RFC108 I've observed some strange stuff with nspawn networking | 12:15:55 |
| 11 May 2025 |
| netpleb | I am not sure of what the root cause is (I am not an expert in this stuff and had to learn a bunch about systemd-network to even get this far), but all I know is that once I finally whittled it down to the smallest possible config that still worked correctly and then removed the LinkLocalAddressing = "no" line (thereby reverting to the default "yes" behavior), the container all of a sudden would timeout trying to reach wait-online.
Who knows. I am just happy it finally works! Now the container boots typically 11 seconds (including checking certs and such) instead of the multiple minutes it was taking before.
| 02:47:22 |
| netpleb | regardless, thank you all here for your help! | 02:47:58 |
