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@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@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@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@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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2097613
Title:
(auto-)Install issue with 25.04 on s390x using DASD disks
To manage notifications about this bug go to:
https://bugs.launchpad.net/subiquity/+bug/2097613/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
