LibreElec don't find my new hard drive

Arutha · November 19, 2017 at 8:31 AM

Hello,

Thanks for this excelent software.

Sorry my English is not good if you don't understand please ask me and I will try to say it in another way.

I change my usb storage drive with a new one of 8 To WD Red plugged in usb (one NTFS partition of 8TO) it works well on windows.

When i plug it on my OpenElec HTPC it doesn't see it.

LibreELEC:~ # df -h

Filesystem Size Used Available Use% Mounted on

devtmpfs 1.8G 202.8M 1.6G 11% /dev

/dev/sda1 487.9M 215.2M 262.5M 45% /flash

/dev/sda2 116.4G 762.6M 115.6G 1% /storage

/dev/loop0 202.8M 202.8M 0 100% /

tmpfs 1.8G 0 1.8G 0% /dev/shm

tmpfs 1.8G 7.2M 1.8G 0% /run

tmpfs 1.8G 0 1.8G 0% /sys/fs/cgroup

tmpfs 1.8G 2.0M 1.8G 0% /var

tmpfs 1.8G 4.0K 1.8G 0% /tmp

LibreELEC:~ # blkid

/dev/sda1: LABEL="System" UUID="bed3b1ff-de96-4f80-aee8-88f36efbbd49" TYPE="ext4" PARTUUID="53660d9a-01"

/dev/sda2: LABEL="Storage" UUID="b45751dd-b419-47e3-9787-849526a0163b" TYPE="ext4" PARTUUID="53660d9a-02"

/dev/loop0: TYPE="squashfs"

/dev/sdb: PTTYPE="PMBR"

Could you help me?

Best regards,

**chewitt** · November 19, 2017 at 12:21 PM Official Post

Make sure you safe eject from Windows else the NTFS volume is 'dirty' and Linux will refuse to mount it to prevent filesystem damage. If that is not the issue run "dmesg | paste" and share the URL (after a clean boot, with the drive connected) so we can see what the kernel thinks.

Arutha · November 19, 2017 at 4:44 PM

I try eject properly the hard drive on Windows then retry on LibreElec but the problem still persist.

Here you can see in enclosed documents dmesg request.

Thank you,

**chewitt** · November 20, 2017 at 4:02 AM Official Post

Code

[    3.233361] ata2.01: failed to resume link (SControl 0)
[    3.244742] ata2.00: SATA link down (SStatus 4 SControl 0)
[    3.244766] ata2.01: SATA link down (SStatus 0 SControl 0)

^ It's not an error that I recognise .. but 9/10 of the "it works in Windows but not in Linux" USB drive issues we see are about cheap SATA bridges with poorly written firmware. It could also be a port issue on the HTPC device - what box is it?

**milhouse** · November 20, 2017 at 6:49 AM

The posted dmesg.txt is unusable as it's truncated at 80 columns.

Arutha upload your dmesg to a pastebin site with "dmesg | pastebinit" then paste the link. And please do the same with "journalctl -a | pastebinit" and paste that link. In both cases make sure the 8TB HDD is connected.

Arutha · November 20, 2017 at 9:15 PM

Hi,

I try directly plug the hard drive on the motherboard and it works!

Then a try with other usb sata adapter and it also works.

Do you know why my old usb sata adapter not work with the new drive?

Thanks,

**milhouse** · November 20, 2017 at 9:27 PM

Quote from Arutha

Do you know why my old usb sata adapter not work with the new drive?

Because the chipset your old SATA-to-USB adapter is using is incapable of "seeing" the full capacity of the 8TB HDD. As chewitt said, not all SATA Bridges are the same and the cheap ones can cause problems with the latest high capacity HDDs. From what I could make out in your truncated log the kernel thought your 8TB HDD had a capacity of about 1.4TB - then you chopped the rest of the information off after that.

VancoD · November 29, 2017 at 12:52 AM

I just shot my previous install of Kodi in the face because it was becoming increasingly problematic over the course of the last several years as XBMC (and Kodibuntu) "matured" to where they are today - Kodi, and "no longer supported". Updating the core OS resulted in odd behavior in Kodi.

I had a perfectly functional external USB drive (2 TB) on that Kodi system. It was fine when I shut down my system, and it was not plugged in during the LibreELEC install....

Now that I've <ahem> "upgraded" to LibreELEC my USB drive isn't being seen correctly.

Kodi:~ # blkid

<snip>
/dev/sdb: PTTYPE="PMBR"

Kodi:~ # blkid -o list

device fs_type label mount point UUID

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------

<snip>
/dev/sdb (not mounted)

Kodi:~ # dmesg | grep sdb

[ 641.920427] sd 6:0:0:0: [sdb] 4294967295 512-byte logical blocks: (2.20 TB/2.00 TiB)

[ 641.921439] sd 6:0:0:0: [sdb] Write Protect is off

[ 641.921442] sd 6:0:0:0: [sdb] Mode Sense: 34 00 00 00

[ 641.922422] sd 6:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA

[ 642.159137] sd 6:0:0:0: [sdb] Attached SCSI disk

[ 1742.619992] F2FS-fs (sdb): Magic Mismatch, valid(0xf2f52010) - read(0xebd0a0a2)

[ 1742.619996] F2FS-fs (sdb): Can't find valid F2FS filesystem in 1th superblock

[ 1742.620616] F2FS-fs (sdb): Magic Mismatch, valid(0xf2f52010) - read(0x0)

[ 1742.620619] F2FS-fs (sdb): Can't find valid F2FS filesystem in 2th superblock

[ 1742.620631] F2FS-fs (sdb): Magic Mismatch, valid(0xf2f52010) - read(0xebd0a0a2)

[ 1742.620632] F2FS-fs (sdb): Can't find valid F2FS filesystem in 1th superblock

