forked from dracutdevs/dracut
-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consolidated s390 device configuration (SLFO) #343
Merged
aafeijoo-suse
merged 18 commits into
openSUSE:SLFO_Main
from
aafeijoo-suse:SLFO_Main-consolidate-s390-tools
Jun 25, 2024
Merged
Consolidated s390 device configuration (SLFO) #343
aafeijoo-suse
merged 18 commits into
openSUSE:SLFO_Main
from
aafeijoo-suse:SLFO_Main-consolidate-s390-tools
Jun 25, 2024
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Since we are using `actions/labeler@main`, its format changed, displaying the following error with every new PR: ``` Run actions/labeler@main The configuration file (path: .github/labeler.yml) was not found locally, fetching via the api Error: Error: found unexpected type for label 'repository' (should be array of config options) Error: found unexpected type for label 'repository' (should be array of config options) ``` (cherry picked from commit de8ac63)
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]> (cherry picked from commit dracut-ng/dracut-ng@6c55657)
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]> (cherry picked from commit dracut-ng/dracut-ng@53a5d10)
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]> (cherry picked from commit dracut-ng/dracut-ng@168c0c6)
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]> (cherry picked from commit dracut-ng/dracut-ng@0b6d695)
Signed-off-by: Steffen Maier <[email protected]> (cherry picked from commit dracut-ng/dracut-ng@166e8a2)
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]> (cherry picked from commit dracut-ng/dracut-ng@b5a35f9)
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]> (cherry picked from commit dracut-ng/dracut-ng@7745a81)
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]> (cherry picked from commit dracut-ng/dracut-ng@72c945c)
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]> (cherry picked from commit dracut-ng/dracut-ng@2397c47)
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]> (cherry picked from commit dracut-ng/dracut-ng@36e1f88)
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]> (cherry picked from commit dracut-ng/dracut-ng@658a21a)
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]> (cherry picked from commit dracut-ng/dracut-ng@8707a69)
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]> (cherry picked from commit dracut-ng/dracut-ng@198a86c)
Otherwise the last rd.znet_ifname statement overwrites the persistent network interface settings of previous such statements. Signed-off-by: Steffen Maier <[email protected]> (cherry picked from commit dracut-ng/dracut-ng@22f5173)
Signed-off-by: Steffen Maier <[email protected]> (cherry picked from commit dracut-ng/dracut-ng@2d8fa8b)
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]> (cherry picked from commit dracut-ng/dracut-ng@457e66e)
tblume
approved these changes
Jun 11, 2024
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
aafeijoo-suse
force-pushed
the
SLFO_Main-consolidate-s390-tools
branch
from
June 24, 2024 07:13
6ac3ebe
to
ed6374a
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See #342 for details.