Packages: Usb not mount which kernel 5.4

[9000000]

daemon.err block: No "mount.ntfs" utility available
Sun Aug 16 20:53:57 2020 daemon.err block: mounting /dev/sda1 (ntfs) as /mnt/sda1 failed (25) - Not a tty
Sun Aug 16 21:00:50 20

[Entropy512]

Yeah, I'm seeing this exact issue, and it was broken a few weeks ago I think (I flashed a self-built upgrade 2-3 weeks ago and didn't realize that it broke NTFS automounting).

I'm not sure why LuCi and the automounter are trying to use mount.ntfs, which is not valid for ntfs-3g

[Entropy512]

Aha, LuCi and the automounter used to rely on the patch which @neheb reverted a while ago. I hadn't recompiled for a few months which is why I didn't notice the loss of functionality until recently:

The patch which broke this is likely https://github.com/openwrt/packages/commit/947899823248ce52efd345e3167bb506d8aa4b14, I'm going to try undoing the breakage and retesting.

[neheb]

antfs is available as an alternative.

[Entropy512]

Then the ntfs-3g package should clearly be marked as deprecated and the replacement clearly indicated so that people don't install ntfs-3g and have it not work, or worse, wonder why their drive stopped mounting.

Although digging in - deprecating ntfs-3g in favor of a package with only a single maintainer who is dropping tarballs onto a git repo seems to be a bad idea - https://github.com/klukonin/antfs

I did confirm that the patch in question is what broke the ability to use ntfs-3g with any automounter.

[neheb]

I assume you have ntfs-3g installed. What does /proc/filesystems list?

[neheb]

Interestingly enough, there was a patch that actually fixed this: https://patchwork.ozlabs.org/project/openwrt/patch/[email protected]/

Was never merged.

[9000000]

root@OpenProT:~# cat /proc/filesystems
nodev sysfs
nodev tmpfs
nodev bdev
nodev proc
nodev cgroup
nodev cgroup2
nodev cpuset
nodev debugfs
nodev sockfs
nodev bpf
nodev pipefs
nodev ramfs
nodev devpts
squashfs
nodev jffs2
nodev overlay
nodev mqueue
nodev ubifs
fuseblk
nodev fuse
nodev fusectl
root@OpenProT:~#

[9000000]

Thanks to all of you that I have installed, I had to remove ntfs-3g and install antfs instead

[neheb]

I think you can have both installed. That was the main motivation for removing mount.ntfs from NTFS-3G.

[Entropy512]

I'll take a look at that patch and whether there's a way to clean up the issues (maybe this weekend). It seemed like the final reason for not putting that in was due to the ntfs-3g package adding the line you removed - but the patch you linked would do a better job of avoiding a conflict between antfs and ntfs-3g

[9000000]

@Entropy512 Have you fixed the error yet?
I also encountered some more errors that is if using a USB 3.0 cable will fail as follows

