search

storaged-project / udisks

The UDisks project provides a daemon, tools and libraries to access and manipulate disks, storage devices and technologies.
https://storaged.org/doc/udisks2-api/latest/
Other
348 stars 142 forks source link

Issue with kde plasma and udisks 2.10 #1139

Closed alexjp closed 1 year ago

alexjp commented 1 year ago

Nixos distro updated udisks to 2.10 some days ago, and since then, kde plasma starting up and at first login freezes for some 5 seconds ( and has other issues, which seems like plasma crashed, although logs don't show any crash ).

This only happens at the first login after boot, being the following ones without this issue.

Going back to 2.9 fixes this. Also disabling udisks fixes the freezing.

I also tested on archlinux, manually updating udisks2 and libblockdev packages and the issue happens also on archlinux.

I apologize because I don't have enough tecnical knowledge to give more detailed info, but I have 2 nvme disks and 2 hdd disks. I also see this on the systemd udisksd unit log:

udisksd[1486]: udisks daemon version 2.10.0 starting
udisksd[1486]: Failed to load config files: Failed to get contents of the config dir (/etc/libblockdev/3/conf.d/)Error opening directory “/etc/libblockdev/3/conf.d/”: No such file or directory. Using the buil
t-in config
udisksd[1486]: Error getting 'loop0' information: Failed to get status of the device loop0: No such device or address (g-bd-loop-error-quark, 1)
udisksd[1486]: Error getting 'loop1' information: Failed to get status of the device loop1: No such device or address (g-bd-loop-error-quark, 1)
udisksd[1486]: Error getting 'loop2' information: Failed to get status of the device loop2: No such device or address (g-bd-loop-error-quark, 1)
udisksd[1486]: Error getting 'loop3' information: Failed to get status of the device loop3: No such device or address (g-bd-loop-error-quark, 1)
udisksd[1486]: Error getting 'loop4' information: Failed to get status of the device loop4: No such device or address (g-bd-loop-error-quark, 1)
udisksd[1486]: Error getting 'loop5' information: Failed to get status of the device loop5: No such device or address (g-bd-loop-error-quark, 1)
udisksd[1486]: Error getting 'loop6' information: Failed to get status of the device loop6: No such device or address (g-bd-loop-error-quark, 1)
udisksd[1486]: Error getting 'loop7' information: Failed to get status of the device loop7: No such device or address (g-bd-loop-error-quark, 1)
udisksd[1486]: Error getting 'loop0' information: Failed to get status of the device loop0: No such device or address (g-bd-loop-error-quark, 1)
udisksd[1486]: Error getting 'loop1' information: Failed to get status of the device loop1: No such device or address (g-bd-loop-error-quark, 1)
udisksd[1486]: Error getting 'loop2' information: Failed to get status of the device loop2: No such device or address (g-bd-loop-error-quark, 1)
udisksd[1486]: Error getting 'loop3' information: Failed to get status of the device loop3: No such device or address (g-bd-loop-error-quark, 1)
udisksd[1486]: Error getting 'loop4' information: Failed to get status of the device loop4: No such device or address (g-bd-loop-error-quark, 1)
udisksd[1486]: Error getting 'loop5' information: Failed to get status of the device loop5: No such device or address (g-bd-loop-error-quark, 1)
udisksd[1486]: Error getting 'loop6' information: Failed to get status of the device loop6: No such device or address (g-bd-loop-error-quark, 1)
udisksd[1486]: Error getting 'loop7' information: Failed to get status of the device loop7: No such device or address (g-bd-loop-error-quark, 1)
udisksd[1486]: Acquired the name org.freedesktop.UDisks2 on the system message bus

If more info is required, feel free to ask. Sorry if this issue isn't valid.

Thanks!

tisyang commented 1 year ago

I have the same issues under KDE. And with additional bugs:

udisks will always auto-mount usb storage disks under mount point /tmp/xxxxx, even I have lable uuid with certain mount point in /etc/fstab . Before upgrade udisks2, it will not auto-mouunt, and when click mouunt, the mouunt point will be /media/${user}/${lable} or ${uuid} .

tisyang commented 1 year ago

I'm running Debian sid with KDE Plasma 5.27.5. After downgrade udisk2 to 2.9.4-4, all thing goes right like before.

bitseater commented 1 year ago

Hi, same issue running Debian unstable with Gnome 43.6 . After last update udisks2 to 2.10 , login process delays more than 5 seconds. I can't see others ssd and usb drives. I can't run gnome-disks. If I try to launch it from terminal i have the following error:

Error getting udisks client: Timeout was reached

The output from journalctl -u udisks2.service is :

jul 12 00:56:54 andromeda systemd[1]: Started udisks2.service - Disk Manager. jul 12 00:56:54 andromeda udisksd[718]: Acquired the name org.freedesktop.UDisks2 on the system message bus jul 12 01:03:21 andromeda udisksd[718]: Error getting 'loop0' information: Failed to get status of the device loop0: No such device or address (g-bd-loop-error-quark, 1) jul 12 01:03:21 andromeda udisksd[718]: Error getting 'loop1' information: Failed to get status of the device loop1: No such device or address (g-bd-loop-error-quark, 1) jul 12 01:03:21 andromeda udisksd[718]: Error getting 'loop2' information: Failed to get status of the device loop2: No such device or address (g-bd-loop-error-quark, 1) jul 12 01:03:21 andromeda udisksd[718]: Error getting 'loop3' information: Failed to get status of the device loop3: No such device or address (g-bd-loop-error-quark, 1) jul 12 01:03:21 andromeda udisksd[718]: Error getting 'loop7' information: Failed to get status of the device loop7: No such device or address (g-bd-loop-error-quark, 1) jul 12 01:03:21 andromeda udisksd[718]: Error getting 'loop4' information: Failed to get status of the device loop4: No such device or address (g-bd-loop-error-quark, 1) jul 12 01:03:21 andromeda udisksd[718]: Error getting 'loop6' information: Failed to get status of the device loop6: No such device or address (g-bd-loop-error-quark, 1) jul 12 01:03:21 andromeda udisksd[718]: Error getting 'loop5' information: Failed to get status of the device loop5: No such device or address (g-bd-loop-error-quark, 1) jul 12 01:03:22 andromeda systemd[1]: Stopping udisks2.service - Disk Manager... jul 12 01:03:22 andromeda udisksd[718]: udisks daemon version 2.10.0 exiting jul 12 01:03:22 andromeda systemd[1]: udisks2.service: Deactivated successfully. jul 12 01:03:22 andromeda systemd[1]: Stopped udisks2.service - Disk Manager. jul 12 01:03:22 andromeda systemd[1]: udisks2.service: Consumed 49.928s CPU time.

I have to downgrade udisks2 and libudisks2-0 to 2.9.4-4 (debian testing) and the issue has disappeared.

Firestar-Reimu commented 1 year ago

Maybe this is why Archlinux do not update udisks to 2.10.0

amurzeau commented 1 year ago

I got into this too, kde starting up freeze for almost one minute.

While it is freezing, udisks2 service is running ntfscluster and NTFS partitions. I saw that as I have a NTFS USB key which is blinking for > 30s when kde is frozen. Then same for the HDD (I have Windows as dual boot).

When running ntfscluster manually on my USB key, it takes 45s (each time I run ntfscluster on it).

Maybe this issue appeared since commit https://github.com/storaged-project/udisks/commit/2892d77c5a29b52d2909a3fc3255ff9f4e6937ca.

Plugging a NTFS USB key after KDE start up will also trigger the same issue:

real 0m25,033s user 0m0,000s sys 0m0,010s



Downgrading to udisks2 2.9.4 fixes theses issues.
amurzeau commented 1 year ago

Reposting here as maybe more related to udisks2:

Also while true; do udisksctl status; done since 2.10 will heavily use disks (their activity led is almost always on).

I guess 2.9 wasn't refreshing disk usage values explaining why it was faster.

But many programs seems to use the get_size or get_info API often, for example opening the KDE network applet panel will probably call these functions as it causes heavy disk usage.

Unplugging and plugging the network cable also trigger very high disk usage.

vojtechtrefny commented 1 year ago

Maybe this issue appeared since commit 2892d77.

But many programs seems to use the get_size or get_info API often, for example opening the KDE network applet panel will probably call these functions as it causes heavy disk usage.

The org.freedesktop.UDisks2.Filesystem.Size was always problematic and it looks like introducing support for more filesystems caused even more problems (see also #1145). I will probably revert 2892d77 or limit it back to Ext and XFS only.

This issue will be finally fixed when util-linux 2.39 will be generally available, we'll then get all the information from udev instead of running (possibly too intrusive) command line tools (see https://github.com/storaged-project/udisks/pull/1114). Unfortunately 2.39 is not yet available in Debian Unstable.

I am sorry for this and big thanks to @amurzeau for debugging this and the fix for libblockdev. I'll try to do a new bugfix build of libblockdev during the weekend and hopefully fix the problem for you all.

tbzatek commented 1 year ago

This issue will be finally fixed when util-linux 2.39 will be generally available, we'll then get all the information from udev instead of running (possibly too intrusive) command line tools (see #1114). Unfortunately 2.39 is not yet available in Debian Unstable.

FYI @mbiebl @seb128 having util-linux-2.39 in the distribution along with udisks-2.10.0 would bring great benefits of lowering I/O and faster startup due to libblkid providing the necessary info.

Nixos distro updated udisks to 2.10 some days ago, and since then, kde plasma starting up and at first login freezes for some 5 seconds ( and has other issues, which seems like plasma crashed, although logs don't show any crash ).

Congratulations, you've found a bug in KDE. In general UI should not actively wait for udisks reply over D-Bus method calls, everything should be async. This udisks issue only revealed deficiencies elsewhere.

I saw that as I have a NTFS USB key which is blinking for > 30s when kde is frozen.

juil. 14 15:29:01 Debian2 org_kde_powerdevil[1387]: kf.solid.backends.udisks2: Error getting props: "org.freedesktop.DBus.Error.UnknownMethod" "Object does not exist at path “/org/freedesktop/UDisks2/block_devices/sdb1”" for "/org/freedesktop/UDisks2/block_devices/sdb1"

Same cases, these should all by async calls, not blocking the UI.

mbiebl commented 1 year ago

FYI @mbiebl @seb128 having util-linux-2.39 in the distribution along with udisks-2.10.0 would bring great benefits of lowering I/O and faster startup due to libblkid providing the necessary info.

while I don't maintain util-linux, this is valuable information, thanks!

tbzatek commented 1 year ago

while I don't maintain util-linux, this is valuable information, thanks!

This was a gentle lobby attempt... ;-)

zeha commented 1 year ago

Unfortunately 2.39 is not yet available in Debian Unstable.

2.39.1 is now in Debian experimental, and it'd be useful if interested people tested that.

tbzatek commented 1 year ago

Unfortunately 2.39 is not yet available in Debian Unstable.

2.39.1 is now in Debian experimental, and it'd be useful if interested people tested that.

Forgot to add that you need recent udev (v252) as well: https://github.com/systemd/systemd/commit/704116c976bd2133b1bc8fcfe23956b82c50a6a7

retrofun commented 1 year ago

I'm running Debian sid with KDE Plasma 5.27.5. After downgrade udisk2 to 2.9.4-4, all thing goes right like before.

Debian testing (trixie/sid) here with XFCE 4.18.

Update of udisks2 from 2.9.4-4 to 2.10.0-3 came in on July, 20th. Since then all drive icons on desktop went away and removable drives that were plugged in didn't show up anymore.

udisksctl dump always failed with Error connecting to the udisks daemon: Timeout was reached

This is my desktop system with many internal and external disk drives and a lot of partitions with different file systems: ext4, ntfs, fat32

I just downgraded to udisks2 2.9.4-4 from Debian stable and everything works again.

On my Linux only laptop - also Debian testing (trixie/sid) with XFCE 4.18 - and Linux partitions only udisks2 2.10.0-3 works fine without any problems.

marcbres commented 1 year ago

I had the same problem on debian trixie, after upgrading to 2.10.0-3. Reverting back to 2.9.4 fixes the problems. I've opened a message to debian maintainers and after reviewing the logs they asked me to open it here. As this seems to be the same issue, I'm not opening a new message, Here are the logs and the gdb trace:

systemctl status

de jul. 22 22:53:20 helm systemd[1]: Starting udisks2.service - Disk Manager...
de jul. 22 22:53:20 helm udisksd[1286]: udisks daemon version 2.10.0 starting
de jul. 22 22:53:20 helm udisksd[1286]: Error getting 'loop6' information: Failed to get status of the device loop6: No such device or address (g-bd-loop-error-quark, 1)
de jul. 22 22:53:20 helm udisksd[1286]: Error getting 'loop7' information: Failed to get status of the device loop7: No such device or address (g-bd-loop-error-quark, 1)
de jul. 22 22:53:20 helm udisksd[1286]: Error getting 'loop6' information: Failed to get status of the device loop6: No such device or address (g-bd-loop-error-quark, 1)
de jul. 22 22:53:20 helm udisksd[1286]: Error getting 'loop7' information: Failed to get status of the device loop7: No such device or address (g-bd-loop-error-quark, 1)
de jul. 22 22:53:20 helm udisksd[1286]: *** stack smashing detected ***: terminated
de jul. 22 22:53:20 helm systemd[1]: udisks2.service: Main process exited, code=killed, status=6/ABRT
de jul. 22 22:53:20 helm systemd[1]: udisks2.service: Failed with result 'signal'.
de jul. 22 22:53:20 helm systemd[1]: Failed to start udisks2.service - Disk Manager.

gdb backtrace

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff6bd76c0 (LWP 3418)]
[New Thread 0x7ffff63d66c0 (LWP 3419)]
[New Thread 0x7ffff5bd56c0 (LWP 3420)]
[New Thread 0x7ffff53d46c0 (LWP 3421)]
[New Thread 0x7fffe7fff6c0 (LWP 3422)]

Thread 1 "udisksd" received signal SIGABRT, Aborted.
__pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
#0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
#1  0x00007ffff758115f in __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
#2  0x00007ffff7533472 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3  0x00007ffff751d4b2 in __GI_abort () at ./stdlib/abort.c:79
#4  0x00007ffff751e1ed in __libc_message (fmt=fmt@entry=0x7ffff7690543 "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:150
#5  0x00007ffff760f2c5 in __GI___fortify_fail (msg=msg@entry=0x7ffff769052b "stack smashing detected") at ./debug/fortify_fail.c:24
#6  0x00007ffff760f2b0 in __stack_chk_fail () at ./debug/stack_chk_fail.c:24
#7  0x00007ffff45ba732 in bd_nvme_get_sanitize_log (device=0x555555634950 "/dev/nvme0", error=0x0) at ./src/plugins/nvme/nvme-info.c:1084
#8  0x0000000000000000 in  ()
#0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
        tid = <optimized out>
        ret = 0
        pd = <optimized out>
        old_mask = {__val = {0}}
        ret = <optimized out>
#1  0x00007ffff758115f in __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
#2  0x00007ffff7533472 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
        ret = <optimized out>
#3  0x00007ffff751d4b2 in __GI_abort () at ./stdlib/abort.c:79
        save_stage = 1
        act = {__sigaction_handler = {sa_handler = 0x20, sa_sigaction = 0x20}, sa_mask = {__val = {0 <repeats 16 times>}}, sa_flags = 0, sa_restorer = 0x0}
#4  0x00007ffff751e1ed in __libc_message (fmt=fmt@entry=0x7ffff7690543 "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:150
        ap = {{gp_offset = 16, fp_offset = 0, overflow_arg_area = 0x7fffffffd5d0, reg_save_area = 0x7fffffffd560}}
        fd = <optimized out>
        list = <optimized out>
        nlist = <optimized out>
        cp = <optimized out>
#5  0x00007ffff760f2c5 in __GI___fortify_fail (msg=msg@entry=0x7ffff769052b "stack smashing detected") at ./debug/fortify_fail.c:24
#6  0x00007ffff760f2b0 in __stack_chk_fail () at ./debug/stack_chk_fail.c:24
#7  0x00007ffff45ba732 in bd_nvme_get_sanitize_log (device=0x555555634950 "/dev/nvme0", error=0x0) at ./src/plugins/nvme/nvme-info.c:1084
        ret = <optimized out>
        fd = <optimized out>
        sanitize_log = {sprog = 65535, sstat = 1, scdw10 = 0, eto = 0, etbe = 0, etce = 0, etond = 0, etbend = 0, etcend = 0, rsvd32 = '\000' <repeats 479 times>}
        log = <optimized out>
        sstat = <optimized out>
#8  0x0000000000000000 in  ()

Thread 6 (Thread 0x7fffe7fff6c0 (LWP 3422) "probing-thread"):
#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x00007ffff778c260 in g_cond_wait () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007ffff76fcefb in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007ffff76fd387 in g_async_queue_pop () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x0000555555577fb9 in probe_request_thread_func (user_data=<optimized out>) at ./src/udiskslinuxprovider.c:292
        provider = 0x555555612180
        request = <optimized out>
        dev_initialized = <optimized out>
        n_tries = <optimized out>
#5  0x00007ffff775ee9d in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#6  0x00007ffff757f3ec in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:444
        ret = <optimized out>
        pd = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140737343123760, -4673221325080522273, -432, 0, 140737488343648, 140737077309440, 4673238917700096479, 4673205176068444639}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
