Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1753975 - nm-initrd-generator doesn't process s390 specific device info from rd.znet parameter
Summary: nm-initrd-generator doesn't process s390 specific device info from rd.znet pa...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 31
Hardware: s390x
OS: Linux
urgent
urgent
Target Milestone: ---
Assignee: Lubomir Rintel
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: ZedoraTracker 1727904
TreeView+ depends on / blocked
 
Reported: 2019-09-20 12:04 UTC by Dan Horák
Modified: 2019-11-06 17:24 UTC (History)
15 users (show)

Fixed In Version: NetworkManager-1.20.4-1.fc31
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-10-04 20:05:29 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
IBM Linux Technology Center 181601 0 None None None 2019-09-23 10:15:39 UTC

Description Dan Horák 2019-09-20 12:04:00 UTC
On s390x platform the network device bring-up is done in 2 steps. First is the construction of the device in the kernel from 3 native devices, in the second step the IP information is assigned. In initrd environment the first step is handled by dracut based on the rd.znet= parameter. The second step then by the ip= parameter. The current implementation of nm-initrd-generator handles the second step just fine, but the device representation in NetworkManager is lacking the information from the first step.

from the dracut shell:

switch_root:/run/NetworkManager/system-connections# cat enc800.nmconnection
Ýconnection¨
id=enc800
uuid=1626a11e-86d0-4a01-9801-a9e874f0a499
type=ethernet
interface-name=enc800
multi-connect=1
permissions=

Ýethernet¨
mac-address-blacklist=

Ýipv4¨
address1=10.16.104.70/21,10.16.111.254
dhcp-hostname=devel7.s390.bos.redhat.com
dns=10.11.5.19;
dns-search=
may-fail=false
method=manual

Ýipv6¨
addr-gen-mode=stable-privacy
dhcp-hostname=devel7.s390.bos.redhat.com
dns-search=
method=disabled

Ýproxy¨


As you can see the following parameters

802-3-ethernet.s390-subchannels:        0.0.0800,0.0.0801,0.0.0802
802-3-ethernet.s390-nettype:            qeth
802-3-ethernet.s390-options:            layer2=0,portno=0

normally defined for an interface on s390x are missing. As a result they are not dumped into the ifcfg file during the installation, making the installed system unusable.

Comment 2 Fedora Update System 2019-09-30 07:44:37 UTC
FEDORA-2019-998f473be9 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-998f473be9

Comment 3 Fedora Update System 2019-10-01 03:06:19 UTC
NetworkManager-1.20.4-1.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-998f473be9

Comment 4 Fedora Update System 2019-10-04 20:05:29 UTC
NetworkManager-1.20.4-1.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.

Comment 5 Jan Stodola 2019-11-06 17:24:57 UTC
One use case to consider for possible problems is the use when the prefixdevname [1] feature is enabled and a custom prefix for the network interface is chosen by the user.

It seems that prefixdevname is not available in Fedora for now, but it could be a problem in RHEL in the future.

[1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_basic_system_settings/using-prefixdevname


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