Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#54338 - [udisks2] fails to start because dependency is missing

Attached to Project: Arch Linux
Opened by Adam K├╝rthy (adee) - Wednesday, 07 June 2017, 07:42 GMT
Last edited by Doug Newgard (Scimmia) - Monday, 15 January 2018, 16:46 GMT
Task Type Bug Report
Category Packages: Testing
Status Closed
Assigned To Felix Yan (felixonmars)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 16
Private No

Details

Description:
systemd[1]: Starting Disk Manager...
udisksd[1138]: udisks daemon version 2.7.0 starting
dbus-daemon[1013]: Successfully activated service 'org.freedesktop.Telepathy.AccountManager'
udisksd[1138]: Cannot load the part plugin: The 'sgdisk' utility is not available
udisksd[1138]: Error initializing libblockdev library: Failed to load plugins (g-bd-init-error-quark, 0)
kernel: traps: udisksd[1138] trap int3 ip:7fe424fe6401 sp:7ffd7f4a9df0 error:0
kernel: in libglib-2.0.so.0.5200.2[7fe424f96000+111000]
systemd[1]: Started Process Core Dump (PID 1145/UID 0).
systemd[1]: udisks2.service: Main process exited, code=dumped, status=5/TRAP
systemd[1]: Failed to start Disk Manager.
systemd[1]: udisks2.service: Unit entered failed state.
systemd[1]: udisks2.service: Failed with result 'core-dump'.

Installing gptfdisk puts the missing binary there and solves the problem


Additional info:
* package version(s)
2.7.0

This task depends upon

Closed by  Doug Newgard (Scimmia)
Monday, 15 January 2018, 16:46 GMT
Reason for closing:  Fixed
Additional comments about closing:  libblockdev 2.8-3
Comment by Hussam Al-Tayeb (hussam) - Wednesday, 07 June 2017, 10:28 GMT
Same issue here. it complains about missing utilities for libblockdev plugins and crashes. It may be best to make them as full dependencies. They won't do damage just sitting there on the hard drive and they are small enough.

udisksd[1138]: Cannot load the part plugin: The 'sgdisk' utility is not available (I think this means it is looking for gptfdisk).

Edit: I rebuilt libblockdev with the following dependencies as static "dmraid parted volume_key libbytesize xfsprogs lvm2 btrfs-progs mdadm gptfdisk" and udisksd starts correctly now.
Comment by Andrea Scarpino (BaSh) - Wednesday, 07 June 2017, 23:06 GMT
Just got this and in my case xfsprogs was missing.
Comment by loqs (loqs) - Thursday, 08 June 2017, 00:27 GMT
dosfstools see https://github.com/rhinstaller/libblockdev/blob/master/src/plugins/fs.c#L280
Edit:
libblockdev also seems to build the lvm_dbus plugin unconditionally then use it in preference over the lvm plugin as
/etc/libblockdev/conf.d/10-lvm-dbus.cfg overrides /etc/libblockdev/conf.d/00-default.cfg in setting
[lvm]
sonames=libbd_lvm-dbus.so.2
my understanding is the lvm2 package is not built with dbus support support so '--without-lvm_dbus' should be passed to configure of libblockdev
Comment by Alexander W. Ahjolinna (ahjolinna) - Thursday, 08 June 2017, 04:35 GMT
I tried the "KaOS's solution" (which is less modular but still) and it works for me now https://github.com/KaOSx/main/commit/499900ea85028af7d9f5b467fd504bbce30cc4be
Comment by Chih-Hsuan Yen (yan12125) - Friday, 09 June 2017, 06:30 GMT
I didn't install all packages in the base group, so there are more missing dependencies:

Jun 09 14:13:37 Arch-PC systemd[1]: Starting Disk Manager...
Jun 09 14:13:37 Arch-PC udisksd[5977]: udisks daemon version 2.7.0 starting
Jun 09 14:13:37 Arch-PC udisksd[5977]: Cannot load the MDRAID plugin: The 'mdadm' utility is not available
Jun 09 14:13:37 Arch-PC udisksd[5977]: Cannot load the part plugin: The 'sgdisk' utility is not available
Jun 09 14:13:37 Arch-PC udisksd[5977]: Cannot load the FS plugin: The 'mkfs.xfs' utility is not available
Jun 09 14:13:37 Arch-PC udisksd[5977]: Cannot load the FS plugin: The 'xfs_db' utility is not available
Jun 09 14:13:37 Arch-PC udisksd[5977]: Cannot load the FS plugin: The 'xfs_repair' utility is not available
Jun 09 14:13:37 Arch-PC udisksd[5977]: Cannot load the FS plugin: The 'xfs_admin' utility is not available
Jun 09 14:13:37 Arch-PC udisksd[5977]: Cannot load the FS plugin: The 'xfs_growfs' utility is not available
Jun 09 14:13:37 Arch-PC udisksd[5977]: Cannot load the FS plugin: The 'mkfs.vfat' utility is not available
Jun 09 14:13:37 Arch-PC udisksd[5977]: Cannot load the FS plugin: The 'fatlabel' utility is not available
Jun 09 14:13:37 Arch-PC udisksd[5977]: Cannot load the FS plugin: The 'fsck.vfat' utility is not available
Jun 09 14:13:37 Arch-PC udisksd[5977]: Error initializing libblockdev library: Failed to load plugins (g-bd-init-error-quark, 0)
Jun 09 14:13:37 Arch-PC systemd[1]: udisks2.service: Main process exited, code=dumped, status=5/TRAP
Jun 09 14:13:37 Arch-PC systemd[1]: Failed to start Disk Manager.
Jun 09 14:13:37 Arch-PC systemd[1]: udisks2.service: Unit entered failed state.
Jun 09 14:13:37 Arch-PC systemd[1]: udisks2.service: Failed with result 'core-dump'.

