RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1443587 - Default route is not being set via ip= boot option
Summary: Default route is not being set via ip= boot option
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: anaconda
Version: 7.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Anaconda Maintenance Team
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-04-19 14:06 UTC by Lukas Zapletal
Modified: 2020-07-16 09:27 UTC (History)
4 users (show)

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

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1433891 0 unspecified CLOSED Problems with GUI/tui reconifiguration of NIC having static config from initramfs if there is another dhcp-configured NI... 2021-02-22 00:41:40 UTC

Internal Links: 1433891

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
Note You need to log in before you can comment on or make changes to this bug.