External HDD mount read-write problem

[Steijn van Essen]

Hello community,

My RPi 3 B+ has a fresh OS install (Raspbian Stretch Lite 2018-11-13). While I'm building myself a NAS I added Samba, NFS (server + client) and mini DLNA. I also added a number of scripts I will use to RSync the data on the external HDD with my other (Debian Linux / Intel based) NASses. Now it was time to hook up my external, USB attached, harddisk to start testing my configuration. Once attached I created one logical partition on it (/dev/sda5) which takes all the available disk space and formatted it as ext4 (just as on my other NASses).

Since this NAS is exclusively meant to support my mediabox I hook my RPi directly into a USB port on the mediabox for power (using a micro USB to USB A cable). I connect my external HDD case to an USB port of the RPi (for data) and to a second USB port on the mediabox (for power) using a Y cable (micro-USB 3.0 to 2 x USB A. In doing so the RPi and ext HDD will boot whenever I start up my mediabox.

Unfortunately I can't get my HDD's data partition mounted RW (read-write). After a day of troubleshooting I discovered that it falls back to RO (read only) within a few seconds after getting mounted. No matter if I mount it through /etc/fstab, /etc/local.rc (at bootup or later, using the 'at' command/package) or manually. Also mounting by devname (/dev/sda5) or UUID makes no difference: I see it mounted RW for a couple of seconds and then fall back to RO.

Having searched through this forum (in the Troubleshooting section) I encountered few posts that were closely related to my problem. But it gave me some ideas, so one thing I tried was using a (Digitus) 4-port USB 3.0 hub to deliver power to my RPi and ext HDD. To no effect.

My HDD is a Western Digital Blue WD20SPZX 2.5" 2 TB (very mainstream I should think); my HDD enclosure is a LogiLink UA0256 (converting SATA3 to USB 3.0).

My questions:
1) Is Raspbian picky when it comes to external HDD enclosures (i.e. the controllers that run in them)?
2) Is there a way to get more information on the reason for switching from RW to RO (f.e. in log files, through debug options or through commands)?
3) Are there other ext HDD enclosures that can be recommended to me for the RPi 3 B and B+?
4) Does anybody have experience with using the Geekworm Raspberry Pi X820 Enclosure and corresponding X820 SATA-to-USB expansion board?

Ad 4 seems a fancy solution: a case that houses both an RPi and an SATA HDD (or SSD) and comes with its own SATA controller board and built-in fan to cool the RPi's CPU.

Looking forward to your reaction,
With regards,

Steijn van Essen

From i8088 to i7-980X in 25 years and still waiting …

[thagrol]

My questions:
1) Is Raspbian picky when it comes to external HDD enclosures (i.e. the controllers that run in them)?

Possibly, I don't knowfor sure.

2) Is there a way to get more information on the reason for switching from RW to RO (f.e. in log files, through debug options or through commands)?

Try

dmesg

3) Are there other ext HDD enclosures that can be recommended to me for the RPi 3 B and B+?
4) Does anybody have experience with using the Geekworm Raspberry Pi X820 Enclosure and corresponding X820 SATA-to-USB expansion board?

I've nothing to suggest on these last two.

What filesystem has been used on your external HDD? If it's ntfs, have you installed ntfs-3g?

[Duckey]

I have been using the Geekworm X820 enclosure and board for several months on my NAS with a 1TB SSD as the boot device. It has worked VERY well. It's not the least expensive way to hood the SSD to a RPi 3B+, but it boots reliably every time. It took a little work to get get up, but you can blame that on the operator, not the device.

I (probably just me), found that the use of a HDD was a little slow on the boot cycle. I went with the SSD so that the boot sequence timing would not be affected by drive latency and spin up time.

[RaTTuS]