I install the following additional packages and udisks2 runs fine as usual.
dosfstools 4.1-1
gptfdisk 1.0.1-2
mdadm 4.0-1
xfsprogs 4.11.0-1
Comment by Nicolas Gruel (gruel) - Friday, 09 June 2017, 09:12 GMT
gptfdisk missing was the culprit for me. The other three were already installed. Thanks.
Comment by Felix Yan (felixonmars) - Friday, 09 June 2017, 15:14 GMT
All added in 2.8-3. Please let me know if you still encounter this issue.
Comment by David J. Ring, Jr. (djringjr) - Sunday, 11 June 2017, 21:14 GMT
Same problem here:

Job for udisks2.service failed because a fatal signal was delivered causing the control process to dump core.
See "systemctl status udisks2.service" and "journalctl -xe" for details.
[backup@djringjr-laptop ~]$ journalctl -xe
#21 0x00007f86a383743a __libc_start_main (libc.so.6)
#22 0x0000000000415e8a _start (udisksd)

Stack trace of thread 1832:
#0 0x00007f86a38fa2bd poll (libc.so.6)
#1 0x00007f86a3e24bf9 n/a (libglib-2.0.so.0)
#2 0x00007f86a3e24d0c g_main_context_iteration (libglib-2.0.so.0)
#3 0x00007f86a3e24d51 n/a (libglib-2.0.so.0)
#4 0x00007f86a3e4bac5 n/a (libglib-2.0.so.0)
#5 0x00007f86a3bc3297 start_thread (libpthread.so.0)
#6 0x00007f86a390425f __clone (libc.so.6)

Stack trace of thread 1833:
#0 0x00007f86a38ff3b9 syscall (libc.so.6)
#1 0x00007f86a3e69c7a g_cond_wait_until (libglib-2.0.so.0)
#2 0x00007f86a3df9121 n/a (libglib-2.0.so.0)
#3 0x00007f86a3e4c464 n/a (libglib-2.0.so.0)
#4 0x00007f86a3e4bac5 n/a (libglib-2.0.so.0)
#5 0x00007f86a3bc3297 start_thread (libpthread.so.0)
#6 0x00007f86a390425f __clone (libc.so.6)

Stack trace of thread 1834:
#0 0x00007f86a38fa2bd poll (libc.so.6)
#1 0x00007f86a3e24bf9 n/a (libglib-2.0.so.0)
#2 0x00007f86a3e24f92 g_main_loop_run (libglib-2.0.so.0)
#3 0x00007f86a440c426 n/a (libgio-2.0.so.0)
#4 0x00007f86a3e4bac5 n/a (libglib-2.0.so.0)
#5 0x00007f86a3bc3297 start_thread (libpthread.so.0)
#6 0x00007f86a390425f __clone (libc.so.6)
-- Subject: Process 1831 (udisksd) dumped core
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- Documentation: man:core(5)
--
-- Process 1831 (udisksd) crashed and dumped core.
--
-- This usually indicates a programming error in the crashing program and
-- should be reported to its vendor as a bug.
Comment by John (graysky) - Thursday, 22 June 2017, 17:20 GMT
Just wondering how many of these new dependencies could be moved into the optdepends array? For example, my systems have no use/need for xfsprogs, mdadm, dmraid etc. Thank you.
Comment by Felix Yan (felixonmars) - Thursday, 22 June 2017, 17:39 GMT
@djringjr I don't know if it's the same problem, since your logs didn't carry any information about missing dependencies.

@graysky I used to put all those in optdepends and quite a lot of installation became broken by default. Comparing to the trouble it cause, the added dependencies and small amount of additional disk space are less troublesome, IMHO.
Comment by Hussam Al-Tayeb (hussam) - Thursday, 22 June 2017, 18:01 GMT
@graysky, they won't affect system performance. I wouldn't worry about it :) Plus your system is basically more "robust" and simpler to maintain without modifying dependencies especially when upstream assumes you have the dependencies installed.

Loading...