consolidated s390 device configuration #2534

steffen-maier · 2023-10-13T14:11:23Z

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 · 2023-11-10T06:44:54Z

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.

Shell library, which can be sourced by other POSIX compatible shell scripts. Provide helper function parsing its stdin based on the syntax of kernel device driver parameter dasd_mod.dasd= and invoking chzdev to produce corresponding persistent device configurations. The helper function takes one argument, which is either "globals" or "ranges". For a complete configuration, call the function twice, first with "globals" and then with "ranges". The new script library file should be packaged in a core (sub)package of s390-tools so the script is available for initrd environments. Users with examples: Subsequent commit ("zdev/dracut: add rd.dasd parsing") introduces zdev/dracut/95zdev/parse-dasd.sh performing: zdev_parse_rd_dasd | zdev_parse_dasd_list globals 2>&1 | zdev_vinfo zdev_parse_rd_dasd | zdev_parse_dasd_list ranges 2>&1 | zdev_vinfo dracutdevs/dracut#2534 updates modules.d/80cms/cmssetup.sh performing: echo "$DASD" | zdev_parse_dasd_list globals 2>&1 | vinfo echo "$DASD" | zdev_parse_dasd_list ranges 2>&1 | vinfo The parsing code for rd.dasd using the same syntax as dasd_mod.dasd= is inspired by the own implementation that used to be in linuxrc.s390 of https://github.com/rhinstaller/anaconda. https://web.archive.org/web/20190721154444/https://www.redhat.com/archives/anaconda-devel-list/2009-February/msg00392.html https://www.spinics.net/linux/fedora/anaconda-devel/msg08316.html ("Re: Improved linuxrc.s390 (third try)") => 9249e40f42ff ("IBM improvements to linuxrc.s390 (#475350)") https://web.archive.org/web/20190721150254/https://www.redhat.com/archives/anaconda-devel-list/2009-July/msg00310.html => 5f0fcf6688d0 ("Update linuxrc.s390 and friends to reflect review comments.") https://web.archive.org/web/20190721125255/https://www.redhat.com/archives/anaconda-devel-list/2009-August/msg00158.html => 523095c86876 ("Handle activation of DASDs in linuxrc.s390 since loader no longer works") Signed-off-by: Steffen Maier <[email protected]>

Shell library, which can be sourced by other POSIX compatible shell scripts. Provide helper function parsing its stdin based on the syntax of kernel device driver parameter dasd_mod.dasd= and invoking chzdev to produce corresponding persistent device configurations. The helper function takes one argument, which is either "globals" or "ranges". For a complete configuration, call the function twice, first with "globals" and then with "ranges". The new script library file should be packaged in a core (sub)package of s390-tools so the script is available for initrd environments. Users with examples: Subsequent commit ("zdev/dracut: add rd.dasd parsing") introduces zdev/dracut/95zdev/parse-dasd.sh performing: zdev_parse_rd_dasd | zdev_parse_dasd_list globals 2>&1 | zdev_vinfo zdev_parse_rd_dasd | zdev_parse_dasd_list ranges 2>&1 | zdev_vinfo dracutdevs/dracut#2534 updates modules.d/80cms/cmssetup.sh performing: echo "$DASD" | zdev_parse_dasd_list globals 2>&1 | vinfo echo "$DASD" | zdev_parse_dasd_list ranges 2>&1 | vinfo The parsing code for rd.dasd using the same syntax as dasd_mod.dasd= is inspired by the own implementation that used to be in linuxrc.s390 of https://github.com/rhinstaller/anaconda. https://web.archive.org/web/20190721154444/https://www.redhat.com/archives/anaconda-devel-list/2009-February/msg00392.html https://www.spinics.net/linux/fedora/anaconda-devel/msg08316.html ("Re: Improved linuxrc.s390 (third try)") => 9249e40f42ff ("IBM improvements to linuxrc.s390 (#475350)") https://web.archive.org/web/20190721150254/https://www.redhat.com/archives/anaconda-devel-list/2009-July/msg00310.html => 5f0fcf6688d0 ("Update linuxrc.s390 and friends to reflect review comments.") https://web.archive.org/web/20190721125255/https://www.redhat.com/archives/anaconda-devel-list/2009-August/msg00158.html => 523095c86876 ("Handle activation of DASDs in linuxrc.s390 since loader no longer works") Github-ID: #158 Acked-by: Vineeth Vijayan <[email protected]> Acked-by: Peter Oberparleiter <[email protected]> Signed-off-by: Steffen Maier <[email protected]> Signed-off-by: Jan Höppner <[email protected]>

