Fedora Account System
Red Hat Associate
Red Hat Customer
Currently we use plain text files (/etc/dasd.conf, /etc/zfcp.conf, network interface scripts) for configuring persistent devices on s390x. We want to switch to the upstream provided mechanism known as zdev (and provided by s390utils), which is based on udev rules for each device. We need to convert handling - DASDs - zFCP/SCSI disks/LUNs - network interfaces
DASDs - /etc/dasd.conf is written by _write_dasd_conf() in pyanaconda/storage/installation.py - /etc/dasd.conf is read by dracut_setup_args() in blivet/devices/disk.py to produce a set of kernel command line parameters (rd.dasd=...), but this is not required when zdev udev rules are in place - /etc/dasd.conf must exists for the (legacy) 95dasd module to work, so we will keep it empty - for setting up the DASDs we will need to prepare the "export/import" file and feed it into chzdev in the sysimage chroot, reuse _write_dasd_conf() - zdev dracut module detects disks for rootfs from the running system, how this will work for the installer environment?? - last step in the converion process will be removal of dasd.udev and dasdconf.sh from s390utils and adapt device_cio_free
zFCP/SCSI - I think similar process like for DASDs can be used
You can watch the progress of my proof-of-concept at https://github.com/sharkcz/anaconda/commits/zdev It should be capable of - converting the internal DASD storage config into a "export/import" file that chzdev can read/process - write the individual device udev rules at the end of the installation just before initrd will be (re)created - the created initrd should pick up automagically the rules required for the root fs, thanks to zdev's dracut module Right now we use /etc/zdev.conf (only /etc exists in the time when it's written) in the system being installed and run "chzdev" in the sysroot. Other option is to use a local file and run "chzdev" with "--base /etc=$sysroot/etc" option.
a brief status update - the changes in the zdev branch seems to work for initializing DASDs, but chzdev has a bug, so it cannot find all devices for root fs (see the linked github issue) - anaconda still adds rd.dasd= parameters on the kernel command line, this can be omitted - we use/create /etc/zdev.conf in the installed system for the initial import by chzdev, we should remove it at the installation end or move it to /root or /var/log/anaconda, for reference only
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle. Changing version to 33.
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 33 changed to end-of-life (EOL) status on 2021-11-30. Fedora 33 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
This bug appears to have been reported against 'rawhide' during the Fedora 36 development cycle. Changing version to 36.
------- Comment From MAIER.com 2023-01-25 11:00 EDT------- Hi Dan, LTC bug 200649 / Red Hat bug 2149846 indirectly triggered me to look at this as well as there is some relation via mkdumprd and dracut. Please note that my comments below are only based on the zfcp part. I would hope other device types could be done in a similar fashion but no promises. (In reply to comment #4) > Currently we use plain text files (/etc/dasd.conf, /etc/zfcp.conf, network > DASDs > - /etc/dasd.conf is written by _write_dasd_conf() in > pyanaconda/storage/installation.py > - /etc/dasd.conf is read by dracut_setup_args() in blivet/devices/disk.py to > produce a set of kernel command line parameters (rd.dasd=...), but this is > not required when zdev udev rules are in place Zfcp dracut_setup_args() is something I haven't fully made up my mind yet. S390 devices on the CCW bus (except for e.g. virtio-block and virtio-scsi using virtio-ccw in an s390 KVM guest) intentionally do deferred probing and often need the step to set them online. Hence, a generic (non-hostonly) initramfs seems hardly possible. Dracut can internally itself resolve the device dependencies (for root-fs or kdump target), can generate a suitable cmdline [--print-cmdline; not in 95zfcp though], and can even store such cmdline inside the initramfs [--hostonly-cmdline]. That would also have the beauty that no user has to think about root-fs dependencies, when they change the dependency graph after installation by e.g. adding another LVM PV to increase the root-fs size; just call dracut and be done. [https://public.dhe.ibm.com/software/dw/linux390/lvc/zFCP_Best_Practices-BB-Webcast_201805.pdf#page=23] So why would anyone want to duplicate similar code in an installer just to pass the same cmdline from the outside of the initramfs (which can hardly be non-hostonly anyway). Let alone potential problems with oversized kernel parameter line [https://www.ibm.com/docs/en/linux-on-systems?topic=pitfalls-kernel-parameters-exceed-limit] although a larger kernel command line length should alleviate that [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.16&id=622021cd6c560ce7aaaf7294a732177a30c9d65f and corresponding user space changes]. I only remember that I implemented dracut_setup_args() for rd.zfcp based on what rd.iscsi already did in anaconda back then. Do you remember why Red Hat seems to use --hostonly-cmdline only for kdump, but not for a "regular" initramfs and instead anaconda dracut_setup_args()? > - /etc/dasd.conf must exists for the (legacy) 95dasd module to work, so we > will keep it empty My idea was to perform all early-boot (regular & kdump) s390 device config in https://github.com/ibm-s390-linux/s390-tools/tree/master/zdev/dracut/95zdev and change 95zfcp into an intermediate state(details pending) where /etc/zfcp.conf is deprecated (possibly even automatically migrated to zdev udev rules for late-boot and renamed or deleted on the root-fs). 95zfcp could eventually be removed entirely. > - for setting up the DASDs we will need to prepare the "export/import" file > and feed it into chzdev in the sysimage chroot, reuse _write_dasd_conf() I was thinking of removing all the direct sysfs handling code as well as removing all writing the old distro-specific config files and replacing it by calling chzdev directly (with an option to have the persistent output land in the appropriate sysroot as the installer's root-fs is of course not the root-fs of the system being installed). That would handle sysfs dynamic online (the "active" part of chzdev) as well as writing the desired new "persistent" config format to the future root-fs. > - zdev dracut module detects disks for rootfs from the running system, how > this will work for the installer environment?? Good point. Doesn't anaconda run dracut chrooted into sysroot like it does for writing the boot record with zipl AFAIK? Other architectures and dracut modules would have the same challenge to solve, wouldn't they? If not, maybe Peter has an idea like having chzdev operate on sysroot instead of / ? > - last step in the converion process will be removal of dasd.udev and > dasdconf.sh from s390utils and adapt device_cio_free Zdev handles cio_ignore handling. What do we still need device_cio_free for? > zFCP/SCSI - I think similar process like for DASDs can be used I have some specific ideas for zfcp in anaconda and python-blivet. Let's see if I can get to actually change code. (In reply to comment #5) > You can watch the progress of my proof-of-concept at > https://github.com/sharkcz/anaconda/commits/zdev > > It should be capable of > - converting the internal DASD storage config into a "export/import" file > that chzdev can read/process I did not expect that. It looks like we would introduce yet another new config file /etc/zdev.conf -- with the un(?)documented internal(?) export/import format of zdev -- and indirectly convert into zdev udev rules? According to my understanding, the chzdev command line and its options are the user interface to generate zdev udev rules (or to dynamically change sysfs). > Right now we use /etc/zdev.conf (only /etc exists in the time when it's > written) in the system being installed and run "chzdev" in the sysroot. > Other option is to use a local file and run "chzdev" with "--base > /etc=$sysroot/etc" option. That would have been my idea, too.
------- Comment From MAIER.com 2023-01-26 09:25 EDT------- (In reply to comment #19) > (In reply to comment #4) > > DASDs > > - /etc/dasd.conf is written by _write_dasd_conf() in > > pyanaconda/storage/installation.py > > - for setting up the DASDs we will need to prepare the "export/import" file > > and feed it into chzdev in the sysimage chroot, reuse _write_dasd_conf() > > I was thinking of removing all the direct sysfs handling code as well as > removing all writing the old distro-specific config files and replacing it > by calling chzdev directly (with an option to have the persistent output > land in the appropriate sysroot as the installer's root-fs is of course not > the root-fs of the system being installed). I missed that storage device setup happens early and thus before sysroot even exists. However, we can still use chzdev without --base to configure zfcp etc. and it writes the persistent config into the installer's ramdisk root-fs. At a suitable point in time, we can use something like "chzdev --export - ... | chzdev --import - --base ..." to migrate the persistent config into sysroot. I suppose a suitable point is after storace device setup and after sysroot was created and before calling dracut or zipl and thus before installing any packages (due to potential rpm post-install scriptlets calling dracut).
------- Comment From MAIER.com 2023-01-27 12:45 EDT------- (In reply to comment #19) > > DASDs > > - /etc/dasd.conf is written by _write_dasd_conf() in > > pyanaconda/storage/installation.py > > > - /etc/dasd.conf is read by dracut_setup_args() in blivet/devices/disk.py to > > produce a set of kernel command line parameters (rd.dasd=...), but this is > > not required when zdev udev rules are in place > > Zfcp dracut_setup_args() is something I haven't fully made up my mind yet. > S390 devices on the CCW bus (except for e.g. virtio-block and virtio-scsi > using virtio-ccw in an s390 KVM guest) intentionally do deferred probing and > often need the step to set them online. Hence, a generic (non-hostonly) > initramfs seems hardly possible. > Dracut can internally itself resolve the device dependencies (for root-fs or > kdump target), can generate a suitable cmdline [--print-cmdline; not in > 95zfcp though], and can even store such cmdline inside the initramfs > [--hostonly-cmdline]. That would also have the beauty that no user has to > think about root-fs dependencies, when they change the dependency graph > after installation by e.g. adding another LVM PV to increase the root-fs > size; just call dracut and be done. > [https://public.dhe.ibm.com/software/dw/linux390/lvc/zFCP_Best_Practices-BB- > Webcast_201805.pdf#page=23] > So why would anyone want to duplicate similar code in an installer just to > pass the same cmdline from the outside of the initramfs (which can hardly be > non-hostonly anyway). Let alone potential problems with oversized kernel > parameter line > [https://www.ibm.com/docs/en/linux-on-systems?topic=pitfalls-kernel- > parameters-exceed-limit] > although a larger kernel command line length should alleviate that > [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/ > ?h=v5.16&id=622021cd6c560ce7aaaf7294a732177a30c9d65f and corresponding user > space changes]. > I only remember that I implemented dracut_setup_args() for rd.zfcp based on > what rd.iscsi already did in anaconda back then. Do you remember why Red Hat > seems to use --hostonly-cmdline only for kdump, but not for a "regular" > initramfs and instead anaconda dracut_setup_args()? Found something in https://github.com/dracutdevs/dracut/blame/eb75861c2a1c05eb142616da1891a7fa5a2a34e1/dracut.conf.d/fedora.conf.example#L43 hostonly="yes" hostonly_cmdline="no"
This message is a reminder that Fedora Linux 36 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '36'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 36 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 36 entered end-of-life (EOL) status on 2023-05-16. Fedora Linux 36 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.
------- Comment From tstaudt.com 2023-05-30 04:35 EDT------- I think this is still a valid bug for newer release.
------- Comment From MAIER.com 2023-10-17 12:57 EDT------- For the sake of completeness: Code for "consolidated s390 device configuration" submitted upstream. It implements what was discussed below in the selectively quoted parts. https://github.com/ibm-s390-linux/s390-tools/pull/158 [draft] https://github.com/dracutdevs/dracut/pull/2534 [draft] https://github.com/storaged-project/blivet/pull/1162 [draft] https://github.com/rhinstaller/anaconda/pull/5250 [draft] https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.org/thread/SCRTNQIGC7AAUDTLQQ6I5B6GSSUG2XOS/#SCRTNQIGC7AAUDTLQQ6I5B6GSSUG2XOS https://github.com/steffen-maier/s390utils/commits/zdev (In reply to comment #19) > (In reply to comment #4) > > Currently we use plain text files (/etc/dasd.conf, /etc/zfcp.conf, network > > > DASDs > > - /etc/dasd.conf is written by _write_dasd_conf() in > > pyanaconda/storage/installation.py > > > - /etc/dasd.conf is read by dracut_setup_args() in blivet/devices/disk.py to > > produce a set of kernel command line parameters (rd.dasd=...), but this is > > not required when zdev udev rules are in place For the time being, I kept and updated the dracut_setup_args() code in my upstream submissions to keep the changes and regression risk as small as possible. > > - /etc/dasd.conf must exists for the (legacy) 95dasd module to work, so we > > will keep it empty > > My idea was to perform all early-boot (regular & kdump) s390 device config in > https://github.com/ibm-s390-linux/s390-tools/tree/master/zdev/dracut/95zdev > and change 95zfcp into an intermediate state(details pending) where > /etc/zfcp.conf is deprecated (possibly even automatically migrated to zdev > udev rules for late-boot and renamed or deleted on the root-fs). 95zfcp > could eventually be removed entirely. > > - zdev dracut module detects disks for rootfs from the running system, how > > this will work for the installer environment?? > > Good point. > Doesn't anaconda run dracut chrooted into sysroot like it does for writing > the boot record with zipl AFAIK? Other architectures and dracut modules > would have the same challenge to solve, wouldn't they? Worked for me during function tests. > > - last step in the converion process will be removal of dasd.udev and > > dasdconf.sh from s390utils and adapt device_cio_free > > Zdev handles cio_ignore handling. What do we still need device_cio_free for? > > > zFCP/SCSI - I think similar process like for DASDs can be used > > I have some specific ideas for zfcp in anaconda and python-blivet. > Let's see if I can get to actually change code. > > (In reply to comment #5) > > You can watch the progress of my proof-of-concept at > > https://github.com/sharkcz/anaconda/commits/zdev > > > > It should be capable of > > - converting the internal DASD storage config into a "export/import" file > > that chzdev can read/process > > I did not expect that. It looks like we would introduce yet another new > config file /etc/zdev.conf -- with the un(?)documented internal(?) > export/import format of zdev -- and indirectly convert into zdev udev rules? > According to my understanding, the chzdev command line and its options are > the user interface to generate zdev udev rules (or to dynamically change > sysfs). > > > Right now we use /etc/zdev.conf (only /etc exists in the time when it's > > written) in the system being installed and run "chzdev" in the sysroot. > > Other option is to use a local file and run "chzdev" with "--base > > /etc=$sysroot/etc" option. > > That would have been my idea, too. (In reply to comment #21) > (In reply to comment #19) > > (In reply to comment #4) > > > DASDs > > > - /etc/dasd.conf is written by _write_dasd_conf() in > > > pyanaconda/storage/installation.py > > > > - for setting up the DASDs we will need to prepare the "export/import" file > > > and feed it into chzdev in the sysimage chroot, reuse _write_dasd_conf() > > > > I was thinking of removing all the direct sysfs handling code as well as > > removing all writing the old distro-specific config files and replacing it > > by calling chzdev directly (with an option to have the persistent output > > land in the appropriate sysroot as the installer's root-fs is of course not > > the root-fs of the system being installed). > > I missed that storage device setup happens early and thus before sysroot > even exists. However, we can still use chzdev without --base to configure > zfcp etc. and it writes the persistent config into the installer's ramdisk > root-fs. At a suitable point in time, we can use something like > "chzdev --export - ... | chzdev --import - --base ..." > to migrate the persistent config into sysroot. > > I suppose a suitable point is after storace device setup and after sysroot > was created and before calling dracut or zipl and thus before installing any > packages (due to potential rpm post-install scriptlets calling dracut).
------- Comment From MAIER.com 2023-10-18 08:55 EDT------- > https://github.com/steffen-maier/s390utils/commits/zdev just FYI, I had the idea of opening a pseudo pull request for that branch in order to provide an opportunity for patch review in github: https://github.com/steffen-maier/s390utils/pull/1
FEDORA-2024-e22ef7a242 (anaconda-42.8-1.fc42 and python-blivet-3.11.0-4.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2024-e22ef7a242
FEDORA-2024-e22ef7a242 (anaconda-42.9-1.fc42 and python-blivet-3.11.0-4.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.