Hi All - went to watch a movie today and the vero 4K is not reading the external hard drive at all. Any ideas?
I’ve uploaded a log here:
https://paste.osmc.tv/vuhugewofo
Thanks!
Seems your disk failed. Try fsck.ext4 on the disk.
How is your drive powered?
Dec 01 14:31:40 osmc kernel: sda: sda1 Dec 01 14:31:40 osmc kernel: sd 0:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16). Dec 01 14:31:40 osmc kernel: sd 0:0:0:0: [sda] No Caching mode page found Dec 01 14:31:40 osmc kernel: sd 0:0:0:0: [sda] Assuming drive cache: write through Dec 01 14:31:40 osmc kernel: sd 0:0:0:0: [sda] Attached SCSI disk Dec 01 14:31:40 osmc udisks-glue[527]: Device file /dev/sda inserted Dec 01 14:31:40 osmc sudo[1048]: osmc : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/sbin/hdparm -S 240 /dev/sda Dec 01 14:31:40 osmc sudo[1048]: pam_unix(sudo:session): session opened for user root by (uid=0) Dec 01 14:31:40 osmc udisks-glue[527]: SG_IO: bad/missing sense data, sb[]: f0 00 01 00 50 00 00 0a 80 00 00 00 00 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Dec 01 14:31:40 osmc udisks-glue[527]: /dev/sda: Dec 01 14:31:40 osmc udisks-glue[527]: setting standby to 240 (20 minutes) Dec 01 14:31:40 osmc sudo[1048]: pam_unix(sudo:session): session closed for user root Dec 01 14:31:40 osmc udisks-glue[527]: Device file /dev/sda1 inserted Dec 01 14:31:40 osmc udisks-glue[527]: Trying to automount /dev/sda1... Dec 01 14:31:41 osmc ntpd[923]: Soliciting pool server 185.121.25.242 Dec 01 14:31:41 osmc ntpd[923]: Soliciting pool server 193.150.34.2 Dec 01 14:31:41 osmc ntpd[923]: Soliciting pool server 88.97.49.225 Dec 01 14:31:42 osmc ntpd[923]: Soliciting pool server 51.89.151.183 Dec 01 14:31:42 osmc ntpd[923]: Soliciting pool server 85.199.214.98 Dec 01 14:31:42 osmc ntpd[923]: Soliciting pool server 95.215.175.2 Dec 01 14:31:42 osmc kernel: JBD2: Invalid checksum recovering block 710 in log Dec 01 14:31:42 osmc kernel: JBD2: Invalid checksum recovering block 710 in log Dec 01 14:31:42 osmc kernel: JBD2: Invalid checksum recovering block 713 in log Dec 01 14:31:42 osmc kernel: JBD2: Invalid checksum recovering block 715 in log Dec 01 14:31:42 osmc kernel: JBD2: Invalid checksum recovering block 716 in log Dec 01 14:31:42 osmc kernel: JBD2: Invalid checksum recovering block 717 in log Dec 01 14:31:42 osmc kernel: JBD2: Invalid checksum recovering block 718 in log Dec 01 14:31:42 osmc kernel: JBD2: Invalid checksum recovering block 718 in log Dec 01 14:31:42 osmc kernel: JBD2: Invalid checksum recovering block 720 in log Dec 01 14:31:42 osmc kernel: JBD2: Invalid checksum recovering block 721 in log Dec 01 14:31:42 osmc kernel: JBD2: Invalid checksum recovering block 721 in log Dec 01 14:31:42 osmc kernel: JBD2: Invalid checksum recovering block 722 in log Dec 01 14:31:42 osmc kernel: JBD2: Invalid checksum recovering block 722 in log Dec 01 14:31:42 osmc kernel: JBD2: Invalid checksum recovering block 722 in log Dec 01 14:31:42 osmc kernel: JBD2: Invalid checksum recovering block 723 in log Dec 01 14:31:42 osmc kernel: JBD2: Invalid checksum recovering block 723 in log Dec 01 14:31:42 osmc kernel: JBD2: Invalid checksum recovering block 723 in log Dec 01 14:31:42 osmc kernel: JBD2: Invalid checksum recovering block 725 in log Dec 01 14:31:42 osmc kernel: JBD2: Invalid checksum recovering block 726 in log Dec 01 14:31:42 osmc kernel: JBD2: Invalid checksum recovering block 726 in log Dec 01 14:31:43 osmc ntpd[923]: Soliciting pool server 91.233.83.132 Dec 01 14:31:43 osmc ntpd[923]: Soliciting pool server 185.53.93.157 Dec 01 14:31:43 osmc kernel: JBD2: recovery failed Dec 01 14:31:43 osmc kernel: EXT4-fs (sda1): error loading journal Dec 01 14:31:43 osmc udisks-glue[527]: Failed to automount /dev/sda1: Error mounting: mount: wrong fs type, bad option, bad superblock on /dev/sda1, Dec 01 14:31:43 osmc udisks-glue[527]: missing codepage or helper program, or other error Dec 01 14:31:43 osmc udisks-glue[527]: In some cases useful info is found in syslog - try Dec 01 14:31:43 osmc udisks-glue[527]: dmesg | tail or so.
It’s self powered with its own plug.
I’ll try that command.
this is what I got, not sure what to do next:
Usage: fsck.ext4 [-panyrcdfktvDFV] [-b superblock] [-B blocksize]
[-l|-L bad_blocks_file] [-C fd] [-j external_journal]
[-E extended-options] [-z undo_file] device
Emergency help:
-p Automatic repair (no questions)
-n Make no changes to the filesystem
-y Assume “yes” to all questions
-c Check for bad blocks and add them to the badblock list
-f Force checking even if filesystem is marked clean
-v Be verbose
-b superblock Use alternative superblock
-B blocksize Force blocksize when looking for superblock
-j external_journal Set location of the external journal
-l bad_blocks_file Add to badblocks list
-L bad_blocks_file Set badblocks list
-z undo_file Create an undo file
Try this:
sudo fsck.ext4 /dev/sda1
You may need to answer yes to questions depending on how badly the filesystem was damaged.
it just comes up:
-bash: fsck.ext4/dev/sda1: No such file or directory
So is the disk corrupted? Whats happening here? its a new drive, and the last one corrupted too after connecting to vero. Am I doing something wrong with the drives? They have their own power supply, stay connected to Vero at all times, seem to power down when vero is in suspend mode, and this one is ext4. it took a week to transfer files into ext4 format and this isn’t sustainable if the drive will fail within a matter of weeks.
Any thoughts appreciated. Thanks
You are missing a space. Look closely at the command I gave.
I put the space in too on a second attempt and it said command not recognised.
Paste exactly what you typed on the command line and the response.
ok - my error, I missed the space after sudo. apologies.
its now checking a bunch of stuff and saying that it was not cleanly unmounted. This is where we’re now at:
osmc@osmc : ~ $ sudo fsck.ext4 /dev/sda1
e2fsck 1.43.4 (31-Jan-2017)
Films: recovering journal
JBD2: Invalid checksum recovering block 710 in log
JBD2: Invalid checksum recovering block 710 in log
JBD2: Invalid checksum recovering block 713 in log
JBD2: Invalid checksum recovering block 715 in log
JBD2: Invalid checksum recovering block 716 in log
JBD2: Invalid checksum recovering block 717 in log
JBD2: Invalid checksum recovering block 718 in log
JBD2: Invalid checksum recovering block 718 in log
JBD2: Invalid checksum recovering block 720 in log
JBD2: Invalid checksum recovering block 721 in log
JBD2: Invalid checksum recovering block 721 in log
JBD2: Invalid checksum recovering block 722 in log
JBD2: Invalid checksum recovering block 722 in log
JBD2: Invalid checksum recovering block 722 in log
JBD2: Invalid checksum recovering block 723 in log
JBD2: Invalid checksum recovering block 723 in log
JBD2: Invalid checksum recovering block 723 in log
JBD2: Invalid checksum recovering block 725 in log
JBD2: Invalid checksum recovering block 726 in log
JBD2: Invalid checksum recovering block 726 in log
Journal checksum error found in Films
Films was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong (560745176, counted=528282428).
Fix? yes
Free inodes count wrong (1904699, counted=1904687).
Fix? yes
Films: ***** FILE SYSTEM WAS MODIFIED *****
Films: 3057/1907744 files (0.0% non-contiguous), 1425223871/1953506299 blocks
osmc@osmc : ~ $
Rebooted and it seems to be working. i’ll have a play around and see if it checks out, but initially it looks good.
Very much appreciate the help.
Cheers
Is this the same drive that you had formatted exFAT previously? If so, then I’d suggest doing some testing on the drive as 2 failures like this make me very suspicious.
no it’s a new drive - only ever been ext4 and only used with the vero. I share your concerns though. I’m worried the vero isn’t dismounting correctly in suspend but assume no-one else has any issues.