Bug 1443587

Summary:	Default route is not being set via ip= boot option
Product:	Red Hat Enterprise Linux 7	Reporter:	Lukas Zapletal <lzap>
Component:	anaconda	Assignee:	Anaconda Maintenance Team <anaconda-maint-list>
Status:	CLOSED WONTFIX	QA Contact:	Release Test Team <release-test-team-automation>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	7.3	CC:	cww, hendra, lzap, rvykydal
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-06-19 17:51:10 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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

Hello,

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
GATEWAY=

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:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Installation_Guide/chap-anaconda-boot-options.html

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.

/tmp/anaconda.log
/tmp/syslog
/tmp/ifcfg.log
/tmp/program.log

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