Installed packages Name : udisks2 Epoch : 0 Version : 2.10.0 Release : 1.fc39 Source : udisks2-2.10.0-1.fc39.src.rpm From repository : rawhide Summary : Disk Manager Both mate and pcmanfm file managers fail to display partitions/file system details other than rawhide. Reproducible: Always Steps to Reproduce: 1.upgrade rawhide udisks2 to udisks2-2.10.0-1.fc39 2.boot rawhide to disktop 3 invoke file manager(s) and note no partitions/filesystems shown other than fedora/rawhide Actual Results: launch file manager(s) and note no partitions/filesystems shown other than fedora/rawhide Expected Results: launch file manager(s) and display available partitions/filesystems revert to pre-update version restores functiondality dnf upgrade excluding udisks2 results in proper file manager funtionality
Can you provide `udisksctl dump` please? If you've reverted the packages, I would be interested in the differences. Do you see anything from `gio list -l computer:///` ?
The udisksctl dump contains private information not intended for the web, although the output details a list of loop devices and partitions. gio list -l computer:/// Arch.mount 0 (mountable) Data.mount 0 (mountable) root.link 0 (mountable) Note that partitions such as ntfs and ext2 are manually mountable/files accessible via cli. Could this issue be related: https://bugzilla.redhat.com/show_bug.cgi?id=2189241
(In reply to publiccontact2020 from comment #2) > gio list -l computer:/// > Arch.mount 0 (mountable) > Data.mount 0 (mountable) > root.link 0 (mountable) This looks like a fallback GUnixMountMonitor. Either gvfs-udisks2-volume-monitor can't connect to udisks or it crashed. Anything related in journal? Anything in `systemctl status udisks2.service`? @oholy: could you please test recent rawhide with gvfs? I don't have any rawhide machine around.
I've just tried with https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-Rawhide-20230704.n.0.iso and everything seems to work fine. It would be better to check the `gio mount -l` output instead. If the types of drives/volumes/mounts have "(GProxyVolumeMonitorUDisks2)" suffix or not.
Thanks Ondrej! Forgot to add that the mentioned `gio` commands need to be run within a running desktop session (or a separate dbus session), avoid any root interaction. Also, can you check the rpm versions please? `rpm -qa | grep -e udisks -e gvfs -e libblockdev`
no volumes showing in file manager: gio mount -l (gio mount:14471): GVFS-RemoteVolumeMonitor-WARNING **: 14:27:29.771: remote volume monitor with dbus name org.gtk.vfs.UDisks2VolumeMonitor is not supported >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ntfs mounted via cli: $ gio mount -l (gio mount:6372): GVFS-RemoteVolumeMonitor-WARNING **: 14:20:35.224: remote volume monitor with dbus name org.gtk.vfs.UDisks2VolumeMonitor is not supported Mount(0): Data -> file:///media/ntfs Type: GUnixMount >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> $ rpm -qa | grep -e udisks -e gvfs -e libblockdev gvfs-client-1.51.1-1.fc39.x86_64 gvfs-1.51.1-1.fc39.x86_64 gvfs-mtp-1.51.1-1.fc39.x86_64 gvfs-fuse-1.51.1-1.fc39.x86_64 gvfs-archive-1.51.1-1.fc39.x86_64 gvfs-afc-1.51.1-1.fc39.x86_64 libblockdev-utils-3.0-1.fc39.x86_64 libblockdev-3.0-1.fc39.x86_64 libblockdev-crypto-3.0-1.fc39.x86_64 libblockdev-fs-3.0-1.fc39.x86_64 libblockdev-loop-3.0-1.fc39.x86_64 libblockdev-mdraid-3.0-1.fc39.x86_64 libblockdev-part-3.0-1.fc39.x86_64 libblockdev-swap-3.0-1.fc39.x86_64 libudisks2-2.10.0-1.fc39.x86_64 libblockdev-nvme-3.0-1.fc39.x86_64 udisks2-2.10.0-1.fc39.x86_64 libblockdev-mpath-3.0-1.fc39.x86_64 libblockdev-lvm-3.0-1.fc39.x86_64 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ● udisks2.service - Disk Manager Loaded: loaded (/usr/lib/systemd/system/udisks2.service; disabled; preset: enabled) Drop-In: /usr/lib/systemd/system/service.d └─10-timeout-abort.conf Active: active (running) since Tue 2023-07-04 14:17:24 -02; 5min ago Docs: man:udisks(8) Main PID: 1192 (udisksd) CPU: 15.594s CGroup: /system.slice/udisks2.service └─1192 /usr/libexec/udisks2/udisksd Jul 04 14:17:24 localhost.localdomain udisksd[1192]: Error getting 'loop0' information: Failed to get status of the device loop0: No such device or address (g-bd-loop-error-quark, 1) Jul 04 14:17:24 localhost.localdomain udisksd[1192]: Error getting 'loop1' information: Failed to get status of the device loop1: No such device or address (g-bd-loop-error-quark, 1) Jul 04 14:17:24 localhost.localdomain udisksd[1192]: Error getting 'loop2' information: Failed to get status of the device loop2: No such device or address (g-bd-loop-error-quark, 1) Jul 04 14:17:24 localhost.localdomain udisksd[1192]: Error getting 'loop3' information: Failed to get status of the device loop3: No such device or address (g-bd-loop-error-quark, 1) Jul 04 14:17:24 localhost.localdomain udisksd[1192]: Error getting 'loop4' information: Failed to get status of the device loop4: No such device or address (g-bd-loop-error-quark, 1) Jul 04 14:17:24 localhost.localdomain udisksd[1192]: Error getting 'loop5' information: Failed to get status of the device loop5: No such device or address (g-bd-loop-error-quark, 1) Jul 04 14:17:24 localhost.localdomain udisksd[1192]: Error getting 'loop6' information: Failed to get status of the device loop6: No such device or address (g-bd-loop-error-quark, 1) Jul 04 14:17:24 localhost.localdomain udisksd[1192]: Error getting 'loop7' information: Failed to get status of the device loop7: No such device or address (g-bd-loop-error-quark, 1) Jul 04 14:17:24 localhost.localdomain systemd[1]: Started udisks2.service - Disk Manager. Jul 04 14:17:24 localhost.localdomain udisksd[1192]: Acquired the name org.freedesktop.UDisks2 on the system message bus ~ Note that fdisk -l does not show any loop devices active. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Issue persists after libblockdev-* revisions. $ rpm -qa | grep -e udisks -e gvfs -e libblockdev gvfs-client-1.51.1-1.fc39.x86_64 gvfs-1.51.1-1.fc39.x86_64 gvfs-mtp-1.51.1-1.fc39.x86_64 gvfs-fuse-1.51.1-1.fc39.x86_64 gvfs-archive-1.51.1-1.fc39.x86_64 gvfs-afc-1.51.1-1.fc39.x86_64 libudisks2-2.10.0-1.fc39.x86_64 udisks2-2.10.0-1.fc39.x86_64 libblockdev-utils-3.0.1-1.fc39.x86_64 libblockdev-3.0.1-1.fc39.x86_64 libblockdev-nvme-3.0.1-1.fc39.x86_64 libblockdev-crypto-3.0.1-1.fc39.x86_64 libblockdev-fs-3.0.1-1.fc39.x86_64 libblockdev-loop-3.0.1-1.fc39.x86_64 libblockdev-lvm-3.0.1-1.fc39.x86_64 libblockdev-mdraid-3.0.1-1.fc39.x86_64 libblockdev-mpath-3.0.1-1.fc39.x86_64 libblockdev-part-3.0.1-1.fc39.x86_64 libblockdev-swap-3.0.1-1.fc39.x86_64 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> $ systemctl status udisks2.service ● udisks2.service - Disk Manager Loaded: loaded (/usr/lib/systemd/system/udisks2.service; disabled; preset: enabled) Drop-In: /usr/lib/systemd/system/service.d └─10-timeout-abort.conf Active: active (running) since Thu 2023-07-06 13:37:58 -02; 7min ago Docs: man:udisks(8) Main PID: 1199 (udisksd) CPU: 14.611s CGroup: /system.slice/udisks2.service └─1199 /usr/libexec/udisks2/udisksd Jul 06 13:37:58 localhost.localdomain udisksd[1199]: Error getting 'loop0' information: Failed to get status of the device loop0: No such device or address (g-bd-loop-error> Jul 06 13:37:58 localhost.localdomain udisksd[1199]: Error getting 'loop1' information: Failed to get status of the device loop1: No such device or address (g-bd-loop-error> Jul 06 13:37:58 localhost.localdomain udisksd[1199]: Error getting 'loop2' information: Failed to get status of the device loop2: No such device or address (g-bd-loop-error> Jul 06 13:37:58 localhost.localdomain udisksd[1199]: Error getting 'loop3' information: Failed to get status of the device loop3: No such device or address (g-bd-loop-error> Jul 06 13:37:58 localhost.localdomain udisksd[1199]: Error getting 'loop4' information: Failed to get status of the device loop4: No such device or address (g-bd-loop-error> Jul 06 13:37:58 localhost.localdomain udisksd[1199]: Error getting 'loop5' information: Failed to get status of the device loop5: No such device or address (g-bd-loop-error> Jul 06 13:37:58 localhost.localdomain udisksd[1199]: Error getting 'loop6' information: Failed to get status of the device loop6: No such device or address (g-bd-loop-error> Jul 06 13:37:58 localhost.localdomain udisksd[1199]: Error getting 'loop7' information: Failed to get status of the device loop7: No such device or address (g-bd-loop-error> Jul 06 13:37:58 localhost.localdomain systemd[1]: Started udisks2.service - Disk Manager. Jul 06 13:37:58 localhost.localdomain udisksd[1199]: Acquired the name org.freedesktop.UDisks2 on the system message bus lines 1-21/21 (END)
> (gio mount:14471): GVFS-RemoteVolumeMonitor-WARNING **: 14:27:29.771: remote volume monitor with dbus name org.gtk.vfs.UDisks2VolumeMonitor is not supported That is because the udisks_client_new_sync function returned NULL for some reason.
This issue has now manifested in Debian pre-release.
(In reply to Ondrej Holy from comment #8) > > (gio mount:14471): GVFS-RemoteVolumeMonitor-WARNING **: 14:27:29.771: remote volume monitor with dbus name org.gtk.vfs.UDisks2VolumeMonitor is not supported > > That is because the udisks_client_new_sync function returned NULL for some > reason. Hmm, how do we get more debugging output? The UDisks2 public API hasn't changed in the last release.
One guess might be that udisks2 is slow to start and gvfs-udisks2-volume-monitor hits the timeout on startup, falling back to a local volume monitor only. See e.g. https://github.com/storaged-project/libblockdev/issues/934 In a running desktop session, does running /usr/libexec/gvfs-udisks2-volume-monitor in a terminal fix anything?
In cli neither /usr/libexec/gvfs-udisks2-volume-monitor nor sudo /usr/libexec/gvfs-udisks2-volume-monitor populate volumes to GUI file manager. Cli manual mount functions.
I've just made a scratch build that adds a warning with an error from the udisks_client_new_sync function (https://gitlab.gnome.org/GNOME/gvfs/-/merge_requests/183): https://koji.fedoraproject.org/koji/taskinfo?taskID=103514278 . @publiccontact2020, can you please install packages from that scratch build and test again? You should see "Failed to connect to UDisks:" warning followed by an error message. If it will be "Timeout was reached" then, it is probably caused by https://github.com/storaged-project/libblockdev/issues/934 .
sudo dnf upgrade udisks2 Updating and loading repositories: Repositories loaded. Package Arch Version Repository Size Upgrading: libblockdev x86_64 3.0.1-2.fc39 rawhide 352.6 KiB replacing libblockdev x86_64 2.28-8.fc39 rawhide 302.9 KiB replacing libblockdev-kbd x86_64 2.28-8.fc39 rawhide 35.6 KiB libblockdev-crypto x86_64 3.0.1-2.fc39 rawhide 63.6 KiB replacing libblockdev-crypto x86_64 2.28-8.fc39 rawhide 51.7 KiB libblockdev-fs x86_64 3.0.1-2.fc39 rawhide 108.6 KiB replacing libblockdev-fs x86_64 2.28-8.fc39 rawhide 60.5 KiB libblockdev-loop x86_64 3.0.1-2.fc39 rawhide 23.5 KiB replacing libblockdev-loop x86_64 2.28-8.fc39 rawhide 19.6 KiB libblockdev-lvm x86_64 3.0.1-2.fc39 rawhide 76.3 KiB replacing libblockdev-lvm x86_64 2.28-8.fc39 rawhide 60.3 KiB libblockdev-mdraid x86_64 3.0.1-2.fc39 rawhide 35.7 KiB replacing libblockdev-mdraid x86_64 2.28-8.fc39 rawhide 36.0 KiB libblockdev-mpath x86_64 3.0.1-2.fc39 rawhide 23.3 KiB replacing libblockdev-mpath x86_64 2.28-8.fc39 rawhide 23.6 KiB libblockdev-part x86_64 3.0.1-2.fc39 rawhide 43.4 KiB replacing libblockdev-part x86_64 2.28-8.fc39 rawhide 43.7 KiB libblockdev-swap x86_64 3.0.1-2.fc39 rawhide 23.3 KiB replacing libblockdev-swap x86_64 2.28-8.fc39 rawhide 23.6 KiB libblockdev-utils x86_64 3.0.1-2.fc39 rawhide 43.6 KiB replacing libblockdev-utils x86_64 2.28-8.fc39 rawhide 55.4 KiB libudisks2 x86_64 2.10.0-1.fc39 rawhide 1.1 MiB replacing libudisks2 x86_64 2.9.4-6.fc38 rawhide 1.0 MiB udisks2 x86_64 2.10.0-1.fc39 rawhide 2.7 MiB replacing udisks2 x86_64 2.9.4-6.fc38 rawhide 2.4 MiB Installing dependencies: btrfs-progs x86_64 6.3.2-2.fc39 rawhide 6.0 MiB exfatprogs x86_64 1.2.1-1.fc39 rawhide 239.8 KiB f2fs-tools x86_64 1.16.0-1.fc39 rawhide 598.6 KiB libblockdev-nvme x86_64 3.0.1-2.fc39 rawhide 43.4 KiB libnvme x86_64 1.5-2.fc39 rawhide 248.3 KiB udftools >>>>>>>>>>>>>>>>>>>>>>>> downloaded from repo: https://kojipkgs.fedoraproject.org//work/tasks/4328/103514328/ gvfs-1.51.1-2.test.fc39.x86_64.rpm gvfs-afc-1.51.1-2.test.fc39.x86_64.rpm gvfs-archive-1.51.1-2.test.fc39.x86_64.rpm gvfs-client-1.51.1-2.test.fc39.x86_64.rpm gvfs-fuse-1.51.1-2.test.fc39.x86_64.rpm gvfs-mtp-1.51.1-2.test.fc39.x86_64.rpm $ sudo rpm -Uihv gvfs-* Verifying... ################################# [100%] Preparing... ################################# [100%] Updating / installing... 1:gvfs-client-1.51.1-2.test.fc39 ################################# [ 8%] 2:gvfs-1.51.1-2.test.fc39 ################################# [ 17%] 3:gvfs-afc-1.51.1-2.test.fc39 ################################# [ 25%] 4:gvfs-archive-1.51.1-2.test.fc39 ################################# [ 33%] 5:gvfs-fuse-1.51.1-2.test.fc39 ################################# [ 42%] 6:gvfs-mtp-1.51.1-2.test.fc39 ################################# [ 50%] Cleaning up / removing... 7:gvfs-mtp-1.51.1-2.fc39 ################################# [ 58%] 8:gvfs-archive-1.51.1-2.fc39 ################################# [ 67%] 9:gvfs-afc-1.51.1-2.fc39 ################################# [ 75%] 10:gvfs-fuse-1.51.1-2.fc39 ################################# [ 83%] 11:gvfs-1.51.1-2.fc39 ################################# [ 92%] 12:gvfs-client-1.51.1-2.fc39 ################################# [100%] reboot No change from previous failure to display volumes in GUI file manager. No warnings, no messages. No "Failed to connect to UDisks:" No "Timeout was reached" In cli neither /usr/libexec/gvfs-udisks2-volume-monitor nor sudo /usr/libexec/gvfs-udisks2-volume-monitor populate volumes to GUI file manager. Cli manual filesysem mounting functions. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Additioally note that niether cli execution of: /usr/libexec/gvfs-udisks2-volume-monitor nor sudo /usr/libexec/gvfs-udisks2-volume-monitor appear to conclude when executed in terminal, only flashing cursor with no return to prompt. Additionally note that when commencing system package upgrade, dnf is not excluding udisks2 and dependencies per: sudo dnf upgrade --exclude="udisk2" This has made it is necessary to tediously specify the packages to be upgraded with dnf using cli. Further note that apparently dnf --downloadonly --downloaddir=/path/to/directory no longer function.
(In reply to publiccontact2020 from comment #14) > Additioally note that niether cli execution of: > > /usr/libexec/gvfs-udisks2-volume-monitor > > nor > > sudo /usr/libexec/gvfs-udisks2-volume-monitor > > appear to conclude when executed in terminal, only flashing cursor with no > return to prompt. This should all be running as user within a single desktop session (which is a single d-bus session itself). No sudo or root please, it would only break things. So if the gvfs-udisks2-volume-monitor started without any issue, it should work and running `gio mount -l` in another terminal should list GProxyVolumeMonitorUDisks2 objects. Anyway, can you post `udisksctl dump` please? If there are any sensitive information, you can redact them, but I really need to know what does you storage looks like.
references to specific hardware and volume names redacted gio mount -l Drive(0): Type: GProxyDrive (GProxyVolumeMonitorUDisks2) Volume(0): Type: GProxyVolume (GProxyVolumeMonitorUDisks2) Volume(1): Type: GProxyVolume (GProxyVolumeMonitorUDisks2) Volume(2): Type: GProxyVolume (GProxyVolumeMonitorUDisks2) Volume(3): Type: GProxyVolume (GProxyVolumeMonitorUDisks2) Volume(4): Type: GProxyVolume (GProxyVolumeMonitorUDisks2) Volume(5): Type: GProxyVolume (GProxyVolumeMonitorUDisks2) Volume(6): Type: GProxyVolume (GProxyVolumeMonitorUDisks2) Volume(7): Type: GProxyVolume (GProxyVolumeMonitorUDisks2) Volume(8): Type: GProxyVolume (GProxyVolumeMonitorUDisks2) Volume(9): Type: GProxyVolume (GProxyVolumeMonitorUDisks2) Volume(10): Type: GProxyVolume (GProxyVolumeMonitorUDisks2) Volume(11): Type: GProxyVolume (GProxyVolumeMonitorUDisks2) Volume(12): Type: GProxyVolume (GProxyVolumeMonitorUDisks2) Volume(13): Type: GProxyVolume (GProxyVolumeMonitorUDisks2) Volume(14): Type: GProxyVolume (GProxyVolumeMonitorUDisks2) Volume(15): Type: GProxyVolume (GProxyVolumeMonitorUDisks2) Volume(16): Type: GProxyVolume (GProxyVolumeMonitorUDisks2) Volume(17): Type: GProxyVolume (GProxyVolumeMonitorUDisks2) Volume(18): Type: GProxyVolume (GProxyVolumeMonitorUDisks2) Mount(0): redacted -> file:///xxxx/ntfs Type: GProxyMount (GProxyVolumeMonitorUDisks2) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> from udisksctl dump: /org/freedesktop/UDisks2/Manager: org.freedesktop.UDisks2.Manager: DefaultEncryptionType: luks2 SupportedEncryptionTypes: luks1 luks2 SupportedFilesystems: ext2 ext3 ext4 xfs vfat ntfs f2fs nilfs2 exfat btrfs udf swap Version: 2.10.0 org.freedesktop.UDisks2.Manager.NVMe: HostID: HostNQN: nqn.2014-08.org.nvmexpress:uuid: Since information within the udisksctl dump is private and not intended for web publication, it can be sent to you via email per your email request, but is not for publication to third parties. Note that the information containted in the dump appears to be a routine listing of partitions and hardware.
(In reply to publiccontact2020 from comment #16) > gio mount -l > Drive(0): > Type: GProxyDrive (GProxyVolumeMonitorUDisks2) > Volume(0): > Type: GProxyVolume (GProxyVolumeMonitorUDisks2) > Volume(1): > Type: GProxyVolume (GProxyVolumeMonitorUDisks2) >... Good, so it works. If you restart your file manager, do you see the volumes now? Also, can you verify that you have util-linux-2.39.1-1.fc39 or newer? > Since information within the udisksctl dump is private and not intended for > web publication, it can be sent to you via email per your email request, but > is not for publication to third parties. > > Note that the information containted in the dump appears to be a routine > listing of partitions and hardware. What may appear routine to you might make a big difference.
In reply to comment #17: Restarting the file manager does not display the volumes. Filesystems ext2, ext4, fat32, ntfs are mountable manually but do not appear in Mate filemnager GUI. The storage is serial ATA spinning rust with GPT partitioning. This failure also manifests with PCmanFM filemanager and has crossed distributions into Debian and Gentoo. udisks2 gentoo sys-fs/udisks-2.10.0 https://bugs.gentoo.org/910554 This failure to display volumes has not manifesed prior to the udisks2 updates referenced in comment #14, but apparently has manifested with a number of various problems involving other distros and desktop environments. It would therefore follow that the problem(s) lie within whatever changes were made between udisks2-2.9.4-6.fc38.x86_64 and 2.10.0-1.fc39, including the related dependencies in order to connect to and display volumes within a file manager. Perhaps version 2.10.0-1.fc39 and its dependencies should be withdrawn from the repos until these matters are resolved.
(In reply to publiccontact2020 from comment #18) > This failure also manifests with PCmanFM filemanager and has crossed > distributions into Debian and Gentoo. > > udisks2 gentoo > sys-fs/udisks-2.10.0 > https://bugs.gentoo.org/910554 FYI, tested on my Gentoo box with: sys-fs/udisks-2.10.0 sys-libs/libblockdev-3.0.1 gnome-base/gvfs-1.50.4-r1 mate-base/caja-1.26.1 Everything works properly. This is likely not about a particular distro, rather a specific storage setup. Just made a simple test: $ sudo pkill udisks (this will kill both the udisksd and gvfs-udisks2-volume-monitor) $ /usr/libexec/gvfs-udisks2-volume-monitor (manual restart, will spawn udisksd through d-bus autoactivation) ... and hit F5 in the Caja's Computer window populates proper items reported also by `gio mount -li` If you can't make this work and yet the gio command gives you expected output, the issue seems to be somewhere in the desktop components. Please send me your `udisksctl dump` privately by e-mail, I'll doublecheck.
org.freedesktop.UDisks2.Block: Configuration: [('fstab', {'fsname': <b'UUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX'>, 'dir': <b'/'>, 'type': <b'extx'>, 'opts': <b'defaults'>, 'freq': <1>, 'passno': <1>})]
Storaged service is not running.
Thanks to redhat devs for your attention to this matter. Note that pursuant to comment #4 here: https://bugs.gentoo.org/910554 the revised version of libblockdev and associated packages has satisfactorily resolved the failure to display volumes as referenced in this bug report. [ 1/18] exfatprogs-0:1.2.1-1.fc39.x86_64 100% | 72.7 KiB/s | 87.8 KiB | 00m01s [ 2/18] udftools-0:2.3-6.fc38.x86_64 100% | 116.0 KiB/s | 159.2 KiB | 00m01s [ 3/18] libblockdev-nvme-0:3.0.2-1.fc39.x86_64 100% | 17.2 KiB/s | 25.6 KiB | 00m01s [ 4/18] libnvme-0:1.5-2.fc39.x86_64 100% | 157.4 KiB/s | 92.2 KiB | 00m01s [ 5/18] libblockdev-0:3.0.2-1.fc39.x86_64 100% | 96.2 KiB/s | 92.5 KiB | 00m01s [ 6/18] f2fs-tools-0:1.16.0-1.fc39.x86_64 100% | 176.1 KiB/s | 243.5 KiB | 00m01s [ 7/18] libblockdev-utils-0:3.0.2-1.fc39.x86_64 100% | 68.8 KiB/s | 24.6 KiB | 00m00s [ 8/18] libudisks2-0:2.10.0-1.fc39.x86_64 100% | 53.2 KiB/s | 221.4 KiB | 00m04s [ 9/18] btrfs-progs-0:6.3.2-2.fc39.x86_64 100% | 177.6 KiB/s | 1.2 MiB | 00m07s [10/18] udisks2-0:2.10.0-1.fc39.x86_64 100% | 93.4 KiB/s | 524.5 KiB | 00m06s [11/18] libblockdev-loop-0:3.0.2-1.fc39.x86_64 100% | 15.6 KiB/s | 16.4 KiB | 00m01s [12/18] libblockdev-crypto-0:3.0.2-1.fc39.x86_64 100% | 11.8 KiB/s | 31.1 KiB | 00m03s [13/18] libblockdev-fs-0:3.0.2-1.fc39.x86_64 100% | 32.0 KiB/s | 45.8 KiB | 00m01s [14/18] libblockdev-mdraid-0:3.0.2-1.fc39.x86_64 100% | 46.2 KiB/s | 21.8 KiB | 00m00s [15/18] libblockdev-swap-0:3.0.2-1.fc39.x86_64 100% | 54.2 KiB/s | 16.2 KiB | 00m00s [16/18] libblockdev-part-0:3.0.2-1.fc39.x86_64 100% | 62.0 KiB/s | 24.1 KiB | 00m00s [17/18] libblockdev-mpath-0:3.0.2-1.fc39.x86_64 100% | 51.1 KiB/s | 16.8 KiB | 00m00s [18/18] libblockdev-lvm-0:3.0.2-1.fc39.x86_64