Arch Linux

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.

Just got this and in my case xfsprogs was missing.

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

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

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

gptfdisk missing was the culprit for me. The other three were already installed. Thanks.

All added in 2.8-3. Please let me know if you still encounter this issue.

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.

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.

@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.

@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.