[UBUNTU 20.04] udev rule change did not get applied

[bugproxy]

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.

[bugproxy (bugproxy)]

Default Comment by Bridge

[Andrew Cloke (andrew-cloke)]

Triaged to the subiquity project, as this issue appears to be related to a subiquity 20.04 installation. Please feel free to reclassify if that's inappropriate.

[Dimitri John Ledkov (xnox)]

> But, in our case, if we are not doing a zipl or update-initramfs -u, the value is not getting modified.

Ubuntu initramfs copies all udev rules that are present in /etc/udev/rules.d into the initramfs. It cannot possibly know which ones are hand-edited, which ones are generated by zdev, and which ones must be in the initramfs or not. For example, we do support bringing up networking interactively inside the initrd, thus even the qeth ones are useful in the initrd.

Separately, we do ship zdev & initramfs integration hook (/lib/s390-tools/zdev-root-update) and thus zdev itself knows how to update the initramfs.

We have discussed this before that `chzdev` persistent enable|disable commands should always invoke zdev-root-update, but that has not been implemented upstream. I too find it confusing that chzdev enable|disable doesn't call zdev-root-update hook (which in turn calls update-initramfs -u to update udev rules in the initrd).

Please open issue against upstream chzdev https://github.com/ibm-s390-tools/s390-tools to call zdev-root-update hook upon any persistent changes to zdev devices.

[Heinz-Werner Seeck (heinz-werner-seeck)]

Test comment: Mirror was not initiated till today.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2020-09-01 10:18 EDT-------
> Ubuntu initramfs copies all udev rules that are present in /etc/udev/rules.d
> into the initramfs. It cannot possibly know which ones are hand-edited,
> which ones are generated by zdev, and which ones must be in the initramfs or
> not. For example, we do support bringing up networking interactively inside
> the initrd, thus even the qeth ones are useful in the initrd.
>

Basically, this means the custom 'hand-edited' value in the /etc/udev/rules.d/41-qeth-0.0.e200.rules should be executed and should over-rule the value of "buffer_count" attribute, which was set from /usr/lib/udev/rules.d/41*.

But, what we see is, this is not happening. The buffer_count attribute value was always the one which is part of initramfs.

[Frank Heimes (fheimes)]

Currently discussed IBM internally - hence setting project entry to Incomplete ...

[bugproxy (bugproxy)]

------- 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

[Frank Heimes (fheimes)]

Using the 'zdev:early' device attribute (and setting it to '1') could be indeed an alternative (at least for the most cases), since with this set one is automatically asked if the initramfs should be rebuild - and in combination with '--yes' this question is automatically confirmed.

I've added here a 2nd disk 0400 and lsinitramfs shows that it's not only listed under
'usr/lib/udev/rules.d', but also under 'etc/udev/rules.d'.

$ sudo chzdev dasd-eckd 0.0.0400 -p zdev:early=1 --yes
Configuring devices in the persistent configuration only
ECKD DASD 0.0.0400 configured
Note: The initial RAM-disk must be updated for these changes to take effect:
       - ECKD DASD 0.0.0400
update-initramfs: Generating /boot/initrd.img-5.4.0-52-generic
Using config file '/etc/zipl.conf'
Building bootmap in '/boot'
Adding IPL section 'ubuntu' (default)
Preparing boot device: dasda (0200).
Done.

$ lsinitramfs /boot/initrd.img-5.4.0-52-generic | grep 41
etc/udev/rules.d/41-cio-ignore-root.rules
etc/udev/rules.d/41-dasd-eckd-0.0.0200.rules
etc/udev/rules.d/41-dasd-eckd-0.0.0400.rules <==
usr/lib/udev/rules.d/41-cio-ignore.rules
usr/lib/udev/rules.d/41-dasd-eckd-0.0.0200.rules
usr/lib/udev/rules.d/41-dasd-eckd-0.0.0400.rules <==
usr/lib/udev/rules.d/41-generic-ccw-0.0.0009.rules
usr/lib/udev/rules.d/41-qeth-0.0.0600.rules

