Hide Forgot
Description of problem: During image of refresh of newest fedora testing image, our tests caught a regression. When "udisksctl mount -b /dev/dm-0" returns "unknown filesystem type 'ntfs'" even when is ntfs-3g installed. Version-Release number of selected component (if applicable): udisks2-2.9.3-1.fc34.x86_64 ntfs-3g-libs-2021.8.22-1.fc34.x86_64 OS: Fedora 34 (Cloud Edition) 5.13.13-200.fc34.x86_64 How reproducible: Steps to Reproduce: On a fresh machine, run: 1. vgcreate TEST /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_DISK1 2. lvcreate TEST -n vol -L 200m 3. mkfs -t ntfs /dev/dm-0 4. udisksctl mount -b /dev/dm-0 Actual results: Device is mounted successfully Expected results: The last command returns an error: Error mounting /dev/dm-0: GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error mounting /dev/dm-0 at /run/media/root/28934C0E5A577BDB: unknown filesystem type 'ntfs' Additional info: Logs from our test image where regression was caught (if that is helpful): https://logs.cockpit-project.org/logs/pull-2380-20210903-022942-5c7da963-fedora-testing-cockpit-project-cockpit/TestStorageResize-testResizeNtfs-fedora-testing-127.0.0.2-2701-FAIL.log.gz
Our guess is it's either caused by an update of udisks2 package or ntfs-3g package.
Here is also our image build where updates of udisks2 and ntfs-3g package can be seen: https://logs.cockpit-project.org/logs/image-refresh-2380-20210903-020808/log
Ahhh, I see I switched "Actual results" and "Expected results" in my bug report. Properly it's supposed to be: Actual results: The last command returns an error: Error mounting /dev/dm-0: GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error mounting /dev/dm-0 at /run/media/root/28934C0E5A577BDB: unknown filesystem type 'ntfs' Expected results: Device is mounted successfully
This happened in our CI during Fedora 34 image refresh (https://github.com/cockpit-project/bots/pull/2380) . The full set of package changes: Removed: ntfs-3g (2:2017.3.23-15.fc34) ntfs-3g-system-compression (1.0-5.fc34) Added: ntfs-3g-libs (2:2021.8.22-1.fc34) Changed: alsa-lib (1.2.5.1-1.fc34 -> 1.2.5.1-2.fc34) cracklib (2.9.6-25.fc34 -> 2.9.6-27.fc34) cracklib-dicts (2.9.6-25.fc34 -> 2.9.6-27.fc34) efi-srpm-macros (5-2.fc34 -> 5-4.fc34) hwdata (0.350-1.fc34 -> 0.351-1.fc34) libtpms (0.8.4-2.20210624gita594c4692a.fc34.0 -> 0.8.5-0.20210901git18ba4c0206.fc34.0) netcat (1.217-3.fc34 -> 1.218-1.fc34) nftables (1:0.9.8-2.fc34 -> 1:0.9.8-3.fc34) ntfsprogs (2:2017.3.23-15.fc34 -> 2:2021.8.22-1.fc34) perl-Digest (1.19-2.fc34 -> 1.20-1.fc34) podman (3:3.3.0-1.fc34 -> 3:3.3.1-1.fc34) podman-gvproxy (3:3.3.0-1.fc34 -> 3:3.3.1-1.fc34) podman-plugins (3:3.3.0-1.fc34 -> 3:3.3.1-1.fc34) python-unversioned-command (3.9.6-2.fc34 -> 3.9.7-1.fc34) python3 (3.9.6-2.fc34 -> 3.9.7-1.fc34) python3-libs (3.9.6-2.fc34 -> 3.9.7-1.fc34) python3-nftables (1:0.9.8-2.fc34 -> 1:0.9.8-3.fc34) strace (5.13-1.fc34 -> 5.14-1.fc34) vim-minimal (2:8.2.3367-1.fc34 -> 2:8.2.3391-1.fc34) So it was *not* an udisks change, but this rather big restructuring of ntfs-3g. It may still be that udisks needs to be adjusted to some changed ntfs-3g API of course -- but until then, this is a regression.
I reported the ntfs-3g (possible) packaging issue as a separate bug here, because I currently cannot install ntfs-3g on Fedora 34: https://bugzilla.redhat.com/show_bug.cgi?id=2001755 If I install the latest ntfs-3g manually, I can mount a NTFS filesystem with udisksctl so I don't think we need to change UDisks, but cockpit test suite probably needs a change -- UDisks doesn't depend on ntfs-3g and in general we do not depend on kernel or FUSE modules needed for mounting, we bring in ntfs-3g through ntfsprogs now, but with the latest ntfs-3g ntfsprogs depend only on the ntfs-3g-libs subpackage so UDisks doesn't (indirectly) depend on ntfs-3g from now on and you should add it as a cockpit test dependency. (I guess we could make exception for NTFS and add the explicit dependency in UDisks if we agree UDisks is the best place to do it.)
I see, thanks Voytech! I'll try that.
Closing for now -- I'll reopen if it still fails with ntfs-3g installed.
Apparently "ntfs-3g" is an alias now for ntfs-3g-libs, I can't actually install "ntfs-3g". That is exactly what Vojtech reported as bug 2001755. More confusingly, `mkfs -F -t ntfs /dev/sda` succeeds and creates an ext2(!!) file system. It just writes a warwning, which is easy to miss: # modprobe scsi_debug dev_size_mb=100 # mkfs -F -t ntfs /dev/sda mke2fs 1.45.6 (20-Mar-2020) Your mke2fs.conf file does not define the ntfs filesystem type. Creating filesystem with 102400 1k blocks and 25688 inodes Filesystem UUID: c81b6e3e-4dfe-4d35-863a-b3542fa16ec4 Superblock backups stored on blocks: 8193, 24577, 40961, 57345, 73729 Allocating group tables: done Writing inode tables: done Writing superblocks and filesystem accounting information: done It works with this: # mkntfs --force /dev/sda But `udisksctl mount -b /dev/sda` still fails. After the `dnf install ntfs-3g-2:2021.8.22-1.fc34.x86_64` hack it finally works. So I confirm that bug 2001755 is indeed the root cause, and we can keep this closed.
Uhm. On slightly unrelated note, have a look at https://github.com/storaged-project/udisks/issues/798. Once kernel 5.15 hits Fedora, we'll be ready on the UDisks side. That would make any spec file changes and ntfs-3g dependencies pointless.