consolidated s390 device configuration

[steffen-maier]

Consolidate the persistent and dynamic configuration of s390-specific devices in Linux distributions by delegating the configuration to the existing framework zdev from s390-tools.

This pull request completes distribution independent s390 device configuration in initrds built by dracut.
This also fixes a few known and newly discovered bugs in addition to the changes described below. Please see the commit descriptions for more bug fix information.
Some of the commits [see their description] depend on certain commits from ibm-s390-linux/s390-tools#158 and thus https://github.com/ibm-s390-linux/s390-tools/releases/tag/v2.31.0.

Zdev's job is to perform low-level configuration after which the user gets architecture-independent objects such as block devices, SCSI devices, or network interfaces. Those can and should in turn be configured with existing common code mechanisms. So there's a clear separated layering for configuration duties.

In particular, the s390-specific devices currently are: DASD (traditional disk), ZFCP (scsi), and ZNET representing channel-attached network (QETH incl. OSA and HiperSockets, LCS, CTC). Zdev has a stable command line user interface and abstracts from sysfs and from a persistent configuration representation. Zdev encapsulates configuration details. Systems management code can simply delegate configuration to zdev and thus reduce architecture-specific code.

This improves user experience, serviceability, maintainability, and reduces test effort.

@danimo @dtardon @haraldh @hramrach @hreinecke @jstodola @mwilck @sharkcz @smitterl @teclator

Changes

Dracut had 3 different plugin module sets to configure s390 devices. Those module sets partly competed with each other and partly contradicted each other such as activating too many devices for a memory-limited kdump environment.

• original modules from Red Hat: dasd, dasd_mod, znet, zfcp.
• additional modules from SUSE because the Red Hat modules were tightly coupled with the Red Hat specific persistent configuration mechanism and SUSE needed their own persistent mechanism: dasd_rules, qeth_rules, zfcp_rules.

Along with zdev as configuration backend, IBM introduced https://github.com/ibm-s390-linux/s390-tools/tree/master/zdev/dracut

• making use of zdev as consolidated configuration mechanism: zdev, zdev-kdump.

This change consolidates the 3 dracut module sets into one single module set. The user syntax with rd.dasd, rd.znet, and rd.zfcp remains the same; only the backend implementation changes to zdev.
Move dasd and zfcp into zdev of s390-tools (modules could alternatively exist in dracut but they are so tightly coupled with zdev that s390-tools seemed natural).
It supports dracut features: hostonly, hostonly-cmdline, print-cmdline.
Update znet and cms (cmsdasd & cmsconffile feature used by anaconda installer) and keep them in dracut because other code depends on these modules.

Checklist

• I have tested it locally
• I have reviewed and updated any documentation if relevant
• I am providing new code and test(s) for it

[dtardon]

Please submit the first two commits as a separate PR (or PRs). They make sense of their own and are not tied to the rest.

[steffen-maier]

Some of the commits [see their description] depend on certain commits from ibm-s390-linux/s390-tools#158.

was merged, so now turning this into a regular pull request

[steffen-maier]

rebased onto latest master and force pushed to resolve the merge conflicts, which meanwhile appeared due to upstream commit de8ac63 ("fix(github): update format of labeler")

[steffen-maier]

LaszloGombos requested a review from lnykryn 2023-10-30

Hello @lnykryn, I'm wondering how I can help getting the required two (green) approving reviews. With you being one of the required approvers, do @sharkcz's review comments with his "grey" approval and my corresponding subsequent code updates help? [1, 2] Can I do anything else?

[steffen-maier]

minor clarifications on rd.zfcp and rd.dasd in man/dracut.cmdline.7.asc

[steffen-maier]

Put temporary files under the subdir ${DRACUT_TMPDIR} in 5fc6649 ("feat(znet): use zdev for consolidated device configuration").
Idea from a kdump dracut module (which additionally has its own subdir under $DRACUT_TMPDIR).
Also used in the related ibm-s390-linux/s390-tools@849aa5b ("zdev/dracut: put temporary files under the subdir ${DRACUT_TMPDIR}").

[steffen-maier]