However, like Dimitri already pointed out in comment #3, if someone manually modifies udev rules, a manual mkinitramfs is needed, too.

However (moving from the above DASD example to a qeth example) if you specify any further attributes, that you want to get activated, immediately with the chzdev command (like in your case 'buffer_count=128' and probably layer2=1), this will then land in the initramfs as well - and in case 'zdev:early=1' was specified, it will even land in a rule under 'etc/udev/rules.d', too. See:

$ sudo chzdev qeth 0603 -p zdev:early=1 layer2=1 buffer_count=128 --yes
Configuring devices in the persistent configuration only
QETH device 0.0.0603:0.0.0604:0.0.0605 configured
Note: The initial RAM-disk must be updated for these changes to take effect:
       - QETH device 0.0.0603:0.0.0604:0.0.0605
update-initramfs: Generating /boot/initrd.img-5.4.0-52-generic
Using config file '/etc/zipl.conf'
Building bootmap in '/boot'
Adding IPL section 'ubuntu' (default)
Preparing boot device: dasda (0200).
Done.
$ cat /etc/udev/rules.d/41-qeth-0.0.0603.rules | egrep '(layer2|buffer_count)'
ATTR{[ccwgroup/0.0.0603]layer2}="1"
ATTR{[ccwgroup/0.0.0603]buffer_count}="128"
$ lsinitramfs -l /boot/initrd.img-5.4.0-52-generic | grep 41-qeth-0.0.0603.rules
-rw-r--r-- 1 root root 1023 Oct 27 09:07 etc/udev/rules.d/41-qeth-0.0.0603.rules
-rw-r--r-- 1 root root 1023 Oct 27 09:07 usr/lib/udev/rules.d/41-qeth-0.0.0603.rules

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2020-11-10 10:24 EDT-------
The zdev:early parameter in the chzdev command is a work-around for this issue.

The Actual issue is,the fact that unlike SUSE or Red Hat, Canonical 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 SUSE and Red Hat distributions.

As discussed internally with the team, what could be done is, to provide a build-time switch, a MACRO 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).
The functionality mentioned above is same as having "zdev:early=1" on this usecase. But, we would like to avoid this extra parameter and make it work like other distros.

We would like to get a go from Canonical on this.

[Dimitri John Ledkov (xnox)]

Hi Vineeth,

that is correct that Debian/Ubuntu always copy all the udev rules from host, to the initramfs by default. And for us, stopping to do that will cause change of behavior which may trigger bug. Same as it would on RHEL/SUSE side if those would start doing this.

If I understand you correctly, an Ubuntu-only change to internal_attr_early to have .defval="1" is the sort of thing you are proposing right? Which should lead to any persistent commands that affect udev rules to trigger initramfs rebuild?

https://github.com/ibm-s390-tools/s390-tools/blob/58ecf1f363c35f452f5d00697620e520029bef83/zdev/src/internal.c#L23

That should fix the originally reported UX issue.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2020-12-10 08:39 EDT-------
Unfortunately .defval="1" functionality doesnt work for this case.
Instead, what we do is, we modify the root_check() function in root.c,such a way that, the required functionality of zdev:early=1 is enabled by default, based on a MACRO.

The new MACRO will be build-time configurable, which will then be used by Canonical while building the chzdev.

The patch is being developed and will push to s390-tools upstream once it is ready. Which can then be used by Canonical. So, we dont need a Canonical-only change in the code; But the change is only the MACRO-definition passed during the build-time.

[Dimitri John Ledkov (xnox)]

Sounds good! Looking forward to that patch. And then we will most likely try to pick it up for stable release updates too. Cause yes, this behaviour needs to be fixed properly.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2021-01-20 09:02 EDT-------
Upstream patch will be pushed soon to the next upcoming s390-tools...
-> in progresss

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2021-01-25 07:44 EDT-------
The patch mentioned in comment#39 is available in the s390-tools upstream now.

https://github.com/ibm-s390-tools/s390-tools/commit/7dd03eaeecdd0e2674f145aca34be1275d291bd8

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2021-02-01 09:15 EDT-------
@Can, when can we expect the integration of the fix ?

[Frank Heimes (fheimes)]

The idea is to pick this up once 2.16 is out (LP#1892367), since with 2.16 the udev topic is solved for hirsute, hence just the SRU to G and F is remaining.

[Launchpad Janitor (janitor)]

This bug was fixed in the package s390-tools - 2.16.0-0ubuntu1

---------------
s390-tools (2.16.0-0ubuntu1) hirsute; urgency=medium

  * New upstream release. LP: #1914574
  * Drop patches applied upstream.
  * Compile with ZDEV_ALWAYS_UPDATE_INITRD=1 option. This fixes calls to
    chzdev to trigger update-initramfs -u. LP: #1892367
  * Set install path via make variables, instead of patching source
    Makefiles.
  * Update homepage to github.com.

s390-tools (2.15.1-1ubuntu3) hirsute; urgency=medium

  * No-change rebuild to drop the udeb package.

s390-tools (2.15.1-1ubuntu2) hirsute; urgency=medium

  * No change rebuild with fixed ownership.

s390-tools (2.15.1-1ubuntu1) hirsute; urgency=low

  * Update debian/watch for new ibm-s390-linux repo
  * Update debian/control for [XC-]Package-Type
  * Merge from Debian unstable. Remaining changes:
    - keep providing zkey
    - split some tools into individuall packages
    - Drop udevadm-path.patch
    - Drop ziomon package
    - Linux on z Systems naming
    - 0001-ziomon-Use-exit-code-0-for-version-and-help.patch
    - 0001-zkey-add-initramfs-hook.patch
    - 0001-zkey-on-Ubuntu-use-default-benchmarked-Argon2i-with-.patch
    - 0001-dumpconf-Don-t-run-the-service-in-LXC.patch
    - update-install-paths.patch
    - 0010-no-pie-is-not-a-valid-option-for-ld.patch
    - s390-tools-lp1903984-hirsute.patch

s390-tools (2.15.1-2) unstable; urgency=medium

  * Remove myself as a maintainer.

s390-tools (2.15.1-1) unstable; urgency=medium

  * New upstream release
    - Install new tool lsstp.
    - Continue to skip out on zkey for now.

 -- Dimitri John Ledkov <email address hidden> Wed, 24 Feb 2021 05:49:54 +0000

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2021-03-03 03:55 EDT-------
Tested the latest ubuntu21.04

root@m35lp41:~# cat /proc/version
Linux version 5.10.0-14-generic (buildd@bos02-s390x-005) (gcc (Ubuntu 10.2.1-6ubuntu2) 10.2.1 20210121, GNU ld (GNU Binutils for Ubuntu) 2.36) #15-Ubuntu SMP Fri Jan 29 15:04:37 UTC 2021
root@m35lp41:~# ls /sys/devices/qeth/0.0.bd00/buffer_count
/sys/devices/qeth/0.0.bd00/buffer_count
root@m35lp41:~# cat /sys/devices/qeth/0.0.bd00/buffer_count
64
root@m35lp41:~# chzdev qeth bd00 -p layer2=1 buffer_count=128
Configuring devices in the persistent configuration only
QETH device 0.0.bd00:0.0.bd01:0.0.bd02 configured
Note: The initial RAM-disk must be updated for these changes to take effect:
- QETH device 0.0.bd00:0.0.bd01:0.0.bd02
update-initramfs: Generating /boot/initrd.img-5.10.0-14-generic

Using config file '/etc/zipl.conf'
Building bootmap in '/boot'
Adding IPL section 'ubuntu' (default)
Preparing boot device: dasda (af8a).
Done.
root@m35lp41:~#
root@m35lp41:~# cat /sys/devices/qeth/0.0.bd00/buffer_count
64
root@m35lp41:~# reboot
packet_write_wait: Connection to UNKNOWN port 65535: Broken pipe
[vineeth.vijayan@oc6887364776 ~]$ ssh m35lp41.lnxne.boe
<email address hidden>'s password:
Welcome to Ubuntu Hirsute Hippo (development branch) (GNU/Linux 5.10.0-14-generic s390x)

* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage

System information as of Wed Mar 3 08:23:18 AM UTC 2021

System load: 0.16 Memory usage: 2% Processes: 204
Usage of /: 7.5% of 20.18GB Swap usage: 0% Users logged in: 0

=> There were exceptions while processing one or more plugins. See
/var/log/landscape/sysinfo.log for more information.

22 updates can be installed immediately.
0 of these updates are security updates.
To see these additional updates run: apt list --upgradable

Last login: Wed Mar 3 08:14:55 2021 from 172.18.0.1
root@m35lp41:~#
root@m35lp41:~# cat /sys/devices/qeth/0.0.bd00/buffer_count
128

Looks good to me.

[Frank Heimes (fheimes)]

Test builds for groovy and focal are available from here:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1892367/+packages

[bugproxy (bugproxy)]

Default Comment by Bridge

[Brian Murray (brian-murray)]

I've sponsored this for Focal and Groovy - thanks!

[Łukasz Zemczak (sil2100)]

Hello bugproxy, or anyone else affected,

Accepted s390-tools into groovy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/s390-tools/2.14.0-1ubuntu1.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-groovy to verification-done-groovy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-groovy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Łukasz Zemczak (sil2100)]

Hello bugproxy, or anyone else affected,

Accepted s390-tools into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/s390-tools/2.12.0-0ubuntu3.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2021-03-29 08:04 EDT-------
Looks like an updated version of "s390-tools-signed" with the same version number than the normal s390-tools is needed for verification.

# sudo apt-get install s390-tools/focal-proposed
Reading package lists... Done
Building dependency tree
Reading state information... Done
Selected version '2.12.0-0ubuntu3.3' (Ubuntu:20.04/focal-proposed [s390x]) for 's390-tools'
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
s390-tools : Depends: s390-tools-signed (= 2.12.0-0ubuntu3.3) but 2.12.0-0ubuntu3.2 is to be installed
E: Unable to correct problems, you have held broken packages.

[Frank Heimes (fheimes)]

So this is fixed now (thx to Brian).
 s390-tools | 2.12.0-0ubuntu3.3 | focal-proposed | s390x
 s390-tools-signed | 2.12.0-0ubuntu3.3 | focal-proposed | s390x
respectively
 s390-tools | 2.14.0-1ubuntu1.2 | groovy-proposed | s390x
 s390-tools-signed | 2.14.0-1ubuntu1.2 | groovy-proposed | s390x

After activating proposed:
sudo add-apt-repository "deb http://us.ports.ubuntu.com/ubuntu-ports/ $(lsb_release -sc)-proposed main"
sudo apt update
s390-tools installs fine (and pulls in s390-tools-signed):
sudo apt install s390-tools
as one can check with:
dpkg -l | grep s390-tools
Wold yu please give it another try for verification?

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2021-03-31 02:13 EDT-------
Tested on focal.
---------------

