[Bug 2097613] Re: (auto-)Install issue with 25.04 on s390x using DASD disks

[Frank Heimes]

After having had a longer debug session (thx to Chris) it turned out
that this issue here is caused by an unexpected behaviour of the chzdev
command (part of s390-tools).

If one for example configures the following three DASDs during an interactive installation in the following sequence and way:
2609 (mod9) 1st partition for /boot, 2nd for LVM
162E (mod27) 1st partition for a LVM
162F (mod27) 1st partition for a LVM
it will end up in the creation of the following devices:
/dev/dasda1 (on 2609) for /boot
/dev/dasda2 (on 2609) for LVM
/dev/dasdb1 (on 162E) for LVM
/dev/dasdc1 (on 162F) for LVM
And this is stored like that in the automatically created /var/log/installer/autoinstall yaml file.

If one now wants to transfers this into a compact chzdev line (for the early-commands section in the autoinstall yaml - since the CCW device enablement needs to be done manually), it would look like this:
  early-commands:
  - chzdev --enable dasd-eckd 2609,162E,162F
And it looks right that this is needed to enable the devices before disk configuration can start.

However, chzdev does NOT enable the devices in the sequence that is given as argument (comma-separated)
(it seems to enable the devices in alphabetical order, or like they appear in the lszdev list of all existing devices).
The result is (unexpectedly):
ubuntu at s1lp15:~$ lsdasd
Bus-ID    Status    Name      Device  Type         BlkSz  Size      Blocks
================================================================================
0.0.162e  active    dasda     94:0    ECKD         4096   21129MB   5409180
0.0.162f  active    dasdb     94:4    ECKD         4096   21129MB   5409180
0.0.2609  active    dasdc     94:8    ECKD         4096   7043MB    1803060
ubuntu at s1lp15:~$ ls -l /dev/dasda*
brw-rw---- 1 root disk 94, 0 Feb 23  2025 /dev/dasda
brw-rw---- 1 root disk 94, 1 Feb 23  2025 /dev/dasda1
ubuntu at s1lp15:~$ ls -l /dev/dasdb*
brw-rw---- 1 root disk 94, 4 Feb 23  2025 /dev/dasdb
brw-rw---- 1 root disk 94, 5 Feb 23  2025 /dev/dasdb1
ubuntu at s1lp15:~$ ls -l /dev/dasdc*
brw-rw---- 1 root disk 94,  8 Feb 23  2025 /dev/dasdc
brw-rw---- 1 root disk 94,  9 Feb 23  2025 /dev/dasdc1
brw-rw---- 1 root disk 94, 10 Feb 23  2025 /dev/dasdc2

So the disk (2609) with the two partitions on it is now dasdc (instead of dasda),
which breaks autoinstall, since autoinstall still expects a dasda2 (that no longer exists anymore - it'S now dasdc2).

A workaround is to not use the compact form of enabling the devices:
chzdev --enable dasd-eckd 2609,162E,162F
but instead split this up into single lines, where each line enables one device:
chzdev --enable dasd-eckd 2609
chzdev --enable dasd-eckd 162E
chzdev --enable dasd-eckd 162F
This (kind of) forces the the device enablement to the desired sequence.

It's obvious that this is not an issue with subiquity or the installation procedure in general,
hence I'm updating the subiquity entry to Invalid,
but will add s390-tools and ask IBM is chzdev behaves like intended.

** Changed in: subiquity
       Status: New => Invalid

** Changed in: ubuntu-z-systems
       Status: New => In Progress

** Also affects: s390-tools (Ubuntu)
   Importance: Undecided
       Status: New

** Changed in: s390-tools (Ubuntu)
       Status: New => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to s390-tools in Ubuntu.
https://bugs.launchpad.net/bugs/2097613

Title:
  (auto-)Install issue with 25.04 on s390x using DASD disks

Status in subiquity:
  Invalid
Status in Ubuntu on IBM z Systems:
  In Progress
Status in s390-tools package in Ubuntu:
  Confirmed

Bug description:
  This is actually a spin off of comment #9 of LP bug #2093352 "autoinstall crash with Ubuntu Server 25.04":
  https://bugs.launchpad.net/subiquity/+bug/2093352/comments/9
  since it's believed that this is a different bug compared to what's described as well.


  That's weird having done the same with an LPAR system now, using DASD disks (which I assumed to work), autoinstall fails on LPAR with:
  "
  2025-02-03 15:28:22,913 INFO probert.lvm:119 b' 1 logical volume(s) in volume group "s1lp15vg" now active\n'
  2025-01-31 15:28:25,619 INFO curtin:1396 Validating extracted storage config components
  2025-01-31 15:28:36,199 INFO root:38 finish: subiquity/Network/apply_config: SUCCESS: silent=False
  2025-01-31 15:28:46,210 ERROR root:38 finish: subiquity/Mirror/apply_autoinstall_config/waiting: FAIL:
  2025-01-31 15:29:00,731 ERROR root:38 finish: subiquity/Filesystem/apply_autoinstall_config/convert_autoinstall_config: FAIL: '/dev/dasda2'
  2025-01-31 15:29:00,731 ERROR root:38 finish: subiquity/Filesystem/apply_autoinstall_config: FAIL: '/dev/dasda2'
  2025-01-31 15:29:00,731 ERROR root:38 finish: subiquity/apply_autoinstall_config: FAIL: '/dev/dasda2'
  2025-01-31 15:29:00,731 ERROR subiquity.server.server:525 top level error
  Traceback (most recent call last):
    File "/snap/subiquity/6390/lib/python3.12/site-packages/subiquity/server/server.py", line 1043, in start
      await self.apply_autoinstall_config()
    File "/snap/subiquity/6390/lib/python3.12/site-packages/subiquitycore/context.py", line 165, in decorated_async
      return await meth(self, **kw)
             ^^^^^^^^^^^^^^^^^^^^^^
  "

  Looks like the device "/dev/dasda2" cannot be properly handled - but
  this is a proper partition on a DASD disk.

To manage notifications about this bug go to:
https://bugs.launchpad.net/subiquity/+bug/2097613/+subscriptions