Bug 2027357

Summary:	s390x - ccw network device not created after synthetic ADD uevent
Product:	Red Hat Enterprise Linux 9	Reporter:	Julian Wiedmann <jwiedman>
Component:	s390utils	Assignee:	Dan Horák <dhorak>
Status:	CLOSED ERRATA	QA Contact:	Vilém Maršík <vmarsik>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	9.0	CC:	cmackows, dhorak, dledford, hca, rvr
Target Milestone:	rc	Keywords:	Triaged
Target Release:	---
Hardware:	s390x
OS:	Linux
Whiteboard:
Fixed In Version:	s390utils-2.19.0-2.el9	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-05-17 15:59:55 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:	1875375

Description Julian Wiedmann 2021-11-29 13:24:09 UTC

Description of problem:

When s390x network devices are enumerated during early boot (ie. prior to rootfs being available), they are subsequently not configured by the s390x-specific udev rule. Hence the system comes up without networking.


Version-Release number of selected component (if applicable):



How reproducible:

Always.

Steps to Reproduce:
1. create a .nmconnection or ifcfg file to configure a qeth network device
2. start the system without using initramfs, so that the qeth ccw devices are enumerated prior to udev being available
3. observe that the network device is not created

Alternatively, one can also test if the udev rule would execute the ccw_init script:

> # udevadm test --action=add /devices/css0/...
> ...
> 0.0.xxxx: /usr/lib/udev/rules.d/81-ccw.rules:3 RUN 'ccw_init'
> ...

Actual results:

The qeth network device isn't created.

Expected results:

The qeth network device gets created, based on the configuration in a .nmconnection or ifcfg file.

Additional info:

As discussed with Dan Horak, this needs a cherry-pick of https://fedorapeople.org/cgit/sharkcz/public_git/utils.git/commit/?id=02124d9b50c1a3e9884c0f87f7d679d2f68a7c63

Comment 1 Dan Horák 2021-12-14 09:13:47 UTC

*** Bug 2024346 has been marked as a duplicate of this bug. ***

Comment 3 IBM Bug Proxy 2021-12-14 09:28:25 UTC

------- Comment From WINTERA.com 2021-12-03 03:52 EDT-------
Is it possible to get debugdata from dbginfo.sh?

Comment 5 Vilém Maršík 2021-12-17 00:37:32 UTC

Could not reproduce on z/VM with s390utils-core-2.19.0-1.el9.1.s390x . Do you know if this version could contain the patch?

--- 

The system came up with network enabled, and I could connect by ssh:
[root@ibm-z-500 ~]# uptime
 19:36:12 up 0 min,  1 user,  load average: 0.00, 0.00, 0.00
[root@ibm-z-500 ~]# rpm -q s390utils-core
s390utils-core-2.19.0-1.el9.1.s390x
[root@ibm-z-500 ~]# cat /proc/cmdline
root=/dev/mapper/rhel_ibm--z--500-root crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M rd.dasd=0.0.0120 rd.lvm.lv=rhel_ibm-z-500/root rd.lvm.lv=rhel_ibm-z-500/swap cio_ignore=all,!condev BOOT_IMAGE=0

Comment 6 Dan Horák 2021-12-17 08:46:53 UTC

The fix is first included in s390utils-2.19.0-2.el9

I think you will need to remove the cio_ignore= from the kernel parameters too, then the environment should be very similar to the one from bug 2024346

Comment 7 Vilém Maršík 2021-12-18 22:06:12 UTC

Thanks, this seems to have worked, think to have reproduced the issue. However, I cannot find any s390x VM that can install latest RHEL9 and has its serial console working, to test the fix. Is that a known issue? What machine are you using?

Comment 8 Dan Horák 2022-01-06 08:40:24 UTC

(In reply to Vilém Maršík from comment #7)
> Thanks, this seems to have worked, think to have reproduced the issue.
> However, I cannot find any s390x VM that can install latest RHEL9 and has
> its serial console working, to test the fix. Is that a known issue? What
> machine are you using?

I had a VM from the High Availability QE team with console access via x3270. But I believe the new z15 beaker VMs have been already updated to have the console configured correctly.

Comment 21 errata-xmlrpc 2022-05-17 15:59:55 UTC

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 (new packages: s390utils), 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-2022:4005