On some bare-metal hardware (Dell PowerEdge in our case) due to systemd/udevd NIC renaming dance, a wrong default gw can be set. This blocks from provisioning. I believe that setting DEFROUTE=no on all the interfaces except the one we are booting from should fix the issue.
Since this issue was entered in Red Hat Bugzilla, the release flag has been set to ? to ensure that it is properly evaluated for this release.
Connecting redmine issue http://projects.theforeman.org/issues/7973 from this bug
Does this need a BZ against RHEL too, if it's caused by systemd/udevd?
Moving to POST since upstream bug http://projects.theforeman.org/issues/7973 has been closed ------------- Lukas Zapletal https://github.com/theforeman/ovirt-node-plugin-foreman/commit/f8ac33db72a8ece5a656442685e0285d0e470231
This will be actually fixed when Jason builds Discovery 2.0 for the first time.
Upstream bug assigned to lzap
QA: To VERIFY discover a host with multiple network cards and various combinations of card order. In all cases, the provisioning interface (the one on the discovery network) should be the default route (check with "ip route" command).
Verified with sat6.1 GA snap4 compose2: Looks like this issue is still reproducible. I tried to reproduce the original issue by discovering a host with multiple nics on libvirt compute-resource. Host was discovered but default route was not pointing to interface on discovery network. for ex: [root@fdi ~]# ip route default via 10.65.207.254 dev eth1 proto static metric 1024 10.65.201.89 via 10.65.207.254 dev eth3 proto static metric 1 10.65.206.0/23 dev eth1 proto kernel scope link src 10.65.207.34 10.65.206.0/23 dev eth3 proto kernel scope link src 10.65.207.187 192.168.110.0/24 dev eth0 proto kernel scope link src 192.168.110.35 192.168.110.0/24 dev eth2 proto kernel scope link src 192.168.110.36
Verified following image: foreman-discovery-image-2.1.0-20.el7sat.noarch [root@fdi network-scripts]# cat /usr/share/fdi/VERSION 2.1.0 [root@fdi network-scripts]# cat /usr/share/fdi/RELEASE 20150327.1
Reproduced!
el6 still uses the el7 wrapper RPM so this is MODIFIED now and will be in the next snap 6
Verified with sat6.1 GA snap6 Now provisioning interface eth0 is set on default route.. -- [root@fdi ~]# cat /usr/share/fdi/VERSION 2.1.0 [root@fdi ~]# cat /usr/share/fdi/RELEASE 20150525.1 [root@fdi ~]# ip route default via 192.168.100.1 dev eth0 proto static metric 100 default via 192.168.100.1 dev ens9 proto static metric 101 default via 10.16.99.254 dev ens11 proto static metric 102 10.16.36.29 via 10.16.99.254 dev ens11 proto dhcp metric 100 10.16.96.0/22 dev ens11 proto kernel scope link src 10.16.99.245 metric 100 169.254.95.0/24 dev ens10 proto kernel scope link src 169.254.95.120 metric 100 192.168.100.0/24 dev ens9 proto kernel scope link src 192.168.100.12 192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.11 metric 100 [root@fdi ~]# ifconfig eth0 eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.100.11 netmask 255.255.255.0 broadcast 192.168.100.255 inet6 fe80::5054:ff:fef3:c80a prefixlen 64 scopeid 0x20<link> ether 52:54:00:f3:c8:0a txqueuelen 1000 (Ethernet) RX packets 168 bytes 10082 (9.8 KiB) RX errors 0 dropped 2 overruns 0 frame 0 TX packets 9 bytes 1262 (1.2 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 [root@fdi ~] Thank you for fixing the issue.
This bug is slated to be released with Satellite 6.1.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2015:1592