....
Since this NAS is exclusively meant to support my mediabox I hook my RPi directly into a USB port on the mediabox for power (using a micro USB to USB A cable). I connect my external HDD case to an USB port of the RPi (for data) and to a second USB port on the mediabox (for power) using a Y cable (micro-USB 3.0 to 2 x USB A. In doing so the RPi and ext HDD will boot whenever I start up my mediabox.....

you media box will probably not be able to supply enough amps for this

[Steijn van Essen]

Hello community,

Thanks for your reactions. Here's my reaction:

@thagrol:

Ad 2: I did some reading on (the role of) dmseg and I will see what it will give back to me if I run some controlled testscenarios. I will get back on that (later, for The Netherlands are suffering from tropical weather conditions at the moment, last night being the hottest night ever).

Ad 1,3,4: Thanks anyway.

Ad filesystem: Taken from an old PuTTY log (I always save my logging):

Before repartitioning and formatting the HDD, fdisk -l showed:

Code: Select all

Disk /dev/sda: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xbe741af1

Device     Boot Start        End    Sectors  Size Id Type
/dev/sda1        2048 3907026943 3907024896  1.8T  7 HPFS/NTFS/exFAT

After repartitioning the HDD, fdisk -l showed:

Code: Select all

<output omitted>
Disklabel type: dos
Disk identifier: 0xbe741af1

Device     Boot Start        End    Sectors  Size Id Type
/dev/sda1        2048 3907029167 3907027120  1.8T  5 Extended
/dev/sda5        4096 3907029167 3907025072  1.8T 83 Linux

Formatting the data partition completed the task:

Code: Select all

mkfs.ext4 /dev/sda5
mke2fs 1.43.4 (31-Jan-2017)
Creating filesystem with 488378134 4k blocks and 122101760 inodes
Filesystem UUID: 1d6a4400-7798-4303-9750-f6172380baeb
<output omitted>
done
Writing superblocks and filesystem accounting information:  0/14905  126/14905  done

@Duckey:

Thx for sharing your experience with X820. I take it you still boot Raspbian from micro SSD card and mount the external SSD as a second device?
In case you do, I can tell you that booting my Pi to the point that I can ping it and start SSH to it takes 12 seconds. By the time I've completed login I see my HDD (partition) already mounted.
With less than 15 seconds to login prompt I see no need to switch from HDD to SSD.

@RaTTuS:

"you media box will probably not be able to supply enough amps for this"

Maybe (I'll keep it in mind), but since I already replaced my mediabox by a USB 3.0 hub for power supply and this didn't change any results, this is IMO less likely. Also because the RPi never fails to mount my HDD, it only fails to mount it read-write.
By the way: considering the spelling of your (nick)name: are you a PuTTY fan too?!

OK I have some work to do. I'll be back to you.

Thanks again,

[Steijn van Essen]

Hello community,

Here's what I did (testing):

1) Disconnect external HDD from RPi 3 B+
2) Power up RPi, login (as 'pi') and 'sudo dmesg > dmesg_0.log'

I have briefly logged into the log and saw nothing disturbing (must say I'm not very familiar with this kind of logs; this part of the log available at your request)

3) Plugged in the ext HDD (both to power source and RPi using USB 3.0 Y cable)
3) Mounted the data partition shortly hereafter with:

Code: Select all

sudo mount -o rw,errors=remount-ro -t ext4 -U 1d6a4400-7798-4303-9750-f6172380baeb /mnt/Media

Here's the result from 'sudo dmesg > dmesg_1.log' (skipping the 'dmesg_0' part):

Code: Select all