steffen-maier · 2023-12-14T14:37:45Z

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 · 2024-01-09T16:14:31Z

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")

This is a preparation for consolidating s390 network device config with dracutdevs/dracut#2534 ("feat(znet): use zdev for consolidated device configuration") https://github.com/steffen-maier/s390utils/pull/1/commits ("znet: migrate to consolidated persistent device config with zdev (#1937046,#1937048))" ("znet: clean up old deprecated persistent device config (#1937046,#1937048)"). With above consolidation, s390-specific low-level configuration information will no longer be in NetworkManager connections (nor ifcfg files), but in the persistent configuration database of chzdev from s390-tools. Since the kdump dracut module here depends on the "znet" dracut module [1] and "znet" will copy all persistent configuration into initrd as of above commit, all s390-specific information would already be in the kdump initrd. [1] 08de712 ("Move some dracut module dependencies checks to module-setup.sh"), 7148c0a ("add s390x netdev setup") However, it is more appropriate and also removes the copy dependency from "znet" to introduce the consolidated zdev mechanism for importing just the required network device config from the current active system configuration. It does not depend on any of the pull requests above. It does not depend on any existing persistent configuration and can replace the old function code. This is similar to dracut block device dependency handling in s390-tools zdev/dracut/95zdev-kdump. The old code only seems to work if there is exactly one s390-specific nmconnection (or ifcfg file). Related commits: b5577c1 ("Simplify setup_znet by copying connection profile to initrd"), 7d47251 ("Iterate /sys/bus/ccwgroup/devices to tell if we should set up rd.znet"), 8b08b4f ("Set up s390 znet cmdline by "nmcli --get-values""), ce0305d ("Add a new option 'rd.znet_ifname' in order to use it in udev rules"), 7148c0a ("add s390x netdev setup"). A bonding or teaming setup would have multiple following network interfaces, each of which would need a low-level config if they're s390 channel-attached network devices. The new code should be able to handle that by iterating the involved network interfaces. Chzdev only exports something if it's a device type it deems itself responsible for. Additional debugging output can be generated with e.g. dracut option "--stdlog 5" (or short -L5). It shows the chzdev export result, the output of chzdev export and import, and an overview of the resulting persistent config within the initrd. On systems, which default to using dracut option "--quiet", you might need an additional "--verbose" to counter "--quiet" so -L5 has effect. Typically combined with "--debug" to get a shell trace from building an initrd (Note: --debug does not increase the log levels). Signed-off-by: Steffen Maier <[email protected]> Reviewed-by: Philipp Rudo <[email protected]> Reviewed-by: Coiby Xu <[email protected]>

steffen-maier · 2024-03-05T13:23:58Z

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 · 2024-03-06T14:34:22Z

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

steffen-maier · 2024-03-11T17:49:47Z

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 · 2024-03-22T13:16:33Z

@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?

This is just internal to initrd, so we can already migrate the code to consolidated dasd device configuration with zdev https://github.com/ibm-s390-linux/s390-tools/tree/master/zdev/. The code change is transparent to users after dracut switch root. Signed-off-by: Steffen Maier <[email protected]>

This is just internal to initrd, so we can already migrate the code to consolidated zfcp device configuration with zdev https://github.com/ibm-s390-linux/s390-tools/tree/master/zdev/. The code change is transparent to users after dracut switch root. The generated persistent config of chzdev are pure udev rules so it has no dependency on other dracut modules such as zdev, or zfcp. Signed-off-by: Steffen Maier <[email protected]>

Depends on https://github.com/ibm-s390-linux/s390-tools commit 9b2fb1d4d2e2 ("zdev: add helper to convert from dasd_mod.dasd to zdev config"). This is just internal to initrd, so it's possible to migrate the code to consolidated dasd device configuration with zdev https://github.com/ibm-s390-linux/s390-tools/tree/master/zdev/. The code change is transparent to users after dracut switch root. The generated persistent config of chzdev are pure udev rules so it has no dependency on other dracut modules such as zdev, dasd, or dasd_mod. Instead now install the corresponding kernel device drivers here directly. Signed-off-by: Steffen Maier <[email protected]>