.info kernel: [11477.835903] usb 2-1: new SuperSpeed Gen 1 USB device number 2 using xhci-mtk
Tue Aug 25 11:27:26 2020 kern.info kernel: [11477.868538] scsi host0: uas
Tue Aug 25 11:27:26 2020 kern.err kernel: [11477.873450] xhci-mtk 1e1c0000.xhci: ERROR Transfer event for unknown stream ring slot 1 ep 6
Tue Aug 25 11:27:26 2020 kern.err kernel: [11477.881915] xhci-mtk 1e1c0000.xhci: @000000000f6fa2a0 0de87000 00000000 05000000 01078001
Tue Aug 25 11:27:26 2020 kern.err kernel: [11477.890089] xhci-mtk 1e1c0000.xhci: ERROR Transfer event for unknown stream ring slot 1 ep 2
Tue Aug 25 11:27:26 2020 kern.err kernel: [11477.898500] xhci-mtk 1e1c0000.xhci: @000000000f6fa2b0 0de87100 00000000 05000000 01038001
Tue Aug 25 11:27:46 2020 kern.info kernel: [11498.443802] scsi 0:0:0:0: tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
Tue Aug 25 11:27:46 2020 kern.info kernel: [11498.451380] scsi 0:0:0:0: tag#0 CDB: opcode=0x12 12 00 00 00 24 00
Tue Aug 25 11:27:46 2020 kern.warn kernel: [11498.457732] xhci-mtk 1e1c0000.xhci: Mismatch between completed Set TR Deq Ptr command & xHCI internal state.
Tue Aug 25 11:27:46 2020 kern.warn kernel: [11498.467528] xhci-mtk 1e1c0000.xhci: ep deq seg = 51d32fbd, deq ptr = 658e2bbc
Tue Aug 25 11:27:46 2020 kern.info kernel: [11498.487754] scsi host0: uas_eh_device_reset_handler start
Tue Aug 25 11:27:46 2020 kern.warn kernel: [11498.493240] xhci-mtk 1e1c0000.xhci: Mismatch between completed Set TR Deq Ptr command & xHCI internal state.
Tue Aug 25 11:27:46 2020 kern.warn kernel: [11498.503029] xhci-mtk 1e1c0000.xhci: ep deq seg = d5e3e6a6, deq ptr = 20952cb3
Tue Aug 25 11:27:46 2020 kern.info kernel: [11498.636264] usb 2-1: reset SuperSpeed Gen 1 USB device number 2 using xhci-mtk
Tue Aug 25 11:27:46 2020 kern.info kernel: [11498.661552] scsi host0: uas_eh_device_reset_handler success
Tue Aug 25 11:27:46 2020 kern.err kernel: [11498.667204] xhci-mtk 1e1c0000.xhci: ERROR Transfer event for unknown stream ring slot 1 ep 6
Tue Aug 25 11:27:46 2020 kern.err kernel: [11498.675651] xhci-mtk 1e1c0000.xhci: @000000000f6fa420 0de87200 00000000 05000000 01078001
Tue Aug 25 11:27:46 2020 kern.info kernel: [11498.687773] scsi 0:0:0:0: tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD
Tue Aug 25 11:27:46 2020 kern.info kernel: [11498.695066] scsi 0:0:0:0: tag#0 CDB: opcode=0x0 00 00 00 00 00 00
Tue Aug 25 11:27:46 2020 kern.info kernel: [11498.701250] scsi host0: uas_eh_device_reset_handler start
Tue Aug 25 11:27:46 2020 kern.warn kernel: [11498.706816] xhci-mtk 1e1c0000.xhci: Mismatch between completed Set TR Deq Ptr command & xHCI internal state.
Tue Aug 25 11:27:46 2020 kern.warn kernel: [11498.716651] xhci-mtk 1e1c0000.xhci: ep deq seg = e3bd8e62, deq ptr = 4574fb9d
Tue Aug 25 11:27:47 2020 kern.info kernel: [11498.852305] usb 2-1: reset SuperSpeed Gen 1 USB device number 2 using xhci-mtk
Tue Aug 25 11:27:47 2020 kern.info kernel: [11498.877742] scsi host0: uas_eh_device_reset_handler success
Tue Aug 25 11:27:47 2020 kern.info kernel: [11498.883351] scsi 0:0:0:0: Device offlined - not ready after error recovery

[9000000]

If I use a USB 2.0 cable to connect then everything works fine but read and write speeds are very slow

Tue Aug 25 11:31:02 2020 kern.info kernel: [11694.766914] usb 1-1: new high-speed USB device number 2 using xhci-mtk
Tue Aug 25 11:31:03 2020 kern.info kernel: [11694.925256] scsi host0: uas
Tue Aug 25 11:31:03 2020 kern.notice kernel: [11694.937369] scsi 0:0:0:0: Direct-Access     ST500LM0 12 HN-M500MBB    0    PQ: 0 ANSI: 6
Tue Aug 25 11:31:03 2020 kern.notice kernel: [11694.950139] sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/466 GiB)
Tue Aug 25 11:31:03 2020 kern.notice kernel: [11694.957662] sd 0:0:0:0: [sda] 4096-byte physical blocks
Tue Aug 25 11:31:03 2020 kern.notice kernel: [11694.963447] sd 0:0:0:0: [sda] Write Protect is off
Tue Aug 25 11:31:03 2020 kern.debug kernel: [11694.968284] sd 0:0:0:0: [sda] Mode Sense: 43 00 00 00
Tue Aug 25 11:31:03 2020 kern.notice kernel: [11694.974046] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Tue Aug 25 11:31:03 2020 kern.warn kernel: [11694.983969] sd 0:0:0:0: [sda] Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes)
Tue Aug 25 11:31:03 2020 kern.info kernel: [11695.048895]  sda: sda1
Tue Aug 25 11:31:03 2020 kern.notice kernel: [11695.055288] sd 0:0:0:0: [sda] Attached SCSI disk

