-
Notifications
You must be signed in to change notification settings - Fork 0
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
base: rawhide
Are you sure you want to change the base?
Conversation
…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]>
Signed-off-by: Steffen Maier <[email protected]>
Depends on https://github.com/ibm-s390-linux/s390-tools/releases/tag/v2.31.0. Link: rhinstaller/anaconda#5250 (comment) Signed-off-by: Steffen Maier <[email protected]>
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)"). |
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.