This is just internal to initrd, so we can already migrate the code to consolidated network device configuration with zdev https://github.com/ibm-s390-linux/s390-tools/tree/master/zdev/. The code change is transparent to users after dracut switch root. The generated persistent config of chzdev are pure udev rules so it has no dependency on the zdev dracut module. Keep the dependency on dracut module znet to at least pull in the required kernel device drivers. Since consolidated s390 network device configuration with zdev is used, it takes care of all s390-specific settings. None of the s390-specific ifcfg variables should be used anymore. NETTYPE, OPTIONS, PORTNAME, and CTCPROT can be removed entirely. SUBCHANNELS is kept because there are some dependency chains (probably around the key identifiying an interface which is not HWADDR): modules.d/35network-legacy/module-setup.sh parses (sources) each of /etc/sysconfig/network-scripts/ifcfg-* and if that contains SUBCHANNELS, create a symlink from the ifcfg file to /etc/sysconfig/network-scripts/ccw-${SUBCHANNELS}.conf modules.d/35network-legacy/ifup.sh installed as /sbin/ifup checks during team setup if a slave interface is an s390 channel-attached network interface and then parses (sources) /etc/sysconfig/network-scripts/ccw-${SUBCHANNELS}.conf from above, if that file exists Signed-off-by: Steffen Maier <[email protected]>

Signed-off-by: Steffen Maier <[email protected]>

These are handled by s390-tools zdev dracut module 95zdev as of ibm-s390-linux/s390-tools@06a30ae ("zdev/dracut: add rd.zfcp cmdline option handling"). Even though this removes one implementation of parsing rd.zfcp in dracut, above s390-tools change introduces another implementation of parsing the exact same rd.zfcp syntax. Therefore, it would be good to keep the documentation in man/dracut.cmdline.7 of dracut as one central place describing all s390 device types that dracut handles. This also fixes problems such as RHBZ 1552619/1745470. It was due to a duplicate configuration because the SUSE-specific module 95zfcp_rules does not have any distro-specific dependency and thus also ran in Red Hat distros. That also caused a kind of competition with 95zfcp regarding the same hook registration: inst_hook cmdline 30 "$moddir/parse-zfcp.sh" "luckily" 95zfcp wins since it runs lexicographically first and the first one registering the hook via inst_simple wins. Because commit c8aa1d9 ("95zfcp_rules: simplified rd.zfcp commandline for NPIV") extended the emitted rd.zfcp syntax for hostonly-cmdline in 95zfcp_rules, kdump initrds built with hostonly-cmdline parsed such rd.zfcp with 95zfcp, which did not understand the extended syntax yet and aborted early boot with a syntax error. It also seems that parse-zfcp.sh on its own is without effect because create_udev_rule() [similar to what zfcp_disk_configure had generated] does not handle the pre-requisite of setting an FCP device (vHBA) online first. So the rport match does not trigger unless something else happens to set an FCP device online [such as rules generated by zfcp_host_configure]. Related to commit d40c49a ("fix(zfcp_rules): remove collect based udev rule creators"). module-setup.sh having copied all udev rules from the root-fs into the initrd conflicted with s390-tools dracut module zdev-kdump, which intentionally only activates the dependencies of the kdump target. Signed-off-by: Steffen Maier <[email protected]>

Parsing of rd.zfcp is handled by s390-tools zdev dracut module 95zdev as of ibm-s390-linux/s390-tools@06a30ae ("zdev/dracut: add rd.zfcp cmdline option handling"). Even though this removes the last implementation of parsing rd.zfcp in dracut, above s390-tools change introduces another implementation of parsing the exact same rd.zfcp syntax. Therefore, it would be good to keep the documentation in man/dracut.cmdline.7 of dracut as one central place describing all s390 device types that dracut handles. For the time being, keep copying /etc/zfcp.conf. Retain the call of zfcp_cio_free so /etc/zfcp.conf gets processed even with the typical cio_ignore kernel boot parameter ignoring most devices. Also keep handling rd.zfcp.conf=0 so users can, at boot time, ignore /etc/zfcp.conf already copied into initrd. Preparation for consolidating persistent configuration with zdev. Signed-off-by: Steffen Maier <[email protected]>

These are handled by s390-tools zdev dracut module 95zdev as of ibm-s390-linux/s390-tools@9927023 ("zdev/dracut: add rd.dasd cmdline option handling"). Even though this removes one implementation of parsing rd.dasd in dracut, above s390-tools change introduces another implementation of parsing the exact same rd.dasd syntax. Therefore, it would be good to keep the documentation in man/dracut.cmdline.7 of dracut as one central place describing all s390 device types that dracut handles. module-setup.sh having copied all udev rules from the root-fs into the initrd conflicted with s390-tools dracut module zdev-kdump, which intentionally only activates the dependencies of the kdump target. Signed-off-by: Steffen Maier <[email protected]>

