You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have observed this issue running Armbian v25.2.1 for Tinker Board running Armbian Linux 6.12.16-current-rockchip (Ubuntu noble server image).
This image uses NetworkManager for network config. When NM is used the NetworkManager-wait-online.service must be enabled so that network-online.target is not reached until NetworkManager has brought up all the interfaces. Service units that require the network to be up before starting rely on network-online.target working correctly otherwise they will likely fail on boot (which is the problem I observed).
I encountered this problem when trying to set up a dhcp server, using the isc-dhcpd-server package. I correctly configured the dhcp server, enabled its unit and restarted it. It worked. However when I rebooted the Pi the dhcp server failed to start claiming "there was no subnet definition for end0". I figured out that this was because at the time isc-dhcp-server was starting the network had not yet come up, so dhcpd could not obtain the IP address & netmask for the interface to match with the subnet definition in the config file.
Reading the systemd documentation (linked above) I ran the suggested command to see if the wait services were enabled:
This reveals that NetworkManager-wait-online.service is disabled, when it should be enabled when NM is used to configure the network.
I enabled NetworkManager-wait-online.service and then rebooted. The dhcp server started correctly.
How to reproduce?
In a running Armbian system execute the following command (from the systemd documentation) and verify that the correct wait unit (depending on how network configuration is done in the image) is enabled:
Hey @daniel-ayers, having fought the -wait-online stuff for years, while I see your point clearly, enabling it by default will cause hangs during boot for people without an ethernet connection. Specially on the first boot, we don't wanna hang on boot. Also there's many folks on wifi only.
I do think there's a good opportunity to (ask to?) enable it during the first-run "wizard". wdyt?
What happened?
I have observed this issue running Armbian v25.2.1 for Tinker Board running Armbian Linux 6.12.16-current-rockchip (Ubuntu noble server image).
This image uses NetworkManager for network config. When NM is used the NetworkManager-wait-online.service must be enabled so that network-online.target is not reached until NetworkManager has brought up all the interfaces. Service units that require the network to be up before starting rely on network-online.target working correctly otherwise they will likely fail on boot (which is the problem I observed).
See the systemd documentation, in particular the first two FAQs.
I encountered this problem when trying to set up a dhcp server, using the isc-dhcpd-server package. I correctly configured the dhcp server, enabled its unit and restarted it. It worked. However when I rebooted the Pi the dhcp server failed to start claiming "there was no subnet definition for end0". I figured out that this was because at the time isc-dhcp-server was starting the network had not yet come up, so dhcpd could not obtain the IP address & netmask for the interface to match with the subnet definition in the config file.
Reading the systemd documentation (linked above) I ran the suggested command to see if the wait services were enabled:
This reveals that NetworkManager-wait-online.service is disabled, when it should be enabled when NM is used to configure the network.
I enabled NetworkManager-wait-online.service and then rebooted. The dhcp server started correctly.
How to reproduce?
In a running Armbian system execute the following command (from the systemd documentation) and verify that the correct wait unit (depending on how network configuration is done in the image) is enabled:
Branch
main (main development branch)
On which host OS are you running the build script and observing this problem?
Other
Are you building on Windows WSL2?
Relevant log URL
No response
Code of Conduct
The text was updated successfully, but these errors were encountered: