after exploring udisks2/libblockdev/libfdisk, I have three possible proposals
for resolution:
1. hack udisks2 udisks_linux_partition_table_update
* calling bd_part_get_disk_spec is always going to be a loop, unless
* watches have been inhibited
* or calling bd_part_get_disk_spec causes
ID_PART_TABLE_TYPE to be set
* disable everything under `if (!part_type && num_parts > 0)`, log
and bail
2. add read-only API in libblockdev so we open the dev RO in libfdisk
3. add vtoc support to libfdisk + enable the s390 bits in libblockdev
only option 1 sounds plausible to me, though, for a Mantic timeframe.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2037569
Title:
udev issues with mantic beta
Status in Ubuntu on IBM z Systems:
Confirmed
Status in libblockdev package in Ubuntu:
New
Status in systemd package in Ubuntu:
Invalid
Status in udisks2 package in Ubuntu:
Confirmed
Bug description:
While installing mantic beta (on s390x, LPAR and z/VM - but this might not be
architecture specific) I faced issues with udev.
In my installation I've updated the installer to "edge/lp-2009141" (subiquity
22.02.2+git1762.1b1ee6f4 5164).
During my installations I first noticed bad response times in case of
dealing with devices (like enabling new devices with chzdev). chzdev
is used during the installation, hence the installation procedure is
also affected by this. (I mainly notice this issue in case of DASD
ECKD disk enablements.)
But even after after a successful (but due to this issue less snappier)
installation, means after the post-install reboot, in the installed system I
can find several udev related processes, like:
69448 root 20 0 31280 11944 2560 S 39.2 0.0 2:51.67
(udev-worker)
509 root 20 0 31276 13812 4600 S 20.6 0.0 2:07.76
systemd-udevd
893 root 20 0 469016 13544 10496 R 17.3 0.0 1:43.53
udisksd
1 root 20 0 168664 12748 8396 S 16.3 0.0 1:40.47
systemd
which is not only unusual, but (as one can see) they consume quite some
resources.
Even the remote ssh into that system is impacted by this high load.
So far I only see this in mantic.
I tried 20.04.3 as well as lunar, but both do not seem to be affected by this
udev problem.
I neither face the bad response on device enablement, nor can see any udev
related processes still running after post-install-reboot in the installed
system.
(Sometimes I could also see a growing log file 'syslog').
I cannot say yet what is causing this, but since I see 'systemd-udevd'
as prominent process in top, I'll first of all mark this as affecting
systemd-udevd (or systemd).
I've attached the outcome of some more investigations I did ...
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2037569/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
