Bug 1910438
| Summary: | RHEL 8.3 anaconda fails to propagate static IP provided on kernel command via 'ip=' to installed OS instance. | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | James Hartsock <hartsjc> | |
| Component: | anaconda | Assignee: | Anaconda Maintenance Team <anaconda-maint-list> | |
| Status: | CLOSED ERRATA | QA Contact: | Release Test Team <release-test-team-automation> | |
| Severity: | high | Docs Contact: | ||
| Priority: | high | |||
| Version: | 8.3 | CC: | anaconda-maint-list, jcastran, jstodola, lmiksik, matthew.lesieur, mkenjale, pgm-rhel-tools, rmullett, rvykydal, sbueno, till, zveleba | |
| Target Milestone: | rc | Keywords: | Regression, Triaged | |
| Target Release: | 8.0 | Flags: | pm-rhel:
mirror+
|
|
| Hardware: | All | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | anaconda-33.16.4.15-1.el8 | Doc Type: | Bug Fix | |
| Doc Text: |
Cause:
After replacement of dracut network module with NetworkManager in initramfs in RHEL 8.3 the BOOTIF boot option was not used to select the interface for static network configuration set by ip= dracut boot option with interface specification left out.
Consequence:
On installed system the interface specified by the BOOTIF option was configured to use DHCP.
Fix:
Anaconda's methods for finding the right connection to be passed to the installed system were updated to match the right connections created by NetworkManager based on the boot options.
Result:
In case of static configuration via ip= boot option with unspecified interface, the interface specified by BOOTIF option is now configured with the expected static configuration on the installed system.
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 1940513 (view as bug list) | Environment: | ||
| Last Closed: | 2021-05-18 15:47:13 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: | ||||
| Bug Depends On: | 1915493 | |||
| Bug Blocks: | 1940513 | |||
|
Description
James Hartsock
2020-12-23 22:45:12 UTC
Copied my 'ip route' not 'ip addr' by mistake for the failing RHEL 8.3
[anaconda root@localhost ~]# ip -4 addr
4: enp1s0f2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
inet 192.168.122.254/24 brd 192.168.122.255 scope global noprefixroute enp1s0f2 <<<<<<< Using command line static ip=
valid_lft forever preferred_lft forever
Yes, if the interface is not specified in ip= dracut configuration Anaconda fails to dump the generic "Wired Connection" created in initramfs into enp1s0f1 configuration file and creates default connection using auto/dhcp ipv4 method. This has been fixed upstream by https://github.com/rhinstaller/anaconda/commit/05a80bb599d6e2ea694279ed4257a11a361b894d . I think it should be possible to port the fix to RHEL 8.4. As regression in RHEL 8.0, 8.1, 8.2 behavior and impacting installing of RHEL 8 is there a z-stream planned? Customer is only using 1 ip=, the multiple was me testing more differences between 8.2 & 8.3 with move to NetworkManager in initramfs.
Customer is booting system for install (anaconda) only knowing the MAC address of the NIC. The ip= only allows to specify <interface> via name; however legacy network scripts have always allowed this to be blank when and uses the NIC specified in BOOTIF. Looking to have this same for RHEL 8.3 (and later) anaconda installs too. And per my testing NetworkManager seems to too; however, it uses 'Wired Conenction' as name and thus final install image doesn't have NIC configured as did in 8.0, 8.1, and 8.2.
Syntax in use is:
ip=<client-IP>:[<peer>]:<gateway-IP>:<netmask>:<client_hostname>:<interface>:{none|off|dhcp|on|any|dhcp6|auto6|ibft}[:[<dns1>][:<dns2>]]
Example is in comment 0
BOOTIF=52-54-00-33-00-94 ip=192.168.122.254::192.168.122.1:255.255.255.0:testhost.example.com::none:172.31.0.1:172.31.0.2
Before fixing anaconda (this bug), I would recommend:
* reporting a new bug against NetworkManager to clarify if ip= without the interface name is supported or not to prevent any unexpected surprises in the future.
* reporting a new bug against dracut, since "man nm-initrd-generator" refers to "dracut.cmdline(7) manual for the documentation of the precise format of the values supported". Also the installation guide refers dracut.cmdline man page [1]. So dracut's man page needs be updated or the references changed with the updated syntax:
ip=<client-IP>:[<peer>]:<gateway-IP>:<netmask>:<client_hostname>:[<interface>]:{none|off|dhcp|on|any|dhcp6|auto6|ibft}[:[<dns1>][:<dns2>]]
[1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/performing_a_standard_rhel_installation/custom-boot-options_installing-rhel#network-boot-options_custom-boot-options
Sounds like plan to me, go for it! If anaconda has a different syntax to boot and install a system only knowing the MAC address with resulting installed OS image still using Predictable Network Interface Name, I welcome the syntax. If you use the ifname= to assign name to the MAC-Address and use that name in ip= ... anaconda ends up using this name/alias. BTW - RHEL 7 still supported the RHEL 6 method of following ... so am aware of that method, just not another one for RHEL 8 anaconda. BOOTIF=<MAC> ip=<IP> gateway=<GW> netmask=<Mask> hostname=rhel7.example.com Any word on the new BZs? Or, other ways to accomplish setting static IP while maintain persistent network names when only know MAC address for install for RHEL 8? Bug 1915493 reported against NetworkManager. PR for Anaconda kickstart test covering the use case: https://github.com/rhinstaller/kickstart-tests/pull/494 Port of the PR from comment #5: https://github.com/rhinstaller/anaconda/pull/3246 It has passed all kickstart network tests. Scratch build with the patch: http://brew-task-repos.usersys.redhat.com/repos/scratch/rvykydal/anaconda/33.16.4.13/2.el8/ Additional patch dealing with use case from https://bugzilla.redhat.com/show_bug.cgi?id=1915493#c43: https://github.com/rhinstaller/anaconda/pull/3258 (In reply to Radek Vykydal from comment #25) > Additional patch dealing with use case from > https://bugzilla.redhat.com/show_bug.cgi?id=1915493#c43: > https://github.com/rhinstaller/anaconda/pull/3258 I am running kickstart tests on compose/iso with latest anaconda (conmment #24, comment #25) and NM (https://bugzilla.redhat.com/show_bug.cgi?id=1915493#c38) updates: http://file.brq.redhat.com/rvykydal/rhbz1910438/boot_anaconda_33.16.4.14-2_nm_1.30.0-4.2.iso created with lorax --product="Red Hat Enterprise Linux" --version=8.4 --release=8.4 \ --workdir ./lorax-work \ --variant=BaseOS --nomacboot --buildarch=x86_64 --volid=RHEL-8-4-0-BaseOS-x86_64 \ -s http://download.eng.brq.redhat.com/nightly/rhel-8/RHEL-8/latest-RHEL-8.4/compose/BaseOS/x86_64/os/ \ -s http://download.eng.brq.redhat.com/nightly/rhel-8/RHEL-8/latest-RHEL-8.4/compose/AppStream/x86_64/os/ \ -s http://download.eng.brq.redhat.com/nightly/rhel-8/RHEL-8/latest-RHEL-8.4/compose/CRB/x86_64/os/ \ -s http://brew-task-repos.usersys.redhat.com/repos/scratch/bgalvani/NetworkManager/1.30.0/4.1.bz1915493.el8/x86_64/ \ -s http://brew-task-repos.usersys.redhat.com/repos/scratch/rvykydal/anaconda/33.16.4.14/2_rhbz1910438.el8/x86_64 \ ./1910438_c25/ New kickstart test for the additional patch (ip= static configuration with device specified by MAC): https://github.com/rhinstaller/kickstart-tests/pull/497 (In reply to Radek Vykydal from comment #26) > -s > http://brew-task-repos.usersys.redhat.com/repos/scratch/bgalvani/ > NetworkManager/1.30.0/4.1.bz1915493.el8/x86_64/ \ -s http://brew-task-repos.usersys.redhat.com/repos/scratch/bgalvani/NetworkManager/1.30.0/4.2.bz1915493.el8/x86_64/ Updating the Doc Text field with a draft. *** Bug 1940513 has been marked as a duplicate of this bug. *** 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 (anaconda bug fix and enhancement update), 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/RHBA-2021:1844 |