dpkg -l | grep s390-tools
ii s390-tools 2.12.0-0ubuntu3.3 s390x fundamental utilities for Linux on z Systems
ii s390-tools-signed 2.12.0-0ubuntu3.3 s390x Signed zipl stage3.bin
root@m35lp41:~#
root@m35lp41:~#
root@m35lp41:~# cat /proc/version
Linux version 5.4.0-70-generic (buildd@bos02-s390x-010) (gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)) #78-Ubuntu SMP Fri Mar 19 13:25:37 UTC 2021
root@m35lp41:~# cat /sys/devices/qeth/0.0.bd00/buffer_count
64
root@m35lp41:~# chzdev qeth bd00 -p layer2=1 buffer_count=128
Configuring devices in the persistent configuration only
QETH device 0.0.bd00:0.0.bd01:0.0.bd02 configured
Note: The initial RAM-disk must be updated for these changes to take effect:
- QETH device 0.0.bd00:0.0.bd01:0.0.bd02
update-initramfs: Generating /boot/initrd.img-5.4.0-70-generic
Using config file '/etc/zipl.conf'
Building bootmap in '/boot'
Adding IPL section 'ubuntu' (default)
Preparing boot device: dasda (af8a).
Done.
root@m35lp41:~# cat /sys/devices/qeth/0.0.bd00/buffer_count
64
root@m35lp41:~# reboot
----
Welcome to Ubuntu 20.04.2 LTS (GNU/Linux 5.4.0-70-generic s390x)

* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage

System information as of Wed 31 Mar 2021 06:12:05 AM UTC

System load: 0.38 Processes: 212
Usage of /: 6.7% of 20.18GB Users logged in: 0
Memory usage: 2% IPv4 address for encbd00: 172.18.60.41
Swap usage: 0%

0 updates can be installed immediately.
0 of these updates are security updates.

**************************************************************
* *
* The system was installed using *
* TESSIA *
* Task Execution Supporter and System Installation Assistant *
* *
* Open source repo: https://gitlab.com/tessia-project *
* (GitHub mirror: https://github.com/tessia-project) *
* *
* Documentation is located here: *
* https://gitlab.com/tessia-project/tessia/-/tree/master/doc *
* *
* To create custom templates for auto installation see: *
* > tess autotemplate add --help *
* *
**************************************************************

Last login: Wed Mar 31 06:07:43 2021 from 172.18.0.1
root@m35lp41:~#
root@m35lp41:~#
root@m35lp41:~# cat /sys/devices/qeth/0.0.bd00/buffer_count
128
---

And looks good.
Thank you for the fix.

------- Comment From <email address hidden> 2021-03-31 02:44 EDT-------
Tested on Groovy
----------------

root@m35lp41:~# dpkg -l | grep s390-tools
ii s390-tools 2.14.0...

[Frank Heimes (fheimes)]

Thank you Vineeth for the verification (and sorry for the hick-up with the s390-tools-signed package) - I'm updating the tags accordingly ...

[Launchpad Janitor (janitor)]

This bug was fixed in the package s390-tools - 2.14.0-1ubuntu1.2

---------------
s390-tools (2.14.0-1ubuntu1.2) groovy; urgency=medium

  * debian/patches/0001-zdev-Add-build-option-to-update-initial-RAM-disk-by-default.patch
    Compile with ZDEV_ALWAYS_UPDATE_INITRD=1 option.
    This fixes calls to chzdev to trigger update-initramfs -u.
    Thanks to Vineeth Vijayan (LP: #1892367)

 -- Frank Heimes <email address hidden> Fri, 12 Mar 2021 10:21:37 +0100

[Brian Murray (brian-murray)]

The verification of the Stable Release Update for s390-tools has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Launchpad Janitor (janitor)]

This bug was fixed in the package s390-tools - 2.12.0-0ubuntu3.3

---------------
s390-tools (2.12.0-0ubuntu3.3) focal; urgency=medium

  * debian/patches/0001-zdev-Add-build-option-to-update-initial-RAM-disk-by-default.patch
    Compile with ZDEV_ALWAYS_UPDATE_INITRD=1 option.
    This fixes calls to chzdev to trigger update-initramfs -u.
    Thanks to Vineeth Vijayan (LP: #1892367)

 -- Frank Heimes <email address hidden> Thu, 11 Mar 2021 18:13:30 +0100

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2021-04-07 02:05 EDT-------
IBM Bugzilla status->closed, Fix Released by all requested distros