Skip to content
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 - step 2: cleanup #2632

Draft
wants to merge 19 commits into
base: master
Choose a base branch
from

Conversation

steffen-maier
Copy link

@steffen-maier steffen-maier commented Feb 29, 2024

This is the final cleanup as very last packaging step after #2534. The PR split was triggered by #2534 (comment). Intentionally only a draft PR for the time being, until Fedora packagers give a go after package updates for step 1 in 2534 could migrate existing persistent s390 device config and thus drop the depency on the removed dracut modules in this PR here.

Only the last 3 commits in here are specific to this PR, the preceding commits just carry the content of #2534 to provide the proper code base, because this PR builds on top of #2534.

Changes

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

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

@github-actions github-actions bot added modules Issue tracker for all modules ifcfg Issues related to the ifcfg module cms Issues related to the cms module dasd Issues related to the dasd module dasd_mod Issues related to the dasd_mod module dasd_rules Issues related to the dasd_rules module qeth_rules Issues related to the qeth_rules module zfcp Issues related to the zfcp module zfcp_rules Issues related to the zfcp_rules module znet Issues related to the znet module github Issues related to .github man labels Feb 29, 2024
@steffen-maier
Copy link
Author

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

@steffen-maier
Copy link
Author

rebased onto latest #2534

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 <maier@linux.ibm.com>
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 <maier@linux.ibm.com>
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 <maier@linux.ibm.com>
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 <maier@linux.ibm.com>
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
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 <maier@linux.ibm.com>
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 <maier@linux.ibm.com>
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 <maier@linux.ibm.com>
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 <maier@linux.ibm.com>
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 <maier@linux.ibm.com>
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 <maier@linux.ibm.com>
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 <maier@linux.ibm.com>
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 <maier@linux.ibm.com>
Otherwise the last rd.znet_ifname statement overwrites the persistent
network interface settings of previous such statements.

Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
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 <maier@linux.ibm.com>
This final cleanup is based on the assumption that users have migrated
their old deprecated persistent config with the help of s390utils
zfcpconfmigrate.sh, potentially invoked by a distribution upgrade.

Signed-off-by: Steffen Maier <maier@linux.ibm.com>
This final cleanup is based on the assumption that users have migrated
their old deprecated persistent config with the help of s390utils
dasdconfmigrate.sh, potentially invoked by a distribution upgrade.

Signed-off-by: Steffen Maier <maier@linux.ibm.com>
This final cleanup is based on the assumption that users have migrated
their old deprecated persistent config with the help of s390utils
dasdconfmigrate.sh, potentially invoked by a distribution upgrade.

Signed-off-by: Steffen Maier <maier@linux.ibm.com>
@steffen-maier
Copy link
Author

rebased onto latest #2534 (comment)

Copy link

stale bot commented Apr 22, 2024

This issue is being marked as stale because it has not had any recent activity. It will be closed if no further activity occurs. If this is still an issue in the latest release of Dracut and you would like to keep it open please comment on this issue within the next 7 days. Thank you for your contributions.

@stale stale bot added the stale communication is stuck label Apr 22, 2024
@steffen-maier
Copy link
Author

This is still relevant. I'm going to make another change to the "parent" #2534 and then rebase this PR here once more. Because this might not happen within 7 days, I comment here to keep this PR open.

@stale stale bot removed the stale communication is stuck label Apr 22, 2024
@mwilck
Copy link
Contributor

mwilck commented May 3, 2024

@steffen-maier, maybe you should rather proceed on dracut-ng/dracut-ng#73.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cms Issues related to the cms module dasd_mod Issues related to the dasd_mod module dasd_rules Issues related to the dasd_rules module dasd Issues related to the dasd module github Issues related to .github ifcfg Issues related to the ifcfg module man modules Issue tracker for all modules qeth_rules Issues related to the qeth_rules module zfcp_rules Issues related to the zfcp_rules module zfcp Issues related to the zfcp module znet Issues related to the znet module
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants