** Changed in: s390-tools (Ubuntu Focal) Importance: Undecided => Medium
** Changed in: s390-tools (Ubuntu Hirsute) Importance: Undecided => Medium ** Changed in: s390-tools (Ubuntu Groovy) Importance: Undecided => Medium ** Project changed: subiquity => ubuntu-translations ** No longer affects: ubuntu-translations -- You received this bug notification because you are a member of Ubuntu Translations Coordinators, which is subscribed to Ubuntu Translations. Matching subscriptions: Ubuntu Translations bug mail https://bugs.launchpad.net/bugs/1892367 Title: [UBUNTU 20.04] udev rule change did not get applied Status in Ubuntu on IBM z Systems: Fix Committed Status in s390-tools package in Ubuntu: Fix Released Status in s390-tools source package in Focal: Fix Committed Status in s390-tools source package in Groovy: Fix Committed Status in s390-tools source package in Hirsute: Fix Released Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1892367/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~ubuntu-translations-coordinators Post to : ubuntu-translations-coordinators@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-translations-coordinators More help : https://help.launchpad.net/ListHelp
