consolidated s390 device configuration #40
Conversation
Complements SUSE bug 1068040.
Dracut commit d40c49a8dfe2 ("fix(zfcp_rules): remove collect based udev
rule creators") states that the "collect" helper no longer exists.
Commit aacc0ae ("s390: update qeth udev rules") fixed this.
However, instead of manually immitating some version of udev rules from
zdev, call zdev itself to create proper persistent s390 network interface
device configuration. This also enables zdev's transparent handling for
cio_ignore (zdev needs to merge all CCW device bus-IDs into its persistent
device configuration).
To make it future-proof and if architecture is s390, run chzdev export
against each and every network interface in the dependency graph and let
chzdev decide if a low-level s390 persistent config is necessary.
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 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).
The remaining function kdump_setup_qeth() now only takes care of the qeth
network interface name as a high-level configuration.
Fixes: aacc0ae ("s390: update qeth udev rules")
Signed-off-by: Steffen Maier <[email protected]>
|
Hello Steffen, I applied your commit, thanks (the commit ID is different, because I also changed the NEWS file). Also thanks for the heads up about the zFCP regression. I haven't pushed it to master yet, because I'd like to coordinate with your s390-tools update. |
|
Hi Jiří,
Thanks for the very quick reaction. I can see my patch as ca98133 on the master branch.
I made a minor and optional review comment there, but it looks good to me.
You mean with my ca98133 but without your regression fix d063a38 ?
I don't think my s390-tools upstream changes are material for an existing distro major release such as SLE15-SPx.
I would suggest to push d063a38 to master. As you says it helps ensuring to avoid the regression. It won't hurt, nothing breaks even if combined with the s390-tools upstream changes: Both s390-tools and kdump would explicitly configure full zfcp paths for kdump initrds, and as both (s390-tools/zdev/dracut/95zdev-kdump and parsing of stored rd.zfcp from kdump) use chzdev for configuration, the config is automatically merged, i.e. no double device config will happen. In other words: Removing the special zfcp handling in kdump would be a pure (non-functional) cleanup; and we can revisit it once we know what's upstream and what will make it into ALP. |
thanks, in the end I decided to ignore cmdline() - the kdump dracut module already writes /etc/cmdline.d/ files directly, and indeed dracut --print-cmdline does not seem useful for anything, since dracut is always called through the mkdumprd wrapper. But thanks anyway!
no, sorry for not being clearer; I mean I pushed the broken 1.9.x version of kdump to ALP and SLE-15-SP6, so now the zfcp code is missing there. So the zfcp fix is needed; I pushed it to master and tagged as version 1.9.7 just now; will push this to SLE-15-SP6/ALP so that the zfcp regression is fixed. Thanks a lot! |
Consolidate the persistent and dynamic configuration of s390-specific network devices by delegating the configuration to the existing framework
zdevfrom s390-tools.This is part of a larger consolidation comprising:
ibm-s390-linux/s390-tools#158
dracutdevs/dracut#2534
However, there are no dependencies on these other pull requests, so the change here can go in independently. It only depends on zdev from s390-tools, which exists since years.
Zdev's job is to perform low-level configuration after which the user gets architecture-independent objects such as 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 network devices currently are: 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.
About zfcp
I had started developing this a while ago before there was commit 1f74c56 ("Simplify kdump-save and initrd generation") and had my own commit removing the zfcp special handling from commit 8189970 ("Explicitly request zFCP devices in kdump initrd").
However, removing the zfcp special handling actually depends on s390-tools commits (esp. the first one) to not cause a regression:
The remove_from_commandline from commit 5a1d3d4 ("Disable zfcp LUN scan in kdump kernel") is still required so users cannot accidentally enable zfcp auto lun scan for kdump by configuring zfcp.allow_lun_scan=1. Adding zfcp.allow_lun_scan=0 to the kdump commandline is superfluous since above s390-tools commit (which does the same in a different way) but it also does not hurt so just keep it.
@jiribohac @danimo @hramrach @hreinecke @mwilck @teclator