Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1802482 - move the installer use zdev for configuring persistent devices
Summary: move the installer use zdev for configuring persistent devices
Keywords:
Status: ASSIGNED
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 33
Hardware: s390x
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Dan Horák
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: ZedoraTracker
TreeView+ depends on / blocked
 
Reported: 2020-02-13 09:45 UTC by Dan Horák
Modified: 2021-06-18 07:19 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github ibm-s390-tools s390-tools issues 80 0 None closed chzdev and --by-path doesn't work with LVM 2020-12-02 15:10:14 UTC
IBM Linux Technology Center 183862 0 None None None 2020-02-13 13:15:54 UTC

Description Dan Horák 2020-02-13 09:45:49 UTC 
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
Comment 1 Dan Horák 2020-02-13 09:59:11 UTC 
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
Comment 2 Dan Horák 2020-02-13 10:00:23 UTC 
zFCP/SCSI - I think similar process like for DASDs can be used
Comment 3 Dan Horák 2020-02-18 09:18:03 UTC 
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.
Comment 4 Dan Horák 2020-02-20 12:42:42 UTC 
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
Comment 5 Ben Cotton 2020-08-11 15:26:32 UTC 
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle.
Changing version to 33.
Note You need to log in before you can comment on or make changes to this bug.