[  528.313638] Under-voltage detected! (0x00050005)
[  530.923633] usb 1-1.1.3: new high-speed USB device number 5 using dwc_otg
[  531.124924] usb 1-1.1.3: New USB device found, idVendor=152d, idProduct=0567
[  531.124937] usb 1-1.1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  531.124946] usb 1-1.1.3: Product: USB 3.0 Device
[  531.124954] usb 1-1.1.3: Manufacturer: USB 3.0 Device
[  531.124962] usb 1-1.1.3: SerialNumber: 00000000C38F
[  531.126085] usb-storage 1-1.1.3:1.0: USB Mass Storage device detected
[  531.131324] scsi host0: usb-storage 1-1.1.3:1.0
[  532.154416] scsi 0:0:0:0: Direct-Access     WDC WD20 SPZX-00CRAT0     0117 PQ: 0 ANSI: 6
[  532.156166] sd 0:0:0:0: [sda] 3907029168 512-byte logical blocks: (2.00 TB/1.82 TiB)
[  532.156672] sd 0:0:0:0: [sda] Write Protect is off
[  532.156697] sd 0:0:0:0: [sda] Mode Sense: 47 00 10 08
[  532.157161] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA
[  532.173090] sd 0:0:0:0: Attached scsi generic sg0 type 0
[  532.284577]  sda: sda1 < sda5 >
[  532.287065] sd 0:0:0:0: [sda] Attached SCSI disk
[  532.473730] Voltage normalised (0x00000000)
[  618.563967] JBD2: Clearing recovery information on journal
[  618.569788] sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
[  618.569805] sd 0:0:0:0: [sda] tag#0 Sense Key : 0x5 [current] 
[  618.569816] sd 0:0:0:0: [sda] tag#0 ASC=0x24 ASCQ=0x0 
[  618.569831] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x2a 2a 08 74 44 10 00 00 00 08 00
[  618.569842] print_req_error: critical target error, dev sda, sector 1950617600
[  618.569853] Buffer I/O error on dev sda5, logical block 243826688, lost sync page write
[  618.569887] JBD2: Error -5 detected when updating journal superblock for sda5-8.
[  618.604181] sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
[  618.604199] sd 0:0:0:0: [sda] tag#0 Sense Key : 0x5 [current] 
[  618.604211] sd 0:0:0:0: [sda] tag#0 ASC=0x24 ASCQ=0x0 
[  618.604226] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x2a 2a 08 00 00 10 00 00 00 08 00
[  618.604236] print_req_error: critical target error, dev sda, sector 4096
[  618.604248] Buffer I/O error on dev sda5, logical block 0, lost sync page write
[  618.874016] EXT4-fs (sda5): mounted filesystem with ordered data mode. Opts: errors=remount-ro
[  626.353301] sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
[  626.353335] sd 0:0:0:0: [sda] tag#0 Sense Key : 0x5 [current] 
[  626.353351] sd 0:0:0:0: [sda] tag#0 ASC=0x24 ASCQ=0x0 
[  626.353369] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x2a 2a 08 74 44 10 18 00 00 08 00
[  626.353384] print_req_error: critical target error, dev sda, sector 1950617624
[  626.353402] print_req_error: critical target error, dev sda, sector 1950617624
[  626.353619] Aborting journal on device sda5-8.
[  626.354440] sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
[  626.354455] sd 0:0:0:0: [sda] tag#0 Sense Key : 0x5 [current] 
[  626.354467] sd 0:0:0:0: [sda] tag#0 ASC=0x24 ASCQ=0x0 
[  626.354481] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x2a 2a 08 74 44 10 00 00 00 08 00
[  626.354490] print_req_error: critical target error, dev sda, sector 1950617600
[  626.354503] Buffer I/O error on dev sda5, logical block 243826688, lost sync page write
[  626.354724] JBD2: Error -5 detected when updating journal superblock for sda5-8.
[  628.794454] EXT4-fs (sda5): previous I/O error to superblock detected
[  628.795216] sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
[  628.795231] sd 0:0:0:0: [sda] tag#0 Sense Key : 0x5 [current] 
[  628.795243] sd 0:0:0:0: [sda] tag#0 ASC=0x24 ASCQ=0x0 
[  628.795258] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x2a 2a 08 00 00 10 00 00 00 08 00
[  628.795268] print_req_error: critical target error, dev sda, sector 4096
[  628.795286] Buffer I/O error on dev sda5, logical block 0, lost sync page write
[  628.795338] EXT4-fs error (device sda5): ext4_journal_check_start:61: Detected aborted journal
[  628.797814] EXT4-fs (sda5): Remounting filesystem read-only
[  628.799146] EXT4-fs (sda5): previous I/O error to superblock detected
[  628.799860] sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
[  628.799878] sd 0:0:0:0: [sda] tag#0 Sense Key : 0x5 [current] 
[  628.799889] sd 0:0:0:0: [sda] tag#0 ASC=0x24 ASCQ=0x0 
[  628.799903] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x2a 2a 08 00 00 10 00 00 00 08 00
[  628.799912] print_req_error: critical target error, dev sda, sector 4096
[  628.799929] Buffer I/O error on dev sda5, logical block 0, lost sync page write

