Bug 1753975

Summary:	nm-initrd-generator doesn't process s390 specific device info from rd.znet parameter
Product:	[Fedora] Fedora	Reporter:	Dan Horák <dan>
Component:	NetworkManager	Assignee:	Lubomir Rintel <lkundrak>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	urgent	Docs Contact:
Priority:	urgent
Version:	31	CC:	bgalvani, bugproxy, dan, dcbw, fgiudici, gnome-sig, hannsj_uhl, john.j5live, jstodola, lkundrak, mclasen, rhughes, rstrode, sandmann, thaller
Target Milestone:	---
Target Release:	---
Hardware:	s390x
OS:	Linux
Whiteboard:
Fixed In Version:	NetworkManager-1.20.4-1.fc31	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-10-04 20:05:29 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:
Bug Blocks:	467765, 1727904

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 1 Dan Horák 2019-09-20 16:26:44 UTC

WIP patch posted in https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/281

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