@johannbg moving discussion on s390 dracut modules here:

Anyways back to the s390-tools PR's what's the current status of that and in which direction are the upstream 390 taking with regards to init systems, is it being generic or moving towards systemd only?

In case you refer to the merged ibm-s390-linux/s390-tools#158 and the related pending #2534 here, it is distro-independent and only uses udev. AFAIK, udev has always been the base for dracut so we should be good? I'm not aware of any dependencies on systemd (or any other init system) for low-level configuration of s390-specific devices.

That said I'm not particularly fond of "partial" upstream, with that I mean we should not support some aspects of 390 here upstream while other parts of it is being maintained in 390 upstream repo which will double the load on everyone involved and quadruple it for anykind of support issues.

Do you mean the fact, that currently handling of DASD and ZFCP is moving to s390-tools, but ZNET remains in dracut? [as in the "Changes" section of the description of #2534 here] Originally, I thought I would move ZNET also into s390-tools, but refrained from doing so because other dracut modules have dependencies on modules/95znet, such as (these are the ones I'm aware of and were included in my function tests):

• dracut/modules.d/80cms/module-setup.sh

  Lines 11 to 14 in 5d2bda4

  	depends() {
  	arch=${DRACUT_ARCH:-$(uname -m)}
  	[ "$arch" = "s390" -o "$arch" = "s390x" ] || return 1
  	echo znet zfcp dasd dasd_mod bash

  (note that the other module dependencies on dasd dasd_mod zfcp go away with consolidated s390 device configuration #2534 so only znet would remain)
• as well as an out-of-tree (not in dracut upstream) kdump module such as https://src.fedoraproject.org/rpms/kexec-tools/blob/858de28447ff05b15ef3c7004f60c7babf1ab15c/f/dracut-module-setup.sh#_66.

I suppose we could theoretically move znet into s390-tools upstream as well, if all affected downstream package maintainers are OK with adapting runtime package requirements on (a particular minimum level of a new future version of) s390-tools, so the znet dracut module exists at initrd build time when dracut module cms or the kdump module depend on znet.
Would that be worth the effort?
In no particular order: @dtardon ? @pvalena ? (dracut packaging), @coiby (kdump-utils being factored out of downstream kexec-tools), @rvykydal (just FYI because anaconda uses znet and 80cms) @sharkcz (s390utils downsteam packaging of s390-tools), @aafeijoo-suse @tblume (dracut packaging), @ngueorguiev (s390-tools packaging), @joseivanlopez (distro installer might depend on znet), @hoeppnerj @steffen-eiden @oberpar @vneethv (s390-tools upstream and the zdev dracut module in there).

Any other alternative ideas?

[steffen-maier]

rebased to resolve merge conflict with just merged #2630

[dtardon]

I suppose we could theoretically move znet into s390-tools upstream as well, if all affected downstream package maintainers are OK with adapting runtime package requirements on (a particular minimum level of a new future version of) s390-tools,

Doesn't this PR already require that?

so the znet dracut module exists at initrd build time when dracut module cms or the kdump module depend on znet. Would that be worth the effort?

Yes, it would.

Any other alternative ideas?

This would have to be tested, but I think it it'd not be a problem if both projects provided the module; they would just have to use a different leading number. (Because only the module with the lower number would be loaded, if I read the code correctly). Then, after some transitional period, the dracut znet module could be dropped.

[tblume]

I suppose we could theoretically move znet into s390-tools upstream as well, if all affected downstream package maintainers are OK with adapting runtime package requirements on (a particular minimum level of a new future version of) s390-tools,

Doesn't this PR already require that?

so the znet dracut module exists at initrd build time when dracut module cms or the kdump module depend on znet. Would that be worth the effort?

Yes, it would.

Any other alternative ideas?

This would have to be tested, but I think it it'd not be a problem if both projects provided the module; they would just have to use a different leading number. (Because only the module with the lower number would be loaded, if I read the code correctly). Then, after some transitional period, the dracut znet module could be dropped.

I support that approach.
We are already using chzdev from the s390-tools for creating the udev rules for network device activation instead of the dracut znet module in our latest versions @SUSE.