My questions:

5) As I see it, in the first four seconds the ext HDD spins up, requesting (too much) power from RPi.
Eventually getting it from the USB 3.0 hub (as power supply at the second end of the USB Y cable).
"Voltage normalised", does this indicate that everybody (ext HDD and RPi) is happy now (powerwise)?
6) 50 seconds after start of HDD spin up I manually execute the mount command, which seems to trigger some I/O to/from the ext HDD. Am I right? And if so, is this just control I/O, or also data I/O?
7) 10 seconds after 'mount' I see 'Remounting filesystem read-only'. Could anyone tell me why this happens?
8) How could I solve (or further analyse) this situation (can't imagine that moving from MBR to GPT will help)?

[Ernst]

What happens when you use the official power supply with the HDD plugged directly into the Pi ?
The cause of your problems is that you are ignoring USB power limitations.

[Steijn van Essen]

@Ernst:

I have an original RPi power supply around, but I'm not very optimistic about the results: why would writing to the HDD take more power than reading from it? But I'll try: How exactly should I wire up my gear?

Like this (I): RPi power ---> RPi mobo ---> ext HDD
Or this: RPi power ---> RPi mobo ---> ext HDD <--- ext power supply (*)

(*) Know that my ext HDD doesn't come with a power adaptor (and has no power inlet, not unusual for a 2,5" case), so in this scenario I use an USB Y cable that I plug both in the RPi and USB 3.0 hub

[rpdom]

why would writing to the HDD take more power than reading from it?

That should be obvious. To read the disk it just has to get the current magnetic status of each bit and confirm it with the checksums. To write it it has to modify those bits and checksum using a focused magnetic field and often with modern disks a heating element. That takes power.

[Ernst]

@Ernst:
How exactly should I wire up my gear?

Like this (I): RPi power ---> RPi mobo ---> ext HDD

According to the specifications the HDD consumes up to 1A. (https://www.wd.com/content/dam/wdc/webs ... 771437.pdf)
The typical active current consumption of the Pi 3B+ is 500mA and can deliver 1.2A on the USB sockets
The max amount of power under stress of the Pi 3B is 1.34A (3B+ most likely more)
The bold above shows what the PSU has to deliver if fully loaded, this is why the PSU is rated at 2.5A
https://www.raspberrypi.org/documentation/faqs/

Now take a look at the USB figures: (https://en.wikipedia.org/wiki/USB)

Max. current
0.5 A (USB 2.0)
0.9 A (USB 3.0)
1.5 A (BC 1.2)
3 A (USB-C)

If you try to power a Pi from an USB socket on your mediabox you can (theoretically) only expect 0.5A (USB2) or 0.9A (USB 3).
A Y-Cable does not help because theoretically! the maximum (USB2) would be just enough to power your HDD.
https://www.howtogeek.com/238683/are-th ... l-devices/

You previous experiments show two power problems:
1) The voltage to the Pi drops giving undervoltage warning
2) The HDD has a similar problem resulting in IO errors

What you should do is put your ear on the HDD and listen to the head movements, if you hear clickety-click or varying speed (spinning up/down) then there is a power supply problem to the HDD.

[LTolledo]

From another RPi NAS enthusiast

2.5" HDD tested/used/currently using:
1. seagate barracuda 2TB (NTFS format)
2. seagate firecuda 2Tb (NTFS format
3. seagate barracuda 4TB (15mm thick, EXT4 format)
4. western digital 4TB (also 15mm thick, EXT4 format)
5. marshall 1TB (NTFS format)

as you may have noticed, the 15mm thick 4TB wont fit any 2.5" HDD case as those were designed for up to 12mm thick HDDs
also tested other pre-made drives, used previously in a winpc, none failed so far as data drive

enclosures that I've used successfully (as data drive none failed actually, some failed as boot drive interface)
1. Orico Clear case (JMicron chipset)
2. Orico black case (JMicron chipset)

even my old 2.5" HDD PATA enclosure work (using Alcor Micro Corp USB 2.0-IDE bridge)
just tried it again a while ago

abandoned the use of HDD case, I tested and now use SATA to USB3.0 adapters
1. Eluteng Black (the original Eluteng Black)[ ASM1051E/ASM1153 chipset]
2. Eluteng Blue ELT-STAU1-U3--V2-BK-SNL [ASM1053E/ASM1153 chipset]
3. Inateck UA1003 [ASM1051E/ASM1153 chipset]
4. Sabrent EC-SSHD [JMicron chipset]
5. Moyagoa JP-MY-U3-SATA-BK i][ASM1051E/ASM1153 chipset][/i]

as I like the LED indicators on the Eluteng Blue, its the one that I use in all my NAS installations.

"read-only problem" I have encountered a lot on NTFS formatted HDDs, that is, if I forgot to install ntfs-3g during my install phase.
never had read-only problem (yet) on EXT4 formatted HDDs.

have tested a number of self powered 3.5" HDD drives and enclosures as well, mostly as data drives, but tested one "old HDD enclosure" as boot drive which worked provided you turn on the HDD enclosure power prior to powering the RPi.

just to add my RPi NAS specs are:
Raspberry Pi 2 Model B v 1.2 running Raspbian Stretch Lite, booted from 8GB class 10 microSD
powered by 5v 3.0A PSU
network connection via USB to GbE Adapter
with data drive of seagate 4TB 2.5" HDD connected via Eluteng Blue SATA to USB 3.0 adapter

prior to upgrade, this was how my RPi NAS looked:

RPi2B_HDD_rack.jpg (233.06 KiB) Viewed 1527 times

[Steijn van Essen]

@rpdom:

OK, maybe I underestimated ext HDD R/W-activity power consumption.
I had no trouble with this combi (WD 2.5" 2 TB HDD in a LogiLink UA0256 case) hooking it up to my Windows 10 desktop but I recall having issues with it hooked directly into my mediabox. The latter being one of the reasons to insert an RPi in between. FYI: other reasons for inserting the RPi concern flexibility, f.e. including the use of RSync for transfering media files, not supported by the mediabox.

@Ernst:

The datasheet of my USB 3.0 hub (Digitus DA-70231) tells me its power supply is 5V/3.5A. So I see no limitations on supporting both the RPi and the ext HDD. But then the question remains, of course, where comes the RPi's dmesg "Under-voltage detected!" message from?! And will it go away when I retrieve ext HDD power solely from the RPi?!
I recall hearing "clickety-click / varying speed" the other week, before deciding to replace the straight USB data cable by a Y cable.

Anyway, to make sure we don't miss something I'll test either scenario (I and II) and come back to you (later).
In the meantime, having learned some things about RPi, USB and power supply, I'll add my fancy avatar to my profile (which might suggest I'm a technician, which I'm not, being more of a drawing board guy).

@LTolledo,

I just finished this reply when I saw your post coming in. I see useful stuff in there but will take some more time to digest it. Thx for now!

Thanks once again,

[Ernst]

The datasheet of my USB 3.0 hub (Digitus DA-70231) tells me its power supply is 5V/3.5A. So I see no limitations on supporting both the RPi and the ext HDD.

This is where you go wrong.

https://www.digitus.info/en/products/co ... /da-70231/

The hub has 4xUSB3 ports, the maximum per USB specification is 0.9A per port, not 3.5A if only one port is used.

See table 2 operating modes http://www.ti.com/lit/ug/tidu614/tidu614.pdf

[LTolledo]

this is how it looks now

RPi2B_NAS_v3.0.jpg (198.74 KiB) Viewed 1516 times

[Steijn van Essen]

Hi everybody,

These are the scenarios I executed for testing, using the original RPi power supply (wall outlet) and inspired by @thagrol, @RaTTuS, @Ernst and @rpdom.
Before I start I power up my RPi 3 B+ with it. I also start up my USB 3.0 hub with its own power supply (wall outlet).

Scenario IA RPi power ---> RPi mobo <---> ext HDD

1) Plug HDD into RPi using only the data leg of the USB Y cable
2) Listen for strange HDD sounds
3) Mount HDD (read-write, under Raspbian)
4) Monitor mount status
5) Umount HDD
6) Unplug HDD from RPi