[ 1742.620634] F2FS-fs (sdb): Magic Mismatch, valid(0xf2f52010) - read(0x0)

[ 1742.620635] F2FS-fs (sdb): Can't find valid F2FS filesystem in 2th superblock

The boot buffer messages have me concerned - can LibreELEC not read GPT partitions??

From parted - the news does not look good at all:
(parted) print all

print all

Error: Invalid argument during seek for read on /dev/sdb

Retry/Ignore/Cancel? I

I

Error: The backup GPT table is corrupt, but the primary appears OK, so that will be used.

OK/Cancel? OK

OK

Model: ST3000DM 001-1CH166 (scsi)

Disk /dev/sdb: 2199GB

Sector size (logical/physical): 512B/512B

Partition Table: unknown

Disk Flags:

I really hope that "Partition table unknown" message is simply an issue with LibreELEC's version of parted...

At this point I'm most likely to just go back to Ubuntu or Debian hoping that the drive is fine (as I believe it to be) - but I thought I'd ask here just on the odds there's a simple answer to my issue.... Sadly I don't have another Linux box handy that I can try the drive on.....

**chewitt** · November 29, 2017 at 2:54 AM Official Post

LE has no issue with GPT partitions and although it's not impossible we run a fairly current version of parted so it's unlikely the issue is there. I've no idea whether F2FS is fully supported though. If the kernel is trying to mount partitions there is clearly some config in the kernel but we don't use it ourselves (we use EXT4) so you might want to check and see if everything required is set.

Go back and test in Ubuntu (on a LiveUSB stick) before attempting anything else.

VancoD · November 29, 2017 at 4:07 AM

Well - good news / odd news.
I shut down LibreELEC to boot from my stick, had an issue with the bootloader, so I was going to run parted on it (inside LibreELEC) to wipe it out.... and....

Kodi:~ # dmesg | grep sdb

[ 2.987150] sd 6:0:0:0: [sdb] 60566016 512-byte logical blocks: (31.0 GB/28.9 GiB)

[ 2.987883] sd 6:0:0:0: [sdb] Write Protect is off

[ 2.987886] sd 6:0:0:0: [sdb] Mode Sense: 2b 00 00 08

[ 2.988641] sd 6:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA

[ 3.236826] sdb: sdb1 sdb2

[ 3.239190] sd 6:0:0:0: [sdb] Attached SCSI removable disk

[ 516.450350] sd 6:0:0:0: [sdb] 60566016 512-byte logical blocks: (31.0 GB/28.9 GiB)

[ 516.451111] sd 6:0:0:0: [sdb] Write Protect is off

[ 516.451116] sd 6:0:0:0: [sdb] Mode Sense: 2b 00 00 08

[ 516.451730] sd 6:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA

[ 517.966454] sdb: sdb1 sdb2
[ 517.969520] sd 6:0:0:0: [sdb] Attached SCSI removable disk

<USB stick pulled / USB drive inserted>
[ 710.369064] sdb:

[ 715.861101] sdb:

[ 731.358468] sdb:

[ 781.405228] sd 6:0:0:0: [sdb] Very big device. Trying to use READ CAPACITY(16).

[ 781.405608] sd 6:0:0:0: [sdb] 5860533168 512-byte logical blocks: (3.00 TB/2.73 TiB)

[ 781.406602] sd 6:0:0:0: [sdb] Write Protect is off

[ 781.406608] sd 6:0:0:0: [sdb] Mode Sense: 34 00 00 00

[ 781.407597] sd 6:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA

[ 781.409590] sd 6:0:0:0: [sdb] Very big device. Trying to use READ CAPACITY(16).

[ 781.476028] sdb: sdb1

[ 781.477203] sd 6:0:0:0: [sdb] Very big device. Trying to use READ CAPACITY(16).

[ 781.479952] sd 6:0:0:0: [sdb] Attached SCSI disk

[ 781.842249] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null)

So it's now "fine".

Kodi:~ # ls -l /var/media/sdb1-ata-ST3000DM001-1CH1/

total 128

drwx------ 2 1000 1000 20480 Jul 20 2014 MST3k

drwxr-xr-x 5 1000 1000 12288 Sep 20 08:42 Movies

drwxr-xr-x 2 1000 1000 49152 Sep 18 10:09 Music

drwxr-xr-x 3 1000 1000 4096 Jul 8 2016 RiffTrax

drwxr-xr-x 7 1000 1000 4096 Feb 21 2016 TV

drwxr-xr-x 2 1000 1000 4096 Nov 18 14:59 Woodworking Vids

drwx------ 6 1000 1000 12288 Nov 20 10:37 YouTubes

drwx------ 2 1000 1000 16384 Jun 26 2014 lost+found

drwxrwxr-x 3 1000 1000 4096 Nov 23 18:13 temp

I'm wondering if the drive enclosure is going bad......

**milhouse** · November 29, 2017 at 5:05 AM

It would help if you didn't snip logs (you've cut out useful information), and didn't claim it was a 2TB drive when it isn't (it seems to be 3TB) so clearly the kernel isn't always seeing the full capacity. If the kernel isn't detecting the full capacity every time I would suspect another dodgy bridge chip.

VancoD · November 29, 2017 at 3:11 PM

Sorry - just didn't see anything of note to include. If it's of any use after the fact:

aGeW (dmesg)

Should I have issue again I'll capture the buffer again.

LibreElec don't find my new hard drive

Similar Threads

Will not Wake from suspend & Chromium Add-on overscanning - Generic.x86_64_8.1.2 8.2

Odroid C2: Touchscreen-Support with Hannspree HT231HPB

LibreElec 8 loses sync with NTFS vol over USB