#7  0x00007ffff75ffa1c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 5 (Thread 0x7ffff53d46c0 (LWP 3421) "gdbus"):
#0  0x00007ffff75f29ef in __GI___poll (fds=0x7fffe0000b90, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
        sc_ret = -516
        sc_cancel_oldtype = 0
#1  0x00007ffff773285e in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007ffff7732b9f in g_main_loop_run () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007ffff79982c6 in  () at /lib/x86_64-linux-gnu/libgio-2.0.so.0
#4  0x00007ffff775ee9d in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x00007ffff757f3ec in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:444
        ret = <optimized out>
        pd = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140737343123760, -4673221325080522273, -432, 11, 140737316210928, 140737299431424, 4673200999044452831, 4673205176068444639}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
#6  0x00007ffff75ffa1c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 4 (Thread 0x7ffff5bd56c0 (LWP 3420) "pool-udisksd"):
#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x00007ffff778c40c in g_cond_wait_until () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007ffff76fced3 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007ffff775f85a in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x00007ffff775ee9d in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x00007ffff757f3ec in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:444
        ret = <optimized out>
        pd = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140737343123760, -4673221325080522273, -432, 0, 140737324603888, 140737307824128, 4673199898995954143, 4673205176068444639}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
#6  0x00007ffff75ffa1c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 3 (Thread 0x7ffff63d66c0 (LWP 3419) "pool-spawner"):
#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x00007ffff778c260 in g_cond_wait () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007ffff76fcefb in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007ffff775f4e2 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x00007ffff775ee9d in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x00007ffff757f3ec in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:444
        ret = <optimized out>
        pd = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140737343123760, -4673221325080522273, -432, 2, 140737488346848, 140737316216832, 4673203196993966559, 4673205176068444639}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
#6  0x00007ffff75ffa1c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 2 (Thread 0x7ffff6bd76c0 (LWP 3418) "gmain"):
#0  0x00007ffff75f29ef in __GI___poll (fds=0x5555555e44d0, nfds=2, timeout=4630) at ../sysdeps/unix/sysv/linux/poll.c:29
        sc_ret = -516
        sc_cancel_oldtype = 0
#1  0x00007ffff773285e in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007ffff773297c in g_main_context_iteration () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007ffff77329c1 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x00007ffff775ee9d in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x00007ffff757f3ec in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:444
        ret = <optimized out>
        pd = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140737343123760, -4673221325080522273, -432, 2, 140737488346832, 140737324609536, 4673202096945467871, 4673205176068444639}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
#6  0x00007ffff75ffa1c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 1 (Thread 0x7ffff709f940 (LWP 3415) "udisksd"):
#0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
        tid = <optimized out>
        ret = 0
        pd = <optimized out>
        old_mask = {__val = {0}}
        ret = <optimized out>
#1  0x00007ffff758115f in __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
#2  0x00007ffff7533472 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
        ret = <optimized out>
#3  0x00007ffff751d4b2 in __GI_abort () at ./stdlib/abort.c:79
        save_stage = 1
        act = {__sigaction_handler = {sa_handler = 0x20, sa_sigaction = 0x20}, sa_mask = {__val = {0 <repeats 16 times>}}, sa_flags = 0, sa_restorer = 0x0}
#4  0x00007ffff751e1ed in __libc_message (fmt=fmt@entry=0x7ffff7690543 "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:150
        ap = {{gp_offset = 16, fp_offset = 0, overflow_arg_area = 0x7fffffffd5d0, reg_save_area = 0x7fffffffd560}}
        fd = <optimized out>
        list = <optimized out>
        nlist = <optimized out>
        cp = <optimized out>
#5  0x00007ffff760f2c5 in __GI___fortify_fail (msg=msg@entry=0x7ffff769052b "stack smashing detected") at ./debug/fortify_fail.c:24
#6  0x00007ffff760f2b0 in __stack_chk_fail () at ./debug/stack_chk_fail.c:24
#7  0x00007ffff45ba732 in bd_nvme_get_sanitize_log (device=0x555555634950 "/dev/nvme0", error=0x0) at ./src/plugins/nvme/nvme-info.c:1084
        ret = <optimized out>
        fd = <optimized out>
        sanitize_log = {sprog = 65535, sstat = 1, scdw10 = 0, eto = 0, etbe = 0, etce = 0, etond = 0, etbend = 0, etcend = 0, rsvd32 = '\000' <repeats 479 times>}
        log = <optimized out>
        sstat = <optimized out>
#8  0x0000000000000000 in  ()

