Bug#1040836: [Pkg-utopia-maintainers] Bug#1040836: udisks2: new udisks (auto-)mounts/unmounts fs?
Am 05.08.23 um 22:28 schrieb Christoph Anton Mitterer: Hey. A fix has been merged upstream... well at least a fix for udisk (only). libblockdev might still do that questionable stuff. https://github.com/storaged-project/udisks/commit/60179ee1a364fc8a4b32a45668abd9f75ebf0117 Once you have a working set of commit ids (for both udisks and libblockdev) that fix the issue for you (i.e. you have verified it works), we can pull them into the Debian packages and I'm happy to make the corresponding uploads. Regards, Michael OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1040836: udisks2: new udisks (auto-)mounts/unmounts fs?
Hey. A fix has been merged upstream... well at least a fix for udisk (only). libblockdev might still do that questionable stuff. https://github.com/storaged-project/udisks/commit/60179ee1a364fc8a4b32a45668abd9f75ebf0117 Cheers, Chris.
Bug#1040836: udisks2: new udisks (auto-)mounts/unmounts fs?
On Mon, 2023-07-17 at 07:50 +0200, Michael Biebl wrote: > To me this looks like a BTRFS specific issue (and I don't use BTRFS). If you mean that back and forth renaming, then... well... partially... as I've said, it's not new to me, only that "_unformatted" postfix is new. And that (postfix) seems to have gotten away again with downgrading udisks (though I didn't make super extensive tests now). > I still don't see any mounts in the log, just some probing / scanning > of > the BTRFS devices. And you do have an (unmounted) btrfs device when testing? > Where exactly is the device mounted to / can you actually write to > the > device? I don't know where udisks mounts it, it seems to unmount it right after. > You mentioned it's mounted rw. I deduced that from the changed transid of the btrfs... it wouldn't change if it was mounted only read-only. It seems upstream has some sort of fix, though I'm not sure whether it really drops that behaviour (automatically mounting stuff) in all places. Oh and I had misunderstood their commit message: seems they never did this for ext*/XFS... only for some other filesystems (including btrfs). Cheers, Chris.
Bug#1040836: udisks2: new udisks (auto-)mounts/unmounts fs?
To me this looks like a BTRFS specific issue (and I don't use BTRFS). I still don't see any mounts in the log, just some probing / scanning of the BTRFS devices. Where exactly is the device mounted to / can you actually write to the device? You mentioned it's mounted rw. OpenPGP_signature Description: OpenPGP digital signature
Bug#1040836: udisks2: new udisks (auto-)mounts/unmounts fs?
Hey Michael. I've looked further into this, and it seems to be even worse than originally thought. udisks mounts the fs readable (actually even if it would mount it ro, it might still cause writes to it)... which may easily cause data corruption if a user unplugs a removable device... because there is no reason for him to believe that the fs will be automagically mounted. I'd even say this is a security issue seem my arguing at https://github.com/storaged-project/udisks/issues/1145#issuecomment-1637258668 . Upstream has some commits with respect to that issue... but (purely by the commit message) it would seem to me that they still do this unwarranted mounting for XFS/ext*. Would be great if any fixes, so upstream recognises the issue, could be pulled into Debian ASAP. :-) Also, perhaps you know anything about this: - me, opening LUKS container... Jul 17 03:22:22 heisenberg kernel: BTRFS: device label data-b-1 devid 1 transid 7188 /dev/dm-1 scanned by (udev-worker) (1086718) Jul 17 03:22:22 heisenberg kernel: BTRFS info (device dm-1): using crc32c (crc32c-intel) checksum algorithm Jul 17 03:22:22 heisenberg kernel: BTRFS info (device dm-1): using free space tree - even without any restart, udisks seems to do its foul play and already mount any new device, but that's not the point here Jul 17 03:22:22 heisenberg kernel: BTRFS info: devid 1 device path /dev/mapper/data-b-1_unformatted changed to /dev/dm-1 scanned by (udev-worker) (1086718) Jul 17 03:22:22 heisenberg kernel: BTRFS info: devid 1 device path /dev/dm-1 changed to /dev/mapper/data-b-1 scanned by (udev-worker) (1086718) => do you perhaps know anything about that "_unformatted"?? This seems new to me (and wrong, as there is an fs within the container). Not sure if it's from the udisks upgrade or perhaps the recent udev/system upgrade 254~rc2-3? Looks at least strange. Previously these messages looked like: 2023-06-21T12:58:53.840720+02:00 heisenberg kernel: [ 63.194874] BTRFS info: devid 1 device path /dev/mapper/data-b-1 changed to /dev/dm-0 scanned by (udev-worker) (2282) 2023-06-21T12:58:53.840720+02:00 heisenberg kernel: [ 63.197048] BTRFS info: devid 1 device path /dev/dm-0 changed to /dev/mapper/data-b-1 scanned by (udev-worker) (2282) (i.e. some back and forth renaming) Thanks :-) Chris.
Bug#1040836: [Pkg-utopia-maintainers] Bug#1040836: udisks2: new udisks (auto-)mounts/unmounts fs?
Am 14.07.23 um 13:01 schrieb Christoph Anton Mitterer: Jul 14 12:47:57 heisenberg udisksd[554984]: The function 'bd_crypto_luks_get_metadata_size' called, but not implemented! Jul 14 12:47:57 heisenberg udisksd[554984]: Error getting '/dev/nvme0n1p1' metadata_size: The function 'bd_crypto_luks_get_metadata_size' called, but not implemented! (g-bd-init-error-quark, 1) Jul 14 12:47:57 heisenberg udisksd[554984]: The function 'bd_crypto_luks_get_metadata_size' called, but not implemented! Jul 14 12:47:57 heisenberg udisksd[554984]: Error getting '/dev/nvme0n1p1' metadata_size: The function 'bd_crypto_luks_get_metadata_size' called, but not implemented! (g-bd-init-error-quark, 1) Jul 14 12:47:57 heisenberg udisksd[554984]: The function 'bd_crypto_luks_get_metadata_size' called, but not implemented! Jul 14 12:47:57 heisenberg udisksd[554984]: Error getting '/dev/nvme0n1p1' metadata_size: The function 'bd_crypto_luks_get_metadata_size' called, but not implemented! (g-bd-init-error-quark, 1) Jul 14 12:47:57 heisenberg udisksd[554984]: The function 'bd_crypto_luks_get_metadata_size' called, but not implemented! Jul 14 12:47:57 heisenberg udisksd[554984]: Error getting '/dev/nvme0n1p1' metadata_size: The function 'bd_crypto_luks_get_metadata_size' called, but not implemented! (g-bd-init-error-quark, 1) Jul 14 12:47:57 heisenberg udisksd[554984]: The function 'bd_crypto_luks_get_metadata_size' called, but not implemented! udisks 2.10 no longer uses those symbols as they have been removed from libblockdev in 3.0 See https://github.com/storaged-project/udisks/commit/a04d28cb9e8770823c0b93633c6388a075864131 ~/git/udisks (master)$ grep bd_crypto_luks_get_metadata_size -R OpenPGP_signature Description: OpenPGP digital signature
Bug#1040836: udisks2: new udisks (auto-)mounts/unmounts fs?
Control: forwarded -1 https://github.com/storaged-project/udisks/issues/1145 Hey Michael. On Fri, 2023-07-14 at 08:09 +0200, Michael Biebl wrote: > If udisks is mounting/unmounting a partition, you should get > udisks-Message: 08:06:35.032: Mounted /dev/sdb2 at > /media/michael/Test > on behalf of uid 1000 > udisks-Message: 08:06:41.931: Cleaning up mount point > /media/michael/Test Expansion Drive (device 8:18 is not mounted) > udisks-Message: 08:06:41.940: Unmounted /dev/sdb2 on behalf of uid > 1000 > > > > > Any further ideas? > > Not really. You can ask upstream, maybe? Done. off topic: I also see quite a few of these: Jul 14 12:47:57 heisenberg udisksd[554984]: The function 'bd_crypto_luks_get_metadata_size' called, but not implemented! Jul 14 12:47:57 heisenberg udisksd[554984]: Error getting '/dev/nvme0n1p1' metadata_size: The function 'bd_crypto_luks_get_metadata_size' called, but not implemented! (g-bd-init-error-quark, 1) Jul 14 12:47:57 heisenberg udisksd[554984]: The function 'bd_crypto_luks_get_metadata_size' called, but not implemented! Jul 14 12:47:57 heisenberg udisksd[554984]: Error getting '/dev/nvme0n1p1' metadata_size: The function 'bd_crypto_luks_get_metadata_size' called, but not implemented! (g-bd-init-error-quark, 1) Jul 14 12:47:57 heisenberg udisksd[554984]: The function 'bd_crypto_luks_get_metadata_size' called, but not implemented! Jul 14 12:47:57 heisenberg udisksd[554984]: Error getting '/dev/nvme0n1p1' metadata_size: The function 'bd_crypto_luks_get_metadata_size' called, but not implemented! (g-bd-init-error-quark, 1) Jul 14 12:47:57 heisenberg udisksd[554984]: The function 'bd_crypto_luks_get_metadata_size' called, but not implemented! Jul 14 12:47:57 heisenberg udisksd[554984]: Error getting '/dev/nvme0n1p1' metadata_size: The function 'bd_crypto_luks_get_metadata_size' called, but not implemented! (g-bd-init-error-quark, 1) Jul 14 12:47:57 heisenberg udisksd[554984]: The function 'bd_crypto_luks_get_metadata_size' called, but not implemented! Do you happen to know by chance, whether this is just some noise, or should I report that upstream, too? Thanks, Chris.
Bug#1040836: [Pkg-utopia-maintainers] Bug#1040836: Bug#1040836: udisks2: new udisks (auto-)mounts/unmounts fs?
Am 14.07.23 um 05:33 schrieb Christoph Anton Mitterer: Control: tags -1 - moreinfo On Tue, 2023-07-11 at 14:20 +0200, Michael Biebl wrote: Please provide a debug log of udisksd (run it with --debug) which shows the mount/unmount. Did the following just after the upgrade to 2.10.0-3: In the unit file: ExecStart=/usr/libexec/udisks2/udisksd --debug # systemctl daemon-reload # systemctl restart udisks2.service # ps ax | grep udisksd 505610 ?Ssl0:00 /usr/libexec/udisks2/udisksd --debug Right after restarting it (every time) the kernel shows me: Jul 14 05:26:00 heisenberg kernel: BTRFS: device label system-meta devid 1 transid 16 /dev/nvme0n1p3 scanned by udisksd (505610) Jul 14 05:26:00 heisenberg kernel: BTRFS info (device nvme0n1p3): using crc32c (crc32c-intel) checksum algorithm Jul 14 05:26:00 heisenberg kernel: BTRFS info (device nvme0n1p3): using free space tree Jul 14 05:26:00 heisenberg kernel: BTRFS info (device nvme0n1p3): enabling ssd optimizations Jul 14 05:26:00 heisenberg kernel: BTRFS info (device nvme0n1p3): auto enabling async discard journalctl _SYSTEMD_UNIT=udisks2.service -f gives: Jul 14 05:25:59 heisenberg udisksd[505215]: udisks daemon version 2.10.0 exiting Jul 14 05:25:59 heisenberg udisksd[505610]: udisks daemon version 2.10.0 starting ... Jul 14 05:26:00 heisenberg udisksd[505610]: Acquired the name org.freedesktop.UDisks2 on the system message bus So there are no mounts printed (unless I do the debugging wrong)... but still the kernel gives exactly these messages when manually mounting the fs. If udisks is mounting/unmounting a partition, you should get udisks-Message: 08:06:35.032: Mounted /dev/sdb2 at /media/michael/Test on behalf of uid 1000 udisks-Message: 08:06:41.931: Cleaning up mount point /media/michael/Test Expansion Drive (device 8:18 is not mounted) udisks-Message: 08:06:41.940: Unmounted /dev/sdb2 on behalf of uid 1000 Any further ideas? Not really. You can ask upstream, maybe? OpenPGP_signature Description: OpenPGP digital signature
Bug#1040836: [Pkg-utopia-maintainers] Bug#1040836: udisks2: new udisks (auto-)mounts/unmounts fs?
Control: tags -1 - moreinfo On Tue, 2023-07-11 at 14:20 +0200, Michael Biebl wrote: > Please provide a debug log of udisksd (run it with --debug) which > shows > the mount/unmount. Did the following just after the upgrade to 2.10.0-3: In the unit file: ExecStart=/usr/libexec/udisks2/udisksd --debug # systemctl daemon-reload # systemctl restart udisks2.service # ps ax | grep udisksd 505610 ?Ssl0:00 /usr/libexec/udisks2/udisksd --debug Right after restarting it (every time) the kernel shows me: Jul 14 05:26:00 heisenberg kernel: BTRFS: device label system-meta devid 1 transid 16 /dev/nvme0n1p3 scanned by udisksd (505610) Jul 14 05:26:00 heisenberg kernel: BTRFS info (device nvme0n1p3): using crc32c (crc32c-intel) checksum algorithm Jul 14 05:26:00 heisenberg kernel: BTRFS info (device nvme0n1p3): using free space tree Jul 14 05:26:00 heisenberg kernel: BTRFS info (device nvme0n1p3): enabling ssd optimizations Jul 14 05:26:00 heisenberg kernel: BTRFS info (device nvme0n1p3): auto enabling async discard journalctl _SYSTEMD_UNIT=udisks2.service -f gives: Jul 14 05:25:59 heisenberg udisksd[505215]: udisks daemon version 2.10.0 exiting Jul 14 05:25:59 heisenberg udisksd[505610]: udisks daemon version 2.10.0 starting Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop0' information: Failed to get status of the device loop0: No such device or address (g-bd-loop-error-quark, 1) Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop1' information: Failed to get status of the device loop1: No such device or address (g-bd-loop-error-quark, 1) Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop2' information: Failed to get status of the device loop2: No such device or address (g-bd-loop-error-quark, 1) Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop3' information: Failed to get status of the device loop3: No such device or address (g-bd-loop-error-quark, 1) Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop4' information: Failed to get status of the device loop4: No such device or address (g-bd-loop-error-quark, 1) Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop5' information: Failed to get status of the device loop5: No such device or address (g-bd-loop-error-quark, 1) Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop6' information: Failed to get status of the device loop6: No such device or address (g-bd-loop-error-quark, 1) Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop7' information: Failed to get status of the device loop7: No such device or address (g-bd-loop-error-quark, 1) Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop0' information: Failed to get status of the device loop0: No such device or address (g-bd-loop-error-quark, 1) Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop1' information: Failed to get status of the device loop1: No such device or address (g-bd-loop-error-quark, 1) Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop2' information: Failed to get status of the device loop2: No such device or address (g-bd-loop-error-quark, 1) Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop3' information: Failed to get status of the device loop3: No such device or address (g-bd-loop-error-quark, 1) Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop4' information: Failed to get status of the device loop4: No such device or address (g-bd-loop-error-quark, 1) Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop5' information: Failed to get status of the device loop5: No such device or address (g-bd-loop-error-quark, 1) Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop6' information: Failed to get status of the device loop6: No such device or address (g-bd-loop-error-quark, 1) Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop7' information: Failed to get status of the device loop7: No such device or address (g-bd-loop-error-quark, 1) Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop6' information: Failed to get status of the device loop6: No such device or address (g-bd-loop-error-quark, 1) Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop0' information: Failed to get status of the device loop0: No such device or address (g-bd-loop-error-quark, 1) Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop7' information: Failed to get status of the device loop7: No such device or address (g-bd-loop-error-quark, 1) Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop1' information: Failed to get status of the device loop1: No such device or address (g-bd-loop-error-quark, 1) Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop2' information: Failed to get status of the device loop2: No such device or address (g-bd-loop-error-quark, 1) Jul 14 05:26:00 heisenberg udisksd[505610]:
Bug#1040836: [Pkg-utopia-maintainers] Bug#1040836: udisks2: new udisks (auto-)mounts/unmounts fs?
Control: tags -1 + moreinfo Am 11.07.23 um 13:16 schrieb Christoph Anton Mitterer: Since upgrading to the new udisks I've noted that it seems to auto mount (but then again unmount) a fs: nvme0n1p3 is a small partition with a btrfs on my NVME, that just contains some non-encrypted stuff like SMART logs (for that device) or so. In fstab it's marked as noauto, yet right now after rebooting my kernel logs: Jul 11 13:09:30 heisenberg kernel: BTRFS info (device nvme0n1p3): using crc32c (crc32c-intel) checksum algorithm Jul 11 13:09:30 heisenberg kernel: BTRFS info (device nvme0n1p3): using free space tree Jul 11 13:09:30 heisenberg kernel: BTRFS info (device nvme0n1p3): enabling ssd optimizations Jul 11 13:09:30 heisenberg kernel: BTRFS info (device nvme0n1p3): auto enabling async discard which are the typical messages when a btrfs is mounted. Please provide a debug log of udisksd (run it with --debug) which shows the mount/unmount. OpenPGP_signature Description: OpenPGP digital signature
Bug#1040836: udisks2: new udisks (auto-)mounts/unmounts fs?
Package: udisks2 Version: 2.10.0-3 Severity: normal Hey. Since upgrading to the new udisks I've noted that it seems to auto mount (but then again unmount) a fs: nvme0n1p3 is a small partition with a btrfs on my NVME, that just contains some non-encrypted stuff like SMART logs (for that device) or so. In fstab it's marked as noauto, yet right now after rebooting my kernel logs: Jul 11 13:09:30 heisenberg kernel: BTRFS info (device nvme0n1p3): using crc32c (crc32c-intel) checksum algorithm Jul 11 13:09:30 heisenberg kernel: BTRFS info (device nvme0n1p3): using free space tree Jul 11 13:09:30 heisenberg kernel: BTRFS info (device nvme0n1p3): enabling ssd optimizations Jul 11 13:09:30 heisenberg kernel: BTRFS info (device nvme0n1p3): auto enabling async discard which are the typical messages when a btrfs is mounted. Also, I saw them few minutes before, when upgrading to 2.10.0-3 (from -2). So supicion is that udisks is the "offender". Is this expected? Or would you experts know any good way to debug whether it actually is udisks (or perhaps one of its udef rules or so) who causes that? Thanks, Chris. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.3.0-2-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages udisks2 depends on: ii dbus 1.14.8-1 ii libacl12.3.1-3 ii libatasmart4 0.19-5 ii libblkid1 2.38.1-6 ii libblockdev-crypto33.0.1-1 ii libblockdev-fs33.0.1-1 ii libblockdev-loop3 3.0.1-1 ii libblockdev-mdraid33.0.1-1 ii libblockdev-nvme3 3.0.1-1 ii libblockdev-part3 3.0.1-1 ii libblockdev-swap3 3.0.1-1 ii libblockdev-utils3 3.0.1-1 ii libblockdev3 3.0.1-1 ii libc6 2.37-5 ii libglib2.0-0 2.74.6-2 ii libgudev-1.0-0 237-2 ii libmount1 2.38.1-6 ii libpolkit-agent-1-0122-4 ii libpolkit-gobject-1-0 122-4 ii libsystemd0253.5-1 ii libudisks2-0 2.10.0-3 ii libuuid1 2.38.1-6 ii parted 3.6-3 ii udev 253.5-1 Versions of packages udisks2 recommends: ii dosfstools 4.2-1 ii e2fsprogs 1.47.0-2 ii eject 2.38.1-6 ii exfatprogs 1.2.1-2 ii libpam-systemd 253.5-1 ii ntfs-3g 1:2022.10.3-1+b1 ii polkitd 122-4 Versions of packages udisks2 suggests: ii btrfs-progs6.3.2-1 ii f2fs-tools 1.15.0-1 ii mdadm 4.2+20230508-5 pn nilfs-tools ii reiserfsprogs 1:3.6.27-6 ii udftools 2.3-1 ii udisks2-btrfs 2.10.0-3 ii udisks2-lvm2 2.10.0-3 ii xfsprogs 6.3.0-1 -- no debconf information
