ubuntu-translations-coordinators team mailing list archive

[Launchpad Bug Tracker <1892367@xxxxxxxxxxxxxxxxxx>]

You have been subscribed to a public bug:

SRU:
====

[Impact]

 * In case a ccw (special s390x hardware) device is configured
   in a special (non-default) way using chzdev
   (like for example increasing the qeth buffer_count to 128),
   the modifications are not persistent by default, since the
   generated udev rules are not automatically incuded/added to the initramfs.

 * One needs to either manually re-create the initramfs,
   e.g. with 'sudo update-initramfs -k all -u' (maybe triggered by zipl)

 * or pass the arguments '-p -r zdev:early' to chzdev.

 * This is not really intuitive and what people expect
   and partly leads to confusion.

 * The solution is to compile with the ZDEV_ALWAYS_UPDATE_INITRD=1 option set.
   This makes sure that executions of chzdev always trigger 'update-initramfs -u'.

[Test Plan]

 * Prepare an Ubuntu Server 20.04 or 20.04 on IBM Z with at least
   one ccw device, for example a qeth network device, here '0.0.1234'.
   (better to do that with a second spare qeth device,
    other than the one that is in use by your remote connection).

 * Configure the device using:
   sudo chzdev qeth -e 1234

 * Check the (default) value of a certain attribute, like qeth buffer_count:
   cat /sys/devices/qeth/0.0.1234/buffer_count
   64

 * Disable the ccw device again:
   sudo chzdev qeth -d 1234
   
 * And enable (re-)enable it with an increased buffer_count:
   sudo chzdev -e 1234 buffer_count=128

 * Check the (increased) value of the qeth buffer_count:
   cat /sys/devices/qeth/0.0.1234/buffer_count
   128

 * Restart the system (without manually running update-initramfs or zipl):
   sudo shutdown -r now

 * Once the system is up again, re-check if the ccw device was enabled again
   and if it still has the increased buffer_count value:
   lszdev qeth 1234
   TYPE  ID                          ON   PERS  NAMES
   qeth  0.0.1234:0.0.1235:0.0.1236  yes  yes   enc1234
   cat /sys/devices/qeth/0.0.1234/buffer_count
   128
   (alternatively check with: lsqeth enc1234 | grep buffer_count)

[Where problems could occur]

 * The logic of handling DZDEV_ALWAYS_UPDATE_INITRD could be wrong, e.g. inversed.
   Then the initramfs is re-build even if not desired
   and in case needed not done, hence similar result than before.

 * The setting of 'ZDEV_ALWAYS_UPDATE_INITRD=1' could have been missed,
   which would lead to the similar behaviour than w/o the patch.

 * 'add_pers_removed' could handle wrong device types or not all devices,
   in case of potential array index errors.

 * 'is_zdev_early_0' could identify wrong persistent devices as some to be
   included early in the boot process (means added to the initramfs).

 * Problems in 'if (all_pers)' could lead to a wrong set of persistent devices
   that are considered (or not all),
   which could lead to unexpected (de-)configurations.

 * Finally the handling of the confirmation
   or the 'build of the command line' could be errornous,
   since the encapsulated if condition(s) changed (sightly).

[Other Info]

 * This patch became upstream accepted with s390-tools 2.16.0 and is
   with that already included in hirsute, based on LP:1914574.

__________

During the ubuntu installation in tessia, we do chzdev for both dasd and
qeth devices, as below.

2020-08-20 09:54:45 | INFO | START subiquity/Early/run/command_1 : chzdev -e dasd 385c
2020-08-20 09:54:45 | INFO | SUCCESS subiquity/Early/run/command_1 : chzdev -e dasd 385c
2020-08-20 09:54:45 | INFO | START subiquity/Early/run/command_2 : chzdev -e qeth 0.0.bdf0
2020-08-20 09:54:47 | INFO | SUCCESS subiquity/Early/run/command_2 : chzdev -e qeth 0.0.bdf0

and we can see the below files in the /etc/udev/rules.d/
oot@m8360024:~# ls -l /etc/udev/rules.d/
total 76
-rw-r--r-- 1 root root   154 Aug 20 09:08 41-cio-ignore.rules
-rw-r--r-- 1 root root   430 Aug 20 09:08 41-dasd-eckd-0.0.385c.rules
-rw-r--r-- 1 root root   357 Aug 20 09:08 41-generic-ccw-0.0.0009.rules
-rw-r--r-- 1 root root  1049 Aug 20 09:08 41-qeth-0.0.bdf0.rules
-rw-r--r-- 1 root root 58549 Aug 20 09:10 70-snap.snapd.rules

Now, lsinitramfs shows files as below,

root@m8360024:~# lsinitramfs /boot/initrd.img-5.4.0-42-generic | grep 41
etc/udev/rules.d/41-cio-ignore-root.rules
etc/udev/rules.d/41-dasd-eckd-0.0.385c.rules
usr/lib/udev/rules.d/41-cio-ignore.rules
usr/lib/udev/rules.d/41-dasd-eckd-0.0.385c.rules
usr/lib/udev/rules.d/41-generic-ccw-0.0.0009.rules
usr/lib/udev/rules.d/41-qeth-0.0.bdf0.rules

Even though lsinitramfs shows the below files, they are overruled by the
filesystem files.

Next thing we did was to modify the 41-qeth-0.0.bdf0.rules and modified
the buffer_count to 128 (As in the attached file). In ideal scenario,
the value should we modified as mentioned in the bug. But, in our case,
if we are not doing a zipl or update-initramfs -u, the value is not
getting modified.

** Affects: ubuntu-translations
     Importance: Undecided
     Assignee: Skipper Bug Screeners (skipper-screen-team)
         Status: Invalid

** Affects: ubuntu-z-systems
     Importance: Medium
     Assignee: Skipper Bug Screeners (skipper-screen-team)
         Status: Fix Committed

** Affects: s390-tools (Ubuntu)
     Importance: Medium
     Assignee: Canonical Foundations Team (canonical-foundations)
         Status: Fix Released

** Affects: s390-tools (Ubuntu Focal)
     Importance: Medium
     Assignee: Brian Murray (brian-murray)
         Status: Fix Committed

** Affects: s390-tools (Ubuntu Groovy)
     Importance: Medium
     Assignee: Brian Murray (brian-murray)
         Status: Fix Committed

** Affects: s390-tools (Ubuntu Hirsute)
     Importance: Medium
     Assignee: Canonical Foundations Team (canonical-foundations)
         Status: Fix Released


** Tags: architecture-s39064 bugnameltc-187578 fr-588 id-5f3edb43483dbd71389ae8c1 severity-medium targetmilestone-inin2004 verification-needed verification-needed-focal verification-needed-groovy
-- 
[UBUNTU 20.04] udev rule change did not get applied
https://bugs.launchpad.net/bugs/1892367
You received this bug notification because you are a member of Ubuntu Translations Coordinators, which is subscribed to Ubuntu Translations.