hope it helps to find the problem. This PC has 2 nvme units and 2 sata SSDs. As the error seems to be on some nvme related function I thought to mention it just in case it is useful

bitseater commented 1 year ago

Unfortunately 2.39 is not yet available in Debian Unstable.

2.39.1 is now in Debian experimental, and it'd be useful if interested people tested that.

Tested with Debian sid/trixie . Same issue with delay at boot. I have to downgrade to udisks2 2.9.4

zeha commented 1 year ago

Unfortunately 2.39 is not yet available in Debian Unstable.

2.39.1 is now in Debian experimental, and it'd be useful if interested people tested that.

Tested with Debian sid/trixie . Same issue with delay at boot. I have to downgrade to udisks2 2.9.4

Did you try with util-linux from experimental?

mbiebl commented 1 year ago

@marcbres

I had the same problem on debian trixie, after upgrading to 2.10.0-3

I do think yours is a different issue. The issue here is a delay on login. Yours is udisksd failing to start with a SIGABRT.

bitseater commented 1 year ago

Unfortunately 2.39 is not yet available in Debian Unstable.

2.39.1 is now in Debian experimental, and it'd be useful if interested people tested that.

Tested with Debian sid/trixie . Same issue with delay at boot. I have to downgrade to udisks2 2.9.4

