| Summary: | mount returns "unknown filesystem type 'ntfs'" even with ntfs-3g installed | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Simon Kobyda <skobyda> |
| Component: | udisks2 | Assignee: | Tomáš Bžatek <tbzatek> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 34 | CC: | gnome-sig, mpitt, tbzatek, vtrefny |
| Target Milestone: | --- | Keywords: | Regression |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-09-07 08:04:11 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Simon Kobyda
2021-09-06 23:58:06 UTC
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. |