Bug 1443587 - Default route is not being set via ip= boot option
Summary: Default route is not being set via ip= boot option
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: anaconda
Version: 7.3
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Anaconda Maintenance Team
QA Contact: Release Test Team
Depends On:
TreeView+ depends on / blocked
Reported: 2017-04-19 14:06 UTC by Lukas Zapletal
Modified: 2017-08-30 08:17 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-06-19 17:51:10 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1433891 None NEW Problems with GUI/tui reconifiguration of NIC having static config from initramfs if there is another dhcp-configured NI... 2019-07-09 09:33:35 UTC

Internal Links: 1433891

Description Lukas Zapletal 2017-04-19 14:06:56 UTC

Anaconda from RHEL 7.3 does not appear to be setting up correctly default route. On a server with 4 NICs this boot configuration configures IP and DNS but not default route:

ks=http://a_server/unattended/provision?token=abcd inst.ks.sendmac ip=10.xxx.9.142::10.xxx.8.1:255.255.xxx.0:::none nameserver=10.xxx.34.18 ksdevice=bootif BOOTIF=00-6c-ae-8b-61-aa-aa

Anaconda starts up correctly but due to missing default route, kickstart cannot be downloaded as in our case it is in different network. In the NetworkManager configuration the default route line is blank (this is pseudo-shell):

grep GATEWAY /etc/sysconfig/network-scripts/ifcfg-eno1

No default route is set in /etc/sysconfig/network either (the file is missing actually).

Comment 3 Lukas Zapletal 2017-04-19 14:13:09 UTC
Relevant documentation part:


I see that ksdevice=bootif is now ignored, we can re-test with ksdevice=AA:BB:CC:DD:EE:FF but it is not clear in which format MAC address should be (assuming : notation).

Comment 5 Radek Vykydal 2017-04-26 10:18:06 UTC
Please attach the kickstart used and installer logs gathered when the problem occurs as individual text/plain attachments.


They can be found also on installed system in /var/log/anaconda.

Comment 7 Radek Vykydal 2017-04-27 11:40:14 UTC
The case from the Description seems to be working for me (there is a default route for the device), but I am not using any kickstart configuration.
The situation may get more complicated if also another device is activated with dhcp in initramfs (as described in the link from comment #6). That is why I'd need to see the logs and the kickstart to investigate your case. Also, it would be good to run the installation with rd.debug option if possible.

Comment 13 Lukas Zapletal 2017-05-22 11:07:48 UTC
Thanks Radku, since the customer reports it is working again, if you can't spot anything suspicious in the logs, I suggest to close this one.

Comment 14 Chris Williams 2017-06-19 17:51:10 UTC
Closing this BZ as the SF Case(s) is/are closed which means we need to focus on more critical BZs. Please re-open if new SF cases are attached and the issue is important to the customer.

Comment 15 Hendra 2017-08-30 08:17:28 UTC
I'm having similar problem kickstarting 7.3 on a system with dual multi-ports NICs (2 x 4 ports). 
Kickstart fails as it is unable to connect to the installation source URL due to missing default route. If I open up the shell (Alt+F2) during "Starting automated install...." is shown on the console add manually add the default route, then the kickstart will proceed smoothly. 
No such problem with 7.1.

.. nomodeset inst.text initrd=7.3-x86_64/initrd.img inst.ks=http://foo/bar/ks.cfg ksdevice=xx:xx:xx:xx:xx:xx ip=10.xxx.8.123::10.xxx.8.1:255.255.xxx.0:svrname::none linksleep=55  inst.sshd inst.ks.kssendmac inst.syslog=xxx.xxx.xxx.xxx:514  net.ifnames=0 biosdevname=0 BOOTIF=30:e1:71:6f:40:08 rd.debug rd.net.timeout.carrier=60 rd.net.timeout.ifup=60

Note You need to log in before you can comment on or make changes to this bug.