Did you try with util-linux from experimental?

Yes, when upgrade to udisks2 2.10.0-3, also upgrade libudisks2-0, bsdextrautils, bsdutils, eject, fdisk, libblkid-dev, libblkid1, libfdisk1, libmount-dev, libmount1, libsmartcols1, libuuid1, mount, & util-linux, util-linux-extra from experimental.

Finally, i have to downgrade all packages to sid/trixie and apt-mark hold udisks2 & libudisks2-0

tisyang commented 1 year ago

KDE and udisks 2.10 works fine now, I'm running Debian sid.

libblockdev 3.0.2-1 udisks2 2.10.0-3

udisks2 log still report these but all things fine:

7月 24 08:15:11 debian udisksd[911]: Error getting 'loop0' information: Failed to get status of the device loop0: No such device or addr>
7月 24 08:15:11 debian udisksd[911]: Error getting 'loop1' information: Failed to get status of the device loop1: No such device or addr>
7月 24 08:15:11 debian udisksd[911]: Error getting 'loop2' information: Failed to get status of the device loop2: No such device or addr>
7月 24 08:15:11 debian udisksd[911]: Error getting 'loop3' information: Failed to get status of the device loop3: No such device or addr>
7月 24 08:15:11 debian udisksd[911]: Error getting 'loop4' information: Failed to get status of the device loop4: No such device or addr>
7月 24 08:15:11 debian udisksd[911]: Error getting 'loop5' information: Failed to get status of the device loop5: No such device or addr>
7月 24 08:15:11 debian udisksd[911]: Error getting 'loop6' information: Failed to get status of the device loop6: No such device or addr>
7月 24 08:15:11 debian udisksd[911]: Error getting 'loop7' information: Failed to get status of the device loop7: No such device or addr>
7月 24 08:15:11 debian udisksd[911]: Error getting 'loop0' information: Failed to get status of the device loop0: No such device or addr>
7月 24 08:15:11 debian udisksd[911]: Error getting 'loop1' information: Failed to get status of the device loop1: No such device or addr>
7月 24 08:15:11 debian udisksd[911]: Error getting 'loop2' information: Failed to get status of the device loop2: No such device or addr>
7月 24 08:15:11 debian udisksd[911]: Error getting 'loop3' information: Failed to get status of the device loop3: No such device or addr>
7月 24 08:15:11 debian udisksd[911]: Error getting 'loop4' information: Failed to get status of the device loop4: No such device or addr>
7月 24 08:15:11 debian udisksd[911]: Error getting 'loop5' information: Failed to get status of the device loop5: No such device or addr>
7月 24 08:15:11 debian udisksd[911]: Error getting 'loop6' information: Failed to get status of the device loop6: No such device or addr>
7月 24 08:15:11 debian udisksd[911]: Error getting 'loop7' information: Failed to get status of the device loop7: No such device or addr>
tbzatek commented 1 year ago

