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 1: migration #2

Open
wants to merge 5 commits into
base: rawhide
Choose a base branch
from

Conversation

steffen-maier
Copy link
Owner

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

This is a factored-out first step of #1. The split is based on dracutdevs/dracut#2534 (comment).
The first three commits only add the migration scripts. They only depend on old chzdev functionality , which existed since s390-tools v1.33.0. I think this could go into s390utils anytime and is a pre-req for some other package pull requests around "consolidated s390 device configuration".
More precisely, the used chzdev command line option --no-settle was only introduced with ibm-s390-linux/s390-tools@f32bff9 ("zdev: Implement --no-settle ") in v2.5.0. And there have been some bugfixes since then (such as ibm-s390-linux/s390-tools@2a1a821 in v2.28.0). Anyway, what I'm trying to say is: something recent would be good but we don't need v2.31.0 (i.e. no dependency on ibm-s390-linux/s390-tools#158).

The second to last commit is an independent spec file cleanup, because I got confused by upstream vs. downstream files / udev rules.

The last commit is for packaging https://github.com/ibm-s390-linux/s390-tools/releases/tag/v2.31.0. It's not really related to the migration scripts and you can pick the last commit at your convenience when you rebase s390utils to upstream v2.31.0.

@jstodola @sharkcz this is a pseudo PR not meant to be merged but to provide a review comment opportunity for this patch set and or you to get commits from here into https://src.fedoraproject.org/rpms/s390utils.

…37046,#1937048)

Implements the zfcp part of referenced bugs.

This also fixes real customer problems with Live Guest Relocation under
z/VM SSI, where the destination has vHBAs with different device bus-IDs.
56-zfcp.rules only triggers on initialization of the zfcp device driver.
Even though users had persistently configured vHBAs (with full zfcp paths)
in /etc/zfcp.conf, it could not automatically activate the vHBAs on the
destination after relocation and thus lost all paths.
Zdev persistent config udev rules selectively trigger on hotplug of
vHBA devices (and of FC remote ports).

The new script zfcpconfmigrate.sh needs to be called at an appropriate time
during distribution upgrade. If /etc/zfcp.conf exists, it automatically
migrates /etc/zfcp.conf to zdev persistent config and moves the old
zfcp.conf to a backup file. To prevent overwriting potentially existing
backups of the old persistent configuration, simply use a timestamp so we
don't overwrite old migration backups.

Signed-off-by: Steffen Maier <[email protected]>
…37046,#1937048)

Implements the dasd part of referenced bugs.

The new script dasdconfmigrate.sh needs to be called at an appropriate time
during distribution upgrade. If /etc/dasd.conf exists, automatically
migrate /etc/dasd.conf to zdev persistent config and move the old dasd.conf
to a backup file. To prevent overwriting potentially existing backups of
the old persistent configuration, simply use a timestamp so we don't
overwrite old migration backups.

Nothing should ever add device bus-IDs to the dasd option for the dasd
kernel module ("dasd.dasd=..." on the kernel command line or corresponding
modprobe.d files with "options dasd dasd=..."). The dasd module option is
supposed to be only used for global settings. Individual DASD devices
should only be configured by means of chzdev.

The only exception is to enable DASDs at boot time for a non-hostonly
initrd such as when booting a distro installer.

Signed-off-by: Steffen Maier <[email protected]>
…37046,#1937048)

Implements the s390 channel-attached network device, and thus the last,
part of referenced bugs.

In contrast to ccw_init, which only seems to configure LAYER2 mode, the new
migration script migrates all s390 options from nmconnections and so all
options will be effective after migration.

The new script znetconfmigrate.sh needs to be called at an appropriate time
during distribution upgrade. For any ifcfg or NetworkManager
configurations, it automatically migrates the s390-specific part to zdev
persistent config, exports a backup file of the old configuration, and
removes the s390-specific part from the old configuration.
To prevent overwriting potentially existing backups of the old persistent
configuration, simply use a timestamp so we don't overwrite old migration
backups.

Signed-off-by: Steffen Maier <[email protected]>
@steffen-maier
Copy link
Owner Author

steffen-maier commented Feb 29, 2024

The last commit is for packaging https://github.com/ibm-s390-linux/s390-tools/releases/tag/v2.31.0. It's not really related to the migration scripts and you can pick the last commit at your convenience when you rebase s390utils to upstream v2.31.0.

Just noticed that the rebase already happened with https://src.fedoraproject.org/rpms/s390utils/c/0226a1b211c6f94017623548bd9f544dd9168299?branch=rawhide. Please ignore my commit ("adapt spec file for upstream s390-tools zdev changes (new helpers)").

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant