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

[Frank Heimes]

Okay, thank you for your look into this.

I assumed that it is 'just' due to the implementation that was chosen.
But I think it's not intuitive,
and renders the usage of the device list to not always usable - for cases the sequence is relevant.

There is fortunately a workaround, that is to (be on the safe side and to) enable the devices one-by-one, each with it's own chzdev call.
That's okay if just a few devices need to be enabled,
but if the amount grows, it becomes more annoying (and will take longer).

Thanks for considering this as potential future enhancement.
I'll update the status of this LP bug to "Opinion" and the importance to "Wishlist" for now,
and will add an entry to the Ubuntu on s390x FAQs (and might need to add a 'Notice' to the Ubuntu Server docs ...)

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

** Changed in: ubuntu-z-systems
   Importance: High => Wishlist

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

** Changed in: s390-tools (Ubuntu)
   Importance: Undecided => Wishlist

** Changed in: ubuntu-z-systems
     Assignee: Skipper Bug Screeners (skipper-screen-team) => (unassigned)

-- 
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:
  Opinion
Status in s390-tools package in Ubuntu:
  Opinion

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