Scenario II RPi power ---> RPi mobo <---> ext HDD <--- USB 3.0 hub

1) Plug HDD into hub using power leg of Y cable;
plug HDD into RPi using data leg of Y cable
2) Listen for strange HDD sounds
3) Mount HDD (as before)
4) Monitor mount status
5) Umount HDD
6) Unplug HDD from RPi and then from hub

Scenario IB RPi power ---> RPi mobo <===> ext HDD

1) Plug HDD into RPi twice, using both legs of Y cable
2) Listen for strange HDD sounds
3) Mount HDD (as before)
4) Monitor mount status
5) Umount HDD
6) Unplug HDD (disconnecting both legs of Y cable from RPi)

After this I dump logging with dmseg and split it in 4 parts with each start of a scenario as a splitting point (calling them part 0, 1, 2 and 3).

My findings:

Logging part 0 (booting the RPi w/o HDD attached) is very similar to that of my previous test (which I didn't post here).

dmseg outputs for the scenarios IA, II and IB (part 1, 2 and 3) are almost identical to eachother. One difference I see is that the USB device number increases each time the ext HDD connects to (and disconnects from) the RPi:

[ 43.491418] usb 1-1.1.3: new high-speed USB device number N using dwc_otg
...
[ 538.298106] usb 1-1.1.3: USB disconnect, device number N

with N =5,6,7

When the HDD is disconnected (unplugged) I see at the end of every scenario three messages in total:

[ 538.298106] usb 1-1.1.3: USB disconnect, device number 5/6/7
[ 368.317198] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 368.317463] sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=0x01 driverbyte=0x00