@marcbres

I had the same problem on debian trixie, after upgrading to 2.10.0-3

I do think yours is a different issue. The issue here is a delay on login. Yours is udisksd failing to start with a SIGABRT.

Please open a separate ticket. Please also state your libnvme version and output of nvme sanitize-log -H /dev/nvme0.

tbzatek commented 1 year ago

udisks2 log still report these but all things fine:

This has been fixed by #1148

tbzatek commented 1 year ago

Yes, when upgrade to udisks2 2.10.0-3, also upgrade libudisks2-0, bsdextrautils, bsdutils, eject, fdisk, libblkid-dev, libblkid1, libfdisk1, libmount-dev, libmount1, libsmartcols1, libuuid1, mount, & util-linux, util-linux-extra from experimental.

You also need a new udev, please see my comment above: https://github.com/storaged-project/udisks/issues/1139#issuecomment-1645653023

bitseater commented 1 year ago

Yes, when upgrade to udisks2 2.10.0-3, also upgrade libudisks2-0, bsdextrautils, bsdutils, eject, fdisk, libblkid-dev, libblkid1, libfdisk1, libmount-dev, libmount1, libsmartcols1, libuuid1, mount, & util-linux, util-linux-extra from experimental.

You also need a new udev, please see my comment above: #1139 (comment)

Running udev & systemd under version 254~rc2-3 > 252

bitseater commented 1 year ago

Update to udisks2 2.10.0-5 with same issues. I can see a internal ssd with ntfs partition and other external ssd with fat32 partition

tbzatek commented 1 year ago

Right, checking util-linux sources, only xfs, ext and btrfs probes do have support for reporting filesystem last block. Many others only report filesystem size that we don't use at the moment.

azioga commented 1 year ago

after 2.10 update, when I plug in my vfat usb disk, a "never ending" fsck.vfat process starts. this prevents plasma-kde from working properly. at the end of fsck the disk is not listed in usb devices and dolphin restarts fsck.vfat no problem with 2.9 version, the disc is recognized correctly. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043022

retrofun commented 1 year ago

udisks 2.10.1 Debian packages are now available at http://ftp.us.debian.org/debian/pool/main/u/udisks2/

The packages work for me on Debian testing trixie/sid!

After apt-mark unhold libudisks2-0 udisks2, apt upgrade (installlation of udisks2 (2.10.0-5) & libudisks2-0:amd64 (2.10.0-5) with the issue) and finally manual package installation with dpkg -i udisks2_2.10.1-1_amd64.deb libudisks2-0_2.10.1-1_amd64.deb disks/partitions are back on my desktop.

Thanks.

tbzatek commented 1 year ago

The packages work for me on Debian testing trixie/sid!

Thanks for testing. Don't forget to update libblockdev as well, many fixes went there actually.

retrofun commented 1 year ago

libblockdev packages were updated from 2.28 to 3.0.3 when installing udisks2 package from 2.9.4-4 to 2.10.0-5 in step apt upgrade. :+1:

bitseater commented 1 year ago

Unhold and update on Debian trixie/sid. All packages working flawless. Good job