Parsing of rd.dasd is handled by s390-tools zdev dracut module 95zdev as of ibm-s390-linux/s390-tools@9927023 ("zdev/dracut: add rd.dasd cmdline option handling"). Even though this removes one implementation of parsing rd.dasd in dracut, above s390-tools change introduces another implementation of parsing the exact same rd.dasd syntax. Therefore, it would be good to keep the documentation in man/dracut.cmdline.7 of dracut as one central place describing all s390 device types that dracut handles. 95dasd/modules-setup.sh copies /etc/dasd.conf from root-fs into initrd. Retain the call of dasd_cio_free here so /etc/dasd.conf gets processed even with the typical cio_ignore kernel boot parameter ignoring most devices. Preparation for consolidating persistent configuration with zdev. Signed-off-by: Steffen Maier <[email protected]>

Parsing of rd.dasd is handled by s390-tools zdev dracut module 95zdev as of ibm-s390-linux/s390-tools@9927023 ("zdev/dracut: add rd.dasd cmdline option handling"). Even though this removes the last implementation of parsing rd.dasd in dracut, above s390-tools change introduces another implementation of parsing the exact same rd.dasd syntax. Therefore, it would be good to keep the documentation in man/dracut.cmdline.7 of dracut as one central place describing all s390 device types that dracut handles. For the time being, keep copying /etc/dasd.conf. The corresponding call to dasd_cio_free is in 95dasd_mod/parse-dasd-mod.sh and indirectly triggers processing of /etc/dasd.conf even with the typical cio_ignore kernel boot parameter ignoring most devices. Preparation for consolidating persistent configuration with zdev. Signed-off-by: Steffen Maier <[email protected]>

Remove any distribution-specifics from s390 channel-attached network device configuration. Similar to 95qeth_rules, copy the existing persistent network configuration into the initrd. This needs to go via chzdev import so chzdev updates (adds to) the cio_ignore persistent config inside the initrd, because other dracut modules such as zdev from s390-tools also import persistent (non-network) config into initrd and the set union of devices needs to end up in the cio_ignore persistent config inside the initrd. Additional debugging output can be generated with e.g. dracut option "--stdlog 5" (or short -L5). It shows the chzdev export result, the output of chzdev imports, and an overview of the resulting persistent config within the initrd. Typically combined with "--debug" to get a shell trace from building an initrd (Note: --debug does not increase the log levels). Note that nm-initrd-generator also parses rd.znet and rd.znet_ifname to fill in s390 options of a NetworkManager connection definition. Signed-off-by: Steffen Maier <[email protected]>

As of the preceding commit ("feat(znet): use zdev for consolidated device configuration"), rd.znet is no longer specific to RHEL/Fedora. Signed-off-by: Steffen Maier <[email protected]>

Dracut module 95znet handles a superset of qeth_rules as of the preceding commit ("feat(znet): use zdev for consolidated device configuration"). The instmods list in installkernel() seemed to have been incomplete because qeth needs one or both of qeth_l2 and qeth_l3 but qeth intentionally does not depend on them so depmod cannot resolve that. In contrast to the old dracut module 95znet, 95qeth_rules also did not seem to have parsing for the upstream dracut cmdline options "rd.znet=" and "rd.znet_ifname=". Signed-off-by: Steffen Maier <[email protected]>

Otherwise the last rd.znet_ifname statement overwrites the persistent network interface settings of previous such statements. Signed-off-by: Steffen Maier <[email protected]>

Signed-off-by: Steffen Maier <[email protected]>

Since consolidated s390 network device configuration with zdev is used, it takes care of all s390-specific settings. None of the s390-specific ifcfg variables should be used anymore. NETTYPE and OPTIONS can be removed entirely. SUBCHANNELS is kept because there are some dependency chains (probably around the interface identifiying key, which is not HWADDR): modules.d/35network-legacy/module-setup.sh parses (sources) each of /etc/sysconfig/network-scripts/ifcfg-* and if that contains SUBCHANNELS, creates a symlink from the ifcfg file to /etc/sysconfig/network-scripts/ccw-${SUBCHANNELS}.conf modules.d/35network-legacy/ifup.sh installed as /sbin/ifup checks during team setup if a slave interface is an s390 channel-attached network interface and then parses (sources) /etc/sysconfig/network-scripts/ccw-${SUBCHANNELS}.conf from above, if that file exists Signed-off-by: Steffen Maier <[email protected]>

