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.