[ahmar20]

What is the status of this issue? I rely heavily on my NTFS drive so I need it working.
In my router /etc/filesystems shows ntfs-3g while /proc/filesystems show as above as @9000000.

[neheb]

Try installing antfs.

[neheb]

Going to close this. I will not be fixing this. If you really want to use NTFS-3G, manually create a symlink to mount.ntfs3g like so:

ln -s /sbin/mount.ntfs3g /sbin/mount.ntfs

[Entropy512]

I've manually done that myself, but I disagree with you insisting that users put their data and kernel stability at risk.

The solution you insist on forcing on user:
https://github.com/Sembedded/antfs/commits/master

4 commits in 2 years. Clearly not maintained, clearly not following any development or code review process. Yet you are insisting that users shove this untested and poorly maintained code into kernel space where it can take down the entire system? In addition to putting their data at risk by running a poorly maintained filesystem driver when there are more stable options?

Compare to https://sourceforge.net/p/ntfs-3g/ntfs-3g/ci/903db231ec0078b9b4efab1ed20b6fb63d88eb18/log/?path= - actually actively developed. Also, fundamentally isolated from the rest of the system so the risks of it taking down the entire system are reduced.

[neheb]

@Entropy512 I'm going to push back here.

The last stable release of NTFS-3G was in 2017. It may still be active but there are no stable releases. It's also a fuse driver which means it's slow.

Looking at the git history of that repo is not correct. The actual driver is developed by AVM and is taken from tarballs that they post. It's not an accurate reflection of the development happening. They probably use a private git repo.

Actually, the package in OpenWrt uses the following repo as it has a newer driver: https://github.com/klukonin/antfs

Furthermore, Paragon is submitting their own NTFS driver upstream. Once that happens, AVM's driver can be retired and the Paragon NTFS driver backported.

[Entropy512]

So you're basically saying that you KNOW that the solution you are forcing on users is not suitable for integration directly into the kernel without insulation, since it is not getting integrated by upstream in favor of another approach?

The repo you link has only one more commit, and it's a tarball dump.

They way I read your comment is "The safe way is slow, so let's take the dangerous path."

Also, it appears that Paragon HAS submitted their driver upstream and it was not well received:
https://www.theregister.com/2020/08/18/paragon_tries_to_contribute_ntfs/

[neheb]

That news is inaccurate. That was for the first patchset. It's currently cleaned up to version 5. More versions will follow. That's the typical kernel process. It just takes time. Some stuff like mwlwifi for example (which went to 8 patchset revisions) was abandoned for upstream inclusion by the author.

The AVM NTFS driver was never proposed for upstreaming at kernel.org. It's not as fully featured as the paragon one is. Its origin is also in NTFS-3G, which would make it problematic.

It's also disingenuous to call NTFS-3G safe. A user recently posted a kernel crash that relates to NTFS-3G (the actual crash happens in a fuse_ function).

edit: I misspoke. v6 now.
edit2: looks like the WinBTRFS author is reviewing it. Cool.

[Entropy512]

OK, so maybe this will be OBE in a bit.

But in the meantime, the package description for NTFS-3G should be updated to indicate that it is no longer maintained/considered obsolete by the OpenWRT team, and will not work as expected without manual intervention so people aren't confused when it does nothing after they install it/add it to their build.

I'll submit a pull request to amend the description along those lines when I get more time later this week.