External USB HDD fails to mount with Manjaro 6.1 and 5.x kernels, works fine in Manjaro 4.19 kernel

[Mirdarthos]

@anon58447167

Nothing on both

Now, please provide the output of:

$ pamac search --installed ntfs

Edit:

@soundofthunder

The assumption of NTFS (or FAT/EXFAT) was based on:

That’s more of a presumption.

_{Couldn't resist. Sorry, not sorry.}

[soundofthunder]

@Mirdarthos

That’s more of a presumption.

Rather, assumption, when knowing no Linux filesystem works in Windows (at least not without extra help.)

[anon58447167]

It is known that Windows ignores problems easier. I have no idea what Kernel Mint uses, but perhaps it’s an older one.

I tested with Linux Mint kernel 5.15.0-87 generic.

I also tested multiple times writing and reading from the disk in Windows 10 and Linux Mint and compared the results with the original files with cmp, diff, md5sum - no problems

And it makes sense that it might not work in the newer one, since things change. That’s the way of things, even for humans.

Yes, I understand that even Linux drops backwards compatibility sometimes and that is clearly the issue here. However, with Linux not being closed source etc., I was just wondering maybe there’s still a way to get this backward compatibility back.

[linux-aarhus]

@anon58447167

/dev/sdf1 * 63 312576704 312576642 149G 7 HPFS/NTFS/exFAT

When it is now determined the disk claims to be ntfs/hpfs/exfat formatted

@anon58447167

/dev/sdf1 * 63 312576704 312576642 149G 7 HPFS/NTFS/exFAT

@anon58447167

sudo lsmod | grep --ignore-case ntfs

Nothing on both

This points to ntfs not loaded - so now convince us hat it is in fact ntfs - execute - let us see if FSTYPE yields (column 2)

lsblk -f /dev/sdf1

Then the blacklisting of ntfs3 kernel driver is valid and in this case should be implemented while booting the Manjaro kernel - at least it won’t do any damage.

We don’t know what kernel Linux Mint uses but it is fair to assume it is a conservative approach compared to Manjaro.

Boot into Windows and run a chkdsk command on the device using the /f switch to fix errors.

The Linux kernel is very conservative when it comes to a foreign proprietary filesystem like ntfs - and if the kernel or ntfs-3g driver refuses to mount - you can be sure there is something wrong.

There is nothing wrong with the kernel when it refuses to mount the device - it is the device itself or errors in the filesystem.

If you can mount the device in Mint - try executing and post the output text

stat /your/ntfs/mountpoint

[Mirdarthos]

Was still based on evidence, while assumption isn’t.

[anon58447167]

$ pamac search --installed ntfs

ntfs-3g  2022.10.3-1                                                                                                                                     extra
    NTFS filesystem driver and utilities

[Wollie]

After blacklisting ntfs3 I would regenerate all the initramfs images by

sudo mkinitcpio -P

It also could be required to set the modconf hook in /etc/mkinitcpio.conf.

[soundofthunder]

My take: this could easily be a disk controller incompatibility, which may only be evident under certain circumstances; there have been some flaky implementations in external USB drives over the years. If this is true, then any perceived blame directed at particular kernels, or the disk itself, may simply be attributable to the strawman.

Naturally, it could also be that I’m the strawman, in this instance.

[anon58447167]

lsblk -f /dev/sdf1

NAME FSTYPE FSVER LABEL   UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sdf1 ntfs         ulkonen EAFE768BFE764FB5                      148,8G     0% /media/lihasika/ulkonen

this could easily be a disk controller incompatibility

Yes, that’s my guess too The disk controller is old, and the kernel is new.

[anon58447167]

@Wollie

After blacklisting ntfs3 I would regenerate all the initramfs images by

sudo mkinitcpio -P

It also could be required to set the modconf hook in /etc/mkinitcpio.conf.

OK I tried that (and also checked that modconf was included in the HOOKS-string). No improvement unfortunately…

I can next try to format it as ext4 in Linux Mint, let’s see if it makes any difference…

[linux-aarhus]

I searched for the device id https://sx.nix.dk/search?q=device 14cd:6116 and it seems the device has has repeatedly created issues on Linux going back as far as 2012 with at least one topic in mid 2022.

USB\VID_14CD&PID_6116 - Device KB

The device appears to be an enclosure utilising a sata bridge which may or may not work as expected.

Also a mention at smartmon tools indicating that the enclosure does not work with usbcypress.

https://sourceforge.net/p/smartmontools/mailman/message/28537309/

So this is not a kernel error but a wild goose chase for a solution to a decade old problem with a cheap enclosure

If you had provided more initial information we wouldn’t be here now. All that brainstorming for nothing

https://bugzilla.redhat.com/show_bug.cgi?id=909591

https://bbs.archlinux.org/viewtopic.php?id=152011

Buggy controller has being mentioned more than once and it is likely what is happening - but you probably already knew that - I mean you must have the -d usbcypress from somewhere.

[anon58447167]

Yep, no difference with ext4.

The device appears to be an enclosure utilising a sata bridge which may or may not work as expected.

It works perfectly as expected in Manjaro kernel 4.19, Windows 10, Linux Mint. Tested write and read multiple times with small and big files. Compared the results with diff, cmp, md5sum…

If you had provided more initial information we wouldn’t be here now.

What information is that and where exactly are we now?

I mean you must have the -d usbcypress from somewhere.

Just man smartctl. It was the only device type selection which was able to get the data.

[anon58447167]

Can you please not mark it as resolved, maybe someone else could still know of an actual solution?

[soundofthunder]

A workaround is to continue using the 4.x kernel; however that only serves to delay the inevitable.

There has been sufficient evidence provided to support the stance that a flaky controller is responsible; for working in some circumstances, and others, not. You even agreed with this likely being the cause:

@anon58447167

this could easily be a disk controller incompatibility

Yes, that’s my guess too The disk controller is old, and the kernel is new.

While this clearly isn’t what you want to hear, there’s nothing else to be done; no tricks; no voodoo; no magic spells…

The actual solution is to replace the unit completely.

Cheers.

[anon58447167]

A workaround is to continue using the 4.x kernel; however that only serves to delay the inevitable.

While this clearly isn’t what you want to hear, there’s nothing else to be done; no tricks; no voodoo; no magic spells…

The actual solution is to replace the unit completely.

I just tested the drive in Linux Mint with kernel 6.2.0-35, and of course it works just fine.

So either Linux Mint has some special magic MOJO (which Manjaro can’t have for some reason?) or what you are saying just isn’t true.

[anon58447167]

Guys, please don’t mark using the old linux419 kernel as a solution.

I’ll let you know when I find the proper solution.

edit: OK, here it is! (since the thread was locked)

In Linux 6.1 kernel source there is drivers/usb/storage/unusual_cypress.h which had

UNUSUAL_DEV( 0x14cd, 0x6116, 0x0160, 0x0160,
 		"Super Top",
 		"USB 2.0  SATA BRIDGE",
 		USB_SC_CYP_ATACB, USB_PR_DEVICE, NULL, 0),

Here the 0x0160, 0x0160 refer to minimum and maximum bcdDevice version - mine is 1.50 (shown in the beginning of the dmesg output in the OP).

It seems that the max limit was 9.99 in some older kernels - this caused corruption with “Super Top” devices having bcdDevice >=2.20. For some reason, somewhere along the way, someone changed also the minimum version to 1.60.

Thus, the solution was to create a patch and recompile the kernel; here I set 1.50 as the min/max, though I could’ve left the max as 1.60…

$ cat 0666-lihasika-cypress.patch 
diff --git a/drivers/usb/storage/unusual_cypress.h b/drivers/usb/storage/unusual_cypress.h
index 0547daf..7b3d5f0 100644
--- a/drivers/usb/storage/unusual_cypress.h
+++ b/drivers/usb/storage/unusual_cypress.h
@@ -19,7 +19,7 @@ UNUSUAL_DEV(  0x04b4, 0x6831, 0x0000, 0x9999,
 		"Cypress ISD-300LP",
 		USB_SC_CYP_ATACB, USB_PR_DEVICE, NULL, 0),
 
-UNUSUAL_DEV( 0x14cd, 0x6116, 0x0160, 0x0160,
+UNUSUAL_DEV( 0x14cd, 0x6116, 0x0150, 0x0150,
 		"Super Top",
 		"USB 2.0  SATA BRIDGE",
 		USB_SC_CYP_ATACB, USB_PR_DEVICE, NULL, 0),

Then I just followed the instructions in Kernel/Arch build system - ArchWiki -

• having a 12-thread capable CPU, I set MAKEFLAGS="-j10" in /etc/makepkg.conf
• instead pkgctl I used git clone https://gitlab.manjaro.org/packages/core/linux61 to get the package build source
• then build, install, reboot:

→ Now the old “Super Top” USB controller (and WD HDD) works great in my new Linux 6.1.59-1-MANJARO kernel

[Wollie]

@anon58447167

Guys, please don’t mark using the old linux419 kernel as a solution.

For what reason using kernel 4.19 is not working for you?

It’s common practice to choose the right kernel for the hardware in place, it does not help at all to say it’s working on other kernels in other distro, people here are firm in Manjaro and very few might be willing to check differences to other distros. You can either stick to kernel 4.19, replace the controller or choose another distro.

[anon58447167]

For what reason using kernel 4.19 is not working for you?

Well, I guess first and foremost: X wouldn’t start on that kernel. Maybe it’s an easy fix, but I’d rather get the HDD working on the newer kernel.

Also I need kernel >=5.14 for nvtop (for radeon)

people here are firm in Manjaro and very few might be willing to check differences to other distros. You can either stick to kernel 4.19, replace the controller or choose another distro.

Yes, no problem - I do understand people are volunteers here.

I can probably fix this myself, I was just wondering if someone already knew of a solution. It would be nice of people to admit that you don’t know, instead of doubling down on spreading misinformation - that’s just wasting everyone’s time.

[anon58447167]

I understand the frustration, however, perhaps the OP could refrain from misdirected sarcasm when the intention here, is only to help:

Dude,

You don’t get to decide what is relevant and what is not …

If you had provided more initial information we wouldn’t be here now. All that brainstorming for nothing

what this guy said is just plain rude and childish, my response was quite mild.

I’m not sure what initial information was missing, since he didn’t respond when I asked. I guess it might have been the USB device ids etc., which are visible right in the opening post’s dmesg output. So it seems that instead of actually reading the opening post, there was a knee-jerk reaction against me sanitizing the inxi output.

[soundofthunder]

@anon58447167

Dude,
what this guy said is just plain rude and childish, my response was quite mild.

I’m not sure what initial information was missing, since he didn’t respond when I asked. I guess it might have been the USB device ids etc., which are visible right in the opening post’s dmesg output. So it seems that instead of actually reading the opening post, there was a knee-jerk reaction against me sanitizing the inxi output.

Thank you for your comments.