[19.04 FEAT] I/O device pre-configuration

[bugproxy]

I/O device auto-configuration is a mechanism by which users can specify IDs and settings of I/O devices that should be automatically enabled in Linux. Users enter this information for an LPAR via an HMC running in DPM mode. During boot, Linux obtains this information via an SCLP call (details to be defined) and triggers the resulting configuration actions (e.g. using the chzdev command).
Available with kernel 4.17

[Frank Heimes (fheimes)]

Can you point to the specific commit ID(s) please?

[Dimitri John Ledkov (xnox)]

it would be really nice, if kernel generated relevant udev events, which then can trigger things via udev to autoconfigure things. If I understand this intended feature correctly.

Also, we do not have access to DPM mode in our HMC, thus we will require assistance in testing and validating this.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2018-07-30 11:13 EDT-------
Git Commit ID: s390/sclp: Add support for Store Data SCLP interface [66aec64721]

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2018-08-03 04:56 EDT-------
Enablement Description:

Dependencies on distributors

This item provides sample scripts for implementing the auto-configuration
mechanism during the initial RAM-disk boot phase. Distributors must adapt these
scripts and activate them for the target distributions (both on the installation
ISO as well as on the installed system) similar to this example

Ubuntu:

cd s390-tools/zdev
make all
make install HAVE_INITRAMFS=1

[Dimitri John Ledkov (xnox)]

$ git tag --contains 66aec64721 Ubuntu-4.17.0-6.7
Ubuntu-4.17.0-6.7

[Dimitri John Ledkov (xnox)]

Given that bionic will receive newer kernels via linux-hwe, this userspace functionality needs to be backported to bionic too. Hence making s390-tools package nominated for bionic too.

[Launchpad Janitor (janitor)]

This bug was fixed in the package s390-tools - 2.6.0-0ubuntu2

---------------
s390-tools (2.6.0-0ubuntu2) cosmic; urgency=medium

  * Add zdev initramfs hooks to initialize firmware provided devices by
    default. LP: #1776631

s390-tools (2.6.0-0ubuntu1) cosmic; urgency=medium

  * New upstream release.
  * Add a zkey subpackage LP: #1786460.

 -- Dimitri John Ledkov <email address hidden> Tue, 21 Aug 2018 15:06:21 +0100

[Dimitri John Ledkov (xnox)]

I think we want this in d-i, subiquity, curtin/MAAS, and backported to bionic as well.

This is now in cosmic. Could you please install cosmic, upgrade to latest s390-tools, enter things via HMC and reboot the instance to see if it picks up and auto-activates devices specified via the HMC?

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2018-08-23 10:49 EDT-------
I've installed cosmic on a DPM LPAR using the daily build ISO "cosmic-server-s390x.iso" (dated 2018-08-23). The installed system (kernel 4.17.0-7-generic, s390-tools 2.6.0-0ubuntu3) correctly applied auto-configuration data:

$ lsinitramfs /boot/initrd.img | grep zdev
sbin/chzdev
sbin/lszdev
scripts/init-top/s390-tools-zdev
$ sudo lszdev --auto-conf
TYPE ID AUTO
dasd-eckd 0.0.1000 yes
dasd-eckd 0.0.1001 yes
...

So that is working as expected.

The install system on the other hand DID NOT correctly apply auto-configuration data - all device IDs needed to be input manually. Looking at the install system I found that kernel-support is available, but the initramfs logic that applies the kernel data (scripts/init-top/s390-tools-zdev) is not present in the install initramfs:

$ sudo mount cosmic-server-s390x.iso /mnt -o loop,ro
$ lsinitramfs /mnt/boot/initrd.ubuntu | grep zdev
sbin/lszdev
sbin/chzdev

It appears that the install system is not including initramfs scripts at all.

@Canonical: What is the correct approach for extending the installer initramfs system to run the missing logic?

[Dimitri John Ledkov (xnox)]

This is all correct - thanks for testing.

This feature has currently only landed for the installed systems only; in cosmic only at the moment.

On launchpad side, you can see that there are still tasks open to fix this in bionic; and in the installers.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2018-10-17 10:39 EDT-------
Due to the fact, that this function need Installer updates for a real customer scenario, moving it to 19.04, Even that the upstream activities are done.

[Dimitri John Ledkov (xnox)]

Not targetted to be enabled in the installers for 19.04, due to ongoing usability & correctness questions.

[Frank Heimes (fheimes)]

Closed (set to Fix Released), since this ticket covers the kernel part, which is done.
The installer bits and pieces are tracked in LP 1799684.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2019-04-23 08:46 EDT-------
IBM bugzilla status -> closed, Fix Released with Disco