Comment 7 for bug 1892367

------- Comment From <email address hidden> 2020-10-26 07:55 EDT-------
Addl Information for a possible solution.

zdev provides an option to specify that a specific device should be configured as part of the initial ram disk configuration steps:

zdev: Implement support for early device configuration
Enable user to specify that a device should be configured early, that is
during the initial RAM-disk boot phase. This may be necessary, e.g. to
override auto-configuration for a device which is also applied during
that boot phase. It may also be used to manually specify devices that
are required to access the root file system, such as networking devices.
Users can mark devices as requiring early configuration by specifying
a value of 1 for the newly added internal attribute zdev:early:
# chzdev dasd-eckd 0.0.1234 -p zdev:early=1
This can be changed back by removing the attribute setting, or by
setting the attribute value to 0:
# chzdev dasd-eckd 0.0.1234 -p -r zdev:early
or

# chzdev dasd-eckd 0.0.1234 -p zdev:early=0

This support was added with s390-tools v2.4.0. It can be used to work around the issue described in this bugzilla.

At the core of this problem lies the fact that unlike other linux vendors, Canonical decided to always want to copy all udev rules to the initial RAM-disk. As this is different between distributions, we cannot just change zdev to always update the RAM-disk as this would potentially introduce problems with other linux vendor distributions.

A potential solution could be done easily by providing a build-time switch that allows Canonical to specify that whenever a persistent device configuration changed, the RAM-disk is updated (this could be implemented via a modified root_check() function in s390-tools/zdev/root.c that only returns if a persistent device configuration was changed).

Could that be a potenital solution? Please provide your feedback. Many thanks in advance