Note that these messages are not present in the log I posted previously because I didn't include unplugging of the HDD back then.

When I compare the log I posted previously with my new log (part 1, 2 or 3) the only difference I see is that these messages have gone:

[ 528.313638] Under-voltage detected! (0x00050005)
...
[ 532.473730] Voltage normalised (0x00000000)

So I guess that is because the official RPi power supply delivers more power than an individual USB 3.0 hub port?!

Unfortunately, in all three scenarios I still see:

[ 476.236603] EXT4-fs (sda5): Remounting filesystem read-only

This messages comes 7, 10, 11 or 13 seconds (in my four tests) after this one:

[ 465.486997] EXT4-fs (sda5): mounted filesystem with ordered data mode. Opts: errors=remount-ro

This timing is confirmed per step 4 of my scenarios (monitor mount status by repeating the 'mount' command a couple of times).

So using the official RPi power supply doesn't solve my mount RW => RO problem.

- - - - -

What else am I to do?

When I google on the phrase "tag#0 Sense Key : 0x5 [current]" I hit a couple of posts that might help me further:

This post exactly describes my problem in terms of dmesg output:
https://www.raspberrypi.org/forums/view ... p?t=231026

And this post tells me what the "tag#0" errors might indicate:
https://forums.unraid.net/topic/56820-b ... scsi-data/

