[Bug 2146873] Re: Custom partitioning on DASD ECKD (s390x) can lead to a failed installation

Olivier Gayot 2146873 at bugs.launchpad.net
Tue Apr 21 13:12:28 UTC 2026


The reason this scenario works outside of DASD is because we use:

$ sfdisk --no-reread
$ partprobe

The --no-reread option does not completely skip the call to
ioctl(BLKRRPART) as one would expect - but instead allows sfdisk to
proceed if partitions are in use.

In such a scenario, the ioctl(BLKRRPART) call fails with EBUSY but
sfdisk only emits a warning:

Re-reading the partition table failed.
The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or partx(8).

There is no equivalent option for `fdasd` so if we want to unify the
implementation, we should either add the new option, or make sure we
mount partitions *after* finishing partitioning.

I suppose we could teach Subiquity to emit "mount" actions at the end
when doing manual/guided partitioning.

** Also affects: subiquity
   Importance: Undecided
       Status: New

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

** Changed in: subiquity
   Importance: Undecided => High

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

Title:
  Custom partitioning on DASD ECKD (s390x) can lead to a failed
  installation

Status in subiquity:
  Triaged
Status in Release Notes for Ubuntu:
  New
Status in Ubuntu on IBM z Systems:
  Confirmed
Status in curtin package in Ubuntu:
  New
Status in subiquity package in Ubuntu:
  New

Bug description:
  Using custom partitioning for DASD ECKD disk devices on s390x can lead
  to a failed installation and crash, due to the way the
  disk/partitioning is handled today.

  This happens in case the root partition is not the only partition that
  is specified and not the last one (of the up to three possible
  partitions on a DASD ECKD disk), an installation may fail in case an
  ext4 filesystem is used for root.

  A workaround is to ensure that the root partition is specified as the **last** (or only) partition, like for example:
  1st partition: /boot
  2nd partition: swap
  3rd partition: / (root)
  _____

  Please try a 26.04 beta (or daily) test installation (using largely
  the defaults) on z/VM with DASD disks.

  (https://cdimage.ubuntu.com/ubuntu-server/daily-live/20260329/ or
  better latest daily:)

  https://cdimage.ubuntu.com/ubuntu-server/daily-live/current/

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





More information about the foundations-bugs mailing list