Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
DescriptionJulian 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
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
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
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?
(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.
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