Hi,
I'm not 100 percent confident this is the correct place for this but feel free to point me to a more appropriate place if there is one.. I'm seeing two separate issues with the latest version of IoT that I was hoping for some assistance with.
1. During boot if DHCP is unavailable it takes a significant amount of time to boot waiting for a timeout to occur. This seems to be related to dracut-network and ignition. The closest thing I could find was a bug report for CoreOS [1] that seemed to be a way to over ride that behavior but I personally couldn't get it to work. Is there a way to override this behavior? I have a system where an IPMI interface reports as having a link but can't get a DHCP address and thus is forced to wait for a timeout.
2. I can't set a static IP address within the OS even though per the docs [2] this should be possible (as it was on 31 IoT). Basically once you set a static address and boot there's a new network connection that's activated and utilizing DHCP while the static one is there unused. I've tried deleting the connection ,recreating it, etc and it just doesn't seem to stick.
[1] https://github.com/coreos/ignition-dracut/issues/94 [2] https://docs.fedoraproject.org/en-US/iot/admin-tasks/
Hi Leah,
I'm not 100 percent confident this is the correct place for this but feel free to point me to a more appropriate place if there is one.. I'm seeing two separate issues with the latest version of IoT that I was hoping for some assistance with.
It's a great place, we can work out where any bug report/issue(s) should be filed from here.
- During boot if DHCP is unavailable it takes a significant amount of time to boot waiting for a timeout to occur. This seems to be related to dracut-network and ignition. The closest thing I could find was a bug report for CoreOS [1] that seemed to be a way to over ride that behavior but I personally couldn't get it to work. Is there a way to override this behavior? I have a system where an IPMI interface reports as having a link but can't get a DHCP address and thus is forced to wait for a timeout.
OK, I have a few questions. Networks are hard to debug as everyone is different. Is there dhcp on the network segment or is it explicitly static only network? When you say IPMI is it the IPMI interface not getting an IP or you're observing this via IPMI. I would expect that the actual IPMI interface would be under Linux's control, they're usually their own little firmware.
The use of ignition and associated bits is still very new in Fedora IoT, we just introduced it for F-32 and there's still quite a bit to do. Things like static configurations are likely very raw.
- I can't set a static IP address within the OS even though per the docs [2] this should be possible (as it was on 31 IoT). Basically once you set a static address and boot there's a new network connection that's activated and utilizing DHCP while the static one is there unused. I've tried deleting the connection ,recreating it, etc and it just doesn't seem to stick.
I wonder if we missed a command there, does something like this work:
# nmcli con mod enp0s1 ipv4.addresses 192.168.1.42/24 # nmcli con mod enp0s1 ipv4.gateway 192.168.1.254 # nmcli con mod enp0s1 ipv4.method manual # nmcli con mod enp0s1 ipv4.dns "8.8.8.8" # nmcli con up enp0s1
Hi Peter,
Sorry for the delayed response. I didn't see this reply. In any case more information is below :)
OK, I have a few questions. Networks are hard to debug as everyone is different. Is there dhcp on the network segment or is it explicitly static only network? When you say IPMI is it the IPMI interface not getting an IP or you're observing this via IPMI. I would expect that the actual IPMI interface would be under Linux's control, they're usually their own little firmware.
I have DHCP running with a pool of addresses and some setup aside for static IPs but DHCP and everything works as expected. The weirdness comes in with interfaces that can get a link but can't get an address from DHCP such as this IPMI interface. Truthfully I'm not sure why it shows up as an interface at all but you can't really use it as one...honestly this is probably a separate issue entirely but not high on my list. Thinking more on this I suppose my main concern isn't that the timeouts occur as it makes sense since the images try to get addresses that way by default...it's more that I can't seem to find a way to change that behavior.
Another situation where this is problematic is I use Fedora IoT as a base for my router. There's approximately 5 interfaces that bring up with a majority of them requiring the timeouts to occur. Just to explain this a bit better there's two physical interfaces. One of those is the WAN side which gets an address from DHCP. The other physical interface and 4 sub interfaces (different VLANs) timeout as expected since the system itself is the DHCP server for those interfaces.
All of that is to say I just am not sure how to tell it to not attempt DHCP on those interfaces (the ipv4.method on all of those except for the WAN interface is set to static).
The first few lines of systemd-analyze blame: 3min 5.213s dracut-initqueue.service 8.519s fstrim.service 4.194s systemd-udev-settle.service 3.749s lvm2-monitor.service 2.869s dev-zram0.device 2.632s NetworkManager-wait-online.service 2.037s systemd-hwdb-update.service 1.670s systemd-logind.service 1.656s initrd-switch-root.service 1.373s systemd-homed.service 838ms systemd-networkd.service 821ms systemd-udevd.service 805ms zezere_ignition_banner.service 801ms systemd-journald.service 753ms iptables.service
The use of ignition and associated bits is still very new in Fedora IoT, we just introduced it for F-32 and there's still quite a bit to do. Things like static configurations are likely very raw.
I wonder if we missed a command there, does something like this work:
# nmcli con mod enp0s1 ipv4.addresses 192.168.1.42/24 # nmcli con mod enp0s1 ipv4.gateway 192.168.1.254 # nmcli con mod enp0s1 ipv4.method manual # nmcli con mod enp0s1 ipv4.dns "8.8.8.8" # nmcli con up enp0s1
So this does work...until a reboot. If I do the equivalent of those commands followed by a "nmcli con delete Wired\ Connection" to remove the original generated DHCP connection, nmcli con mod enp0s1 autoconnect yes, and a reboot just causes the creation of another "Wired\ Connection" that's utilizing DHCP with the connection with the static address unactivated.
I was able to figure out how to override this by using "rpm-ostree kargs --editor" and set "rd.neednet=0". This removes the dhcp polling on startup and the overriding of the manual configuration from within the os. Overall boot times changed from 3+ minutes to 20 seconds.
If there's a different/more preferred way to do this but this at least is working for me.
-
Leah Anderson -
Peter Robinson