[UBUNTU 20.04] chzdev -e is rebuilding initramfs even with zdev:early=0 set
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
Ubuntu on IBM z Systems |
Fix Released
|
Medium
|
Unassigned | |||
s390-tools (Ubuntu) | Status tracked in Oracular | |||||
Oracular |
Fix Released
|
Medium
|
Skipper Bug Screeners | |||
systemd (Ubuntu) | Status tracked in Oracular | |||||
Oracular |
Fix Released
|
Medium
|
Simon Chopin |
Bug Description
Versions:
Ubuntu 20.04.5 s390-tools version 2.12.0-
Ubuntu 22.04.2 s390-tools version 2.20.0-
When I configure a zfcp LUN persistently via chzdev, the initrd is being rebuilt even with parameter zdev:early=0
root@a8315003:~# chzdev -e zfcp-lun 0.0.1803:
zFCP LUN 0.0.1803:
Note: The initial RAM-disk must be updated for these changes to take effect:
- zFCP LUN 0.0.1803:
update-initramfs: Generating /boot/initrd.
I: The initramfs will attempt to resume from /dev/dasdb1
I: (UUID=e70ecb80-
I: Set the RESUME variable to override this.
Using config file '/etc/zipl.conf'
Building bootmap in '/boot'
Adding IPL section 'ubuntu' (default)
Preparing boot device: dasda (c00a).
Done.
root@a8315003:~#
== Comment: - Thorsten Diehl <email address hidden> - 2023-03-01 06:55:47 ==
@BOE-dev
This behaviour is unexpected.
https:/
Activating a device early during the boot process
Use the zdev:early device attribute to activate a device early during the boot process and to override any existing auto-configuration with a persistent device configuration.
zdev:early=1
The device is activated during the initial RAM disc phase according to the persistent configuration.
zdev:early=0
The device is activated as usual during the boot process. This is the default. If auto-configuration data is present, the device is activated during the initial RAM disc phase according to the auto-configuration.
I can't interprete a SCSI LUN as a device with auto configuration data. (At least, if the zfcp device hasn't NPIV enabled)
== Comment: #5 - Peter Oberparleiter <email address hidden> - 2023-03-01 11:18:28 ==
(In reply to comment #2)
> @BOE-dev
> This behaviour is unexpected.
> https:/
> Activating a device early during the boot process
>
> Use the zdev:early device attribute to activate a device early during the
> boot process and to override any existing auto-configuration with a
> persistent device configuration.
>
> zdev:early=1
> The device is activated during the initial RAM disc phase according to
> the persistent configuration.
>
> zdev:early=0
> The device is activated as usual during the boot process. This is the
> default. If auto-configuration data is present, the device is activated
> during the initial RAM disc phase according to the auto-configuration.
The documentation is incorrect for Ubuntu. Canonical specifically builds zdev in a way that every change to persistent device configuration causes an update to the initial RAM-disk. See also:
https:/
https:/
> I can't interprete a SCSI LUN as a device with auto configuration data. (At
> least, if the zfcp device hasn't NPIV enabled)
This is related to auto-configuration as implemented for DPM.
== Comment: #6 - Thorsten Diehl <email address hidden> - 2023-03-03 12:41:44 ==
So, IIUC, chzdev is built for Ubuntu with ZDEV_ALWAYS_
If you confirm, you may also close this bug.
Not nice - then we have to find an alternate solution.
== Comment: #7 - Peter Oberparleiter <email address hidden> - 2023-03-07 06:48:07 ==
(In reply to comment #6)
> So, IIUC, chzdev is built for Ubuntu with ZDEV_ALWAYS_
> make the parameter zdev:early=0 ineffective. Correct?
> If you confirm, you may also close this bug.
>
> Not nice - then we have to find an alternate solution.
chzdev -p on Ubuntu will by default rebuild the initrd. This is intended
behavior by Canonical and controlled by the ZDEV_ALWAYS_
switch. You can suppress it by adding option --no-root-update to the command
line.
Specifying zdev:early=0 to chzdev has exactly the effect that it is supposed to
have: it tells zdev not to enable that device during initrd processing,
resulting in the corresponding udev rule not being copied to the initrd [1].
Unfortunately there is another Ubuntu-initrd script [2] that simply copies ALL
udev rules, including those created by zdev, into the initrd. As a result,
zdev's early-attribute handling is rendered useless and all devices are enabled,
even if a user specified zdev:early=0.
Since this bug report indicates that there is a use-case for this function in
Ubuntu, it might be worth asking Canonical if current processing could be
changed to provide a way for users to specify that a device should specifically
NOT be enabled within initrd processing.
Technically this could easily be done:
1) Have the generic udev initramfs script not copy zdev-generated Udev rules,
OR
have the zdev initramfs script remove those rules (somewhat of a hack)
2) Change the zdev initramfs script logic from the current:
- enable devices required for the root file system, AND
- enable devices for which zdev:early=1 was specified
to
- enable all persistently configured devices EXCEPT those for which
zdev:early=0 was specified
This change would be needed to maintain Canonical's policy of enabling
all devices in the initrd by default
I'm open to adding the change in 2) to our s390-tools package, but someone at
Canonical would need to work out a way to implement 1).
[1] https:/
[2] https:/
tags: | added: architecture-s39064 bugnameltc-201777 severity-medium targetmilestone-inin--- |
Changed in ubuntu: | |
assignee: | nobody → Skipper Bug Screeners (skipper-screen-team) |
affects: | ubuntu → linux (Ubuntu) |
affects: | linux (Ubuntu) → s390-tools (Ubuntu) |
Changed in s390-tools (Ubuntu): | |
importance: | Undecided → Medium |
Changed in initramfs-tools (Ubuntu): | |
importance: | Undecided → Medium |
Changed in ubuntu-z-systems: | |
importance: | Undecided → Medium |
tags: |
added: foundations-todo removed: rls-ff-incoming rls-jj-incoming |
Changed in systemd (Ubuntu): | |
assignee: | nobody → Simon Chopin (schopin) |
Changed in systemd (Ubuntu Oracular): | |
status: | New → In Progress |
Changed in ubuntu-z-systems: | |
status: | New → Fix Released |
This was implemented around 2020, mainly to catch any ccw config changes in a user friendly way: /bugs.launchpad .net/bugs/ 1892367 /i527439087. restricted. launchpadlibrar ian.net/ 527439087/ 20f6c87a- 829f-11eb- 9412-002481e91f 22.txt? token=zC4n7TlCm ffBDHm9Dl002Psf chDXC3Dk
https:/
https:/
Regarding:
"1) Have the generic udev initramfs script not copy zdev-generated Udev rules,"
we need to be super careful here to not break stuff ...
How to best identify the zdev-generated Udev rules,
since these are not all the rules generated by chzdev (indicated by first line in rule), are they?
I'm not very sure if initramfs(-tools) maintainer(s) are very happy ...