steffen-maier · 2024-03-22T14:57:31Z

rebased to resolve merge conflict with just merged #2630

dtardon · 2024-03-25T10:01:35Z

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 · 2024-03-25T11:19:56Z

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.

This was referenced Oct 13, 2023

consolidated s390 device configuration openSUSE/kdump#40

Closed

consolidated s390 device configuration - step 2: cleanup steffen-maier/s390utils#1

Draft

LaszloGombos added the enhancement Issue adding new functionality label Oct 30, 2023

LaszloGombos requested a review from lnykryn October 30, 2023 13:51

steffen-maier force-pushed the zdev branch from 563de69 to 20c2d93 Compare November 8, 2023 16:11

steffen-maier mentioned this pull request Nov 10, 2023

Improve lsinitrd to ease debugging for developers and end users. #2552

Open

3 tasks

steffen-maier force-pushed the zdev branch from 8c56334 to 303ec48 Compare November 10, 2023 17:35

steffen-maier force-pushed the zdev branch from 303ec48 to 8011fbe Compare November 22, 2023 15:37

steffen-maier marked this pull request as ready for review December 14, 2023 14:38

steffen-maier requested review from haraldh and johannbg as code owners December 14, 2023 14:38

rvykydal mentioned this pull request Jan 4, 2024

consolidated s390 device configuration rhinstaller/anaconda#5250

Merged

steffen-maier force-pushed the zdev branch from 8011fbe to 6493695 Compare January 9, 2024 16:14

github-actions bot added the man label Jan 9, 2024

steffen-maier force-pushed the zdev branch from 98b2b40 to 57926d8 Compare March 6, 2024 14:32

steffen-maier force-pushed the zdev branch from 57926d8 to 21f9139 Compare March 11, 2024 17:46

steffen-maier added 16 commits March 22, 2024 15:44

refactor(cms): remove now unnecessary inclusion of full s390utils-base

d71591f

Signed-off-by: Steffen Maier <[email protected]>

docs(dracut.cmdline): generalize description of rd.znet

2ba3d44

As of the preceding commit ("feat(znet): use zdev for consolidated device configuration"), rd.znet is no longer specific to RHEL/Fedora. Signed-off-by: Steffen Maier <[email protected]>

fix(znet): append to udev rules so each rd.znet_ifname is effective

b0197bc

Otherwise the last rd.znet_ifname statement overwrites the persistent network interface settings of previous such statements. Signed-off-by: Steffen Maier <[email protected]>

refactor(ifcfg): delete code duplication using iface_get_subchannels()

71688c1

Signed-off-by: Steffen Maier <[email protected]>

steffen-maier force-pushed the zdev branch from 21f9139 to b2f3373 Compare March 22, 2024 14:55

This was referenced Apr 2, 2024

consolidated s390 device configuration dracut-ng/dracut-ng#71

Closed

consolidated s390 device configuration dracut-ng/dracut-ng#73

Merged

aafeijoo-suse mentioned this pull request Jun 11, 2024

Consolidated s390 device configuration openSUSE/dracut#342

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

consolidated s390 device configuration #2534

consolidated s390 device configuration #2534

steffen-maier commented Oct 13, 2023 •

edited

Loading

dtardon commented Nov 10, 2023

steffen-maier commented Dec 14, 2023

steffen-maier commented Jan 9, 2024

steffen-maier commented Mar 5, 2024

steffen-maier commented Mar 6, 2024

steffen-maier commented Mar 11, 2024

steffen-maier commented Mar 22, 2024

steffen-maier commented Mar 22, 2024

dtardon commented Mar 25, 2024

tblume commented Mar 25, 2024

consolidated s390 device configuration #2534

Are you sure you want to change the base?

consolidated s390 device configuration #2534

Conversation

steffen-maier commented Oct 13, 2023 • edited Loading

Changes

Checklist

dtardon commented Nov 10, 2023

steffen-maier commented Dec 14, 2023

steffen-maier commented Jan 9, 2024

steffen-maier commented Mar 5, 2024

steffen-maier commented Mar 6, 2024

steffen-maier commented Mar 11, 2024

steffen-maier commented Mar 22, 2024

steffen-maier commented Mar 22, 2024

dtardon commented Mar 25, 2024

tblume commented Mar 25, 2024

steffen-maier commented Oct 13, 2023 •

edited

Loading