Here's an example of a CD in /dev/sr0 generating similar errors:
https://bbs.archlinux.org/viewtopic.php?id=212919

A similar (but not identical) problem was solved by replacing an RPi 3 B+ by an RPi 3 B:
https://github.com/raspberrypi/linux/issues/2714
(lateron it was found that the RPi 3 B+ mobo itself was faulty)

I see three ways to go:
1) restart HDD partitioning, now using (g)parted
2) replace my RPi 3 B+ by an RPi 3 B (which I also happen to have)
3) get myself another controller/enclosure for the ext HDD, inspired by @Ducky and @LTolledo

Does anybody on the RPi forum has suggestions for me, based on my findings?

[Steijn van Essen]

Hello community,

Been busy with so many things that it took some time before I was able to follow up.
Here's what happened:

Last time, I posed three suggestions for moving on:
1) restart HDD partitioning, now using (g)parted
2) replace my RPi 3 B+ by an RPi 3 B (which I also happen to have)
3) get myself another controller/enclosure for the ext HDD

I choose, however another option: hooking up my Logilink UA0256 based ext HDD case to another version of Linux.

This took me a while. I have a small VMware farm with a number of virtual Linux servers in it. Some are important and I don't want to touch those. So I dusted off an old VMware server and upgraded it first, before installing a very basic virtual Linux server.
My favorite Linux flavour at the moment is Debian GNU/Linux (v7.6), so kernel behaviour should closely match that of Raspbian.
Then I had to learn some things about VMware USB device passthrough before I was able to hook my physical ext HDD to my virtual Debian machine (via a virtual USB3 port). With some trial and error I made it work. And guess what: mounting the ext HDD RW dropped to RO after some 10 seconds, just like with Raspbian. Here's the dmesg output from the moment the ext HDD is discovered (as sd 3:0:0:0:):

Code: Select all

[    3.143511] scsi 3:0:0:0: Direct-Access     WDC WD20 SPZX-00CRAT0     0117 PQ: 0 ANSI: 6
[    3.144193] sd 3:0:0:0: Attached scsi generic sg2 type 0
[    3.145261] sd 3:0:0:0: [sdb] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB)
[    3.147551] sd 3:0:0:0: [sdb] Write Protect is off
[    3.147554] sd 3:0:0:0: [sdb] Mode Sense: 47 00 10 08
[    3.149830] sd 3:0:0:0: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA
[    3.150610] Adding 477180k swap on /dev/sda5.  Priority:-1 extents:1 across:477180k 
[    3.163061] EXT4-fs (sda1): re-mounted. Opts: (null)
[    3.216018] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro
[    3.230794] loop: module loaded
[    5.506932]  sdb: sdb1 < sdb5 >
[    5.520455] sd 3:0:0:0: [sdb] Attached SCSI disk
[    5.769480] RPC: Registered named UNIX socket transport module.
[    5.769482] RPC: Registered udp transport module.
[    5.769483] RPC: Registered tcp transport module.
[    5.769484] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    5.773288] FS-Cache: Loaded
[    5.778706] FS-Cache: Netfs 'nfs' registered for caching
[    5.782403] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
[    5.852854] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
[    5.860982] e1000: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
[    5.862695] ADDRCONF(NETDEV_UP): eth1: link is not ready
[    5.862726] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[    6.140639] sd 0:0:0:0: [sda] Unhandled sense code
[    6.140642] sd 0:0:0:0: [sda]  Result: hostbyte=invalid driverbyte=DRIVER_SENSE
[    6.140644] sd 0:0:0:0: [sda]  Sense Key : Hardware Error [current] 
[    6.140646] sd 0:0:0:0: [sda]  Add. Sense: Internal target failure
[    6.140650] sd 0:0:0:0: [sda] CDB: Read(10): 28 00 00 8d 81 f8 00 01 00 00
[    6.140655] end_request: critical target error, dev sda, sector 9273848
[   16.042242] eth0: no IPv6 routers present
[   16.402008] eth1: no IPv6 routers present
[  698.792450]  sdb: sdb1
[ 1317.340683] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null)
[ 1323.306727] sd 3:0:0:0: [sdb]  Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 1323.306731] sd 3:0:0:0: [sdb]  Sense Key : Illegal Request [current] 
[ 1323.306734] sd 3:0:0:0: [sdb]  Add. Sense: Invalid field in cdb
[ 1323.306738] sd 3:0:0:0: [sdb] CDB: Write(10): 2a 08 74 44 08 18 00 00 08 00
[ 1323.306746] end_request: I/O error, dev sdb, sector 1950615576
[ 1323.306828] end_request: I/O error, dev sdb, sector 1950615576
[ 1323.306912] Aborting journal on device sdb1-8.
[ 1324.034502] EXT4-fs error (device sdb1): ext4_journal_start_sb:327: Detected aborted journal
[ 1324.034626] EXT4-fs (sdb1): Remounting filesystem read-only

