I’ll start with explaining my problem. I need to figure out the correct and intended way that Ubuntu Core has designed to configure IP addresses. In this case it is Ubuntu Core 16 clean install with nothing added or modified.
So to go down the line of attempts:
NetworkManager is not installed so not used.
Attempt to use netplan
Using this yaml file (below) in /etc/netplan directory correctly sets everything as intended but experience the same isssue described in this forum post https://ubuntuforums.org/showthread.php?t=2323253 but due to Ubuntu Cores read only file system, changing any of these time out values is not an option.
Use nmcli
This works to allow static and dhcp to set, the boot issue from netplan doesn’t exist but there’s no hotplug option anymore. This means if I don’t have a static port plugged in, the ip address is not available. I need that solution to exist and this seems the most stable but missing this feature.
Am I missing something in any of this? Is there a solution for netplan for Ubuntu Core? Or I’d even take a nmcli solution that allows static IP’s to remain when unplugged.
I am aware of console.conf but this is not a viable solution as I need this to be done via software, not an interactive interface through the terminal.
systemd-networkd is waiting for a link if a device isn’t disabled like a system does with ifupdown if you configure eth0, don’t plug a cable in and don’t define allow-hotplug.
This is exactly the same behavior, netplan needs an equivalent option…
Which part of systemd-networkd is doing the waiting and what it turn is waiting for it? My understanding, and this may be wrong, is that this comes from something waiting for the systemd network-online target, and I’d like to know what is waiting for that so we can make it stop! If something else is going on, I think we still need more details.
i have sadly no idea, my theory is that systemd-networkd simply doesnt emit the event as long as there is n link up…
something in the chain respects allow-hotplug when ifupdown is used though (either because ifupdown simply hides the interface from network-online target or because network-online target actually catches the allow-hotplug setting and skips the interface)
There is an older bug about the topic at:
Digging deeper on a freshly installed pi3 i see two things:
any snap you install later that uses the snapd network interface also installs a service unit with Wants=network-online.target (though that indeed wont affect boots without these snaps installed)
After some fairly extensive testing on using netplan, interfaces files in /etc/network/interfaces.d/ and playing around with the network-manager snap I believe I can comment at least closer to a solution for this issue.
First off I need to correct my initial statement of network-manager not being installed was wrong. It is installed as a snap by default, I just failed to notice this due to my attempt to start it as a regular service rather than interact with it as a snap not realizing that nmcli was actually an aliased command for network-manager.nmcli in the network-manager snap. This does cause a small problem when using netplan-apply with network-manager defined as netplan doesn’t use the snap by tries the systemctl methods to access network-manager so restarting the system is the most consistent way to make this take effect. I can explicitly call
nmcli con up id ‘Connection’
for each connection shown on nmcli c which will show up something like netplan-eth0 for each connection defined in the yaml file but I haven’t had 100% success with this process.
Removing any manual connections made using nmcli and re-introducing the yaml file alone doesn’t solve the issue because network-manager needs to be enabled by netplan which means there’s another file in /etc/netplan that needs to be left alone that I removed initially. This file is 00-default-nm-renderer.yaml which only holds the contents:
network:
renderer: NetworkManager
Without this file, network manager doesn’t get enabled and the slow boot exists. I’ve tried adding the renderer option to the single yaml file but this does not work for some reason I have yet to figure out so I have had to leave this as a separate config file.
So ultimately this means that NetworkManager must be enabled via one yaml file and active to prevent the slow boot when things aren’t connected and/or plugged in but still allow netplan to be configured via yaml files. Unfortunately the lack of hotplug in netplan does still keep static IP’s from being assigned unless plugged in which means ifconfig isn’t a sufficient inspection tool but with a little extra work, you can examine the managed connections again with nmcli and find out what the IP address is even if not connected.
nmcli -p con show netplan-eth1 | grep ipv4.addresses | awk ‘{print $2}’
Which image are you using exactly, we definitely do not install it on our default ones (you might be using some vendor image shipped with some hardware over there i guess)…
This is an image provided by Dell for their Edge Gateway 5000 series.
If the NetworkManager snap isn’t installed by default, then I would say there is definitely a pretty big issue on this default OS to handle IP configurations since having it enabled is the only way I’ve managed to have a stable boot and IP connections. I don’t have an issue using this configuration method but not having access to the nmcli commands from within a container using the docker snap (so far as my attempts have gone) is going to present me with some challenges i’m not looking forward to. If I could only use the yaml files and netplan alone that would be a much preferred method and not have the same hurdles.
Ah, yes, Dell indeed does include network-manager out of the box on these devices…
Note that most developer boards we provide images for come with a single NIC though (the RPi3 is an exception), which is why this netplan issue did not hit as hard yet …
Well the good news is that network-manager solves the netplan issue, hotplug option excluded, so there is a solution currently ready. Now if there is a way to access network-manager from within a docker container, separate issue but one that would make my use case complete.