Though the type/order of operations on the drive is different from Rapbian, the Debian log shows the same final result: "Remounting filesystem read-only". Note also that the output under Debian is a bit more verbose than that ounder Raspbian, with explicit mentioning of things like "Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE", "Sense Key : Illegal Request [current]" and "CDB: Write(10): 2a 08 74 44 08 18 00 00 08 00".

So I guess that the Logilink UA0256 is not Linux compatible (at least for Debian flavours). Can't blame the vendor: the datasheet only mentions Win 7/8.1/10 and MacOS with respect to OS compatibility.

To doublecheck my suspicion I then hooked up my old Conceptronics ext HDD case to the Debian VM. It mounted RW with no fallback to RO. Could not write any data to it, however, getting 'Permission denied'. Most likely because it was NTFS formatted. Using fdisk I replaced the NTFS partition by an EXT4 partition and remounted it. Now I was able to write (and read back) a file to it.
The last thing I did was hooking up the Conceptronics to my RPi, mount it RW and, guess what, read and write directly to the partition I had prepared on the Debian VM. So, Raspbian (and Debian) do not work well with the Logilink external HDD case, while with Windows it works flawless.

Unless somebody very technically skilled can tell me how to tweak Raspbian (or Debian for that sake) so that it will not remount the FS read-only after encountering the above errors I see no other option than number 3: to get myself another controller/enclosure for the ext HDD. @Ducky and @LTolledo already brought some options to my attention.

FYI: I already tried to mount the Logilink with option "errors=remount-rw" but this results in my RPi to hang. And I didn't find any details on the controller used in the Logilink case.

Feel free to leave a comment if you don't agree with my conclusions and/or still see a path to a solution other than the ones I already figured out myself.

Thanks everbody for your time and help,

[Steijn van Essen]

With 2019 coming to a close I thought it a good idea to add something to my post:

Last August I replaced my Logilink enclosures with Adata ED600 enclosures and this DID solve my mounting problems.
So, when buying external, USB attached, HDD enclosures for Raspbian OS (or Debian) make sure the data sheet mentions Linux compatibility.

A final tip: to prevent the OS from stalling its bootup when a to-be-mounted device is missing you can add the 'nofail' option on the mount statement or in /etc/fstab. This allows you to SSH into your RPi system to resolve mounting problems, if needed.

Wishing you all a fruitful 2020,