HDD not happy, file system check seems to cause a core dump

[ploughguy]

I have a (beyonwiz-supplied) 1 TB drive plugged into my V2. It was working fine until yesterday - about 160GB free space, recording and replaying like a champ.

Yesterday, I watched a program from it at about 6pm - all good, then at about 8 tried to watch another and the recorded media display page hung with the rotating dingus on the screen totally ignores the remote, including the power button. I restarted the V2 by cycling the power - no change. In Settings - Setup - Storage - File System Check, the device is listed with its correct size, but the FSCK does not run - I get a brief Python error (screenshot attached, I hope.).

I have also attached snaps of the info pages for system version and attached devices.
The software version is dated Oct 2021 - I have tried to update it but it tells me there is no new version. Is this correct?

This message has two purposes:
1: Report the program crash so maybe someone can fix it one day;
2: Find out what my recovery options are, if any.

Does this mean my disk is shot? Or is there hope? So much unwatched content - I was kinda hoping to be hit by a bus so I could veg out and catch up…

Any thoughts?

Thanks for your help!
Russ

[IanL-S]

I have never seen this with my V2, nor my U4 or T2. Have had similar thing happen with Toppys (which use a different file system). I suspect the most likely explanation is a corrupted file system, which is not inconsistent with reporting the correct capacity of the disk (which I think you are saying is the case)..

My guess is that the USB HDD is OK.

I would copy any recordings that you want to keep via ftp to PC or MAC. I Would then attach it to PC/MAC and run SeaTools for Windows or if MAC the corresponding MAC utility. Hopefully that will fix the problem.

[prl]

The problem is that the HDD is being detected by the system, but its filesystem type can't be determined. That means that the HDD's filesystem may only be able to be recovered by running the filesystem check manually from the V2's command-line interface.

The crash is caused because the code doesn't handle that case correctly. It should just ignore the OK button press in that case. Instead it tries to use an invalid entry in the list.

An alternative would be to remove the V2's HDD, put it into a USB dock and connect that to a Linux system, where that system's HDD check could be used on the V2's HDD.

Both of those are likely to be beyond what you want to do.

Alternatively, you could try to format the V2's HDD from the Storage menu, but if that's successful, it will erase all the recordings and media on the V2's HDD.

[peteru]

If you just bought and connected the external USB drive without formatting it on the V2 first, it is most likely formatted as NTFS. If there is any corruption on that drive, NTFS is not repairable on the Beyonwiz. However, if it is NTFS, connecting the drive to a Windows machine should allow you to repair the file system and it is very likely that you will be able to salvage some/most of the data.

As a first step, shut down the V2, disconnect the drive and connect the drive to a Windows machine. If Windows recognises the drive, try to repair the file system using whatever tools ship with Windows. Don't bother with third party data recovery tools. If this is successful, you can "Safely Remove/Eject" the drive from Windows and reconnect it to the V2. It should work again.

To avoid problems in the future, if you repair the file system on the drive, you should copy any data you want to keep to a different drive and reformat the HDD on the V2 itself. This will ensure that the HDD is using a robust file system that can be natively repaired. NTFS is not that file system.

[ploughguy]

Thanks to you all for your help.
I don't recall if I formatted the drive when I first installed it - I might have assumed that buying in it from BeyonWiz meant it was ready to go, or I might have gone all Unix-guy on it and reformatted it because if you want it done properly...

I have connected in via ssh from my Mac.
parted returns the following:
---------------8<---------------
root@beyonwizv2:~# parted
GNU Parted 3.2
Using /dev/sdc
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p
Model: Seagate Expansion (scsi)
Disk /dev/sdc: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1049kB 1000GB 1000GB ext4 primary
(parted)
---------------8<---------------

This implies we have an ext4 file system, which makes sense. I presume this means I reformatted it when I set up the Wiz.
I created /media/russ as a mount point.

Mount seems to expect NTFS and nothing else:

---------------8<---------------
root@beyonwizv2:~# mount /dev/sdc /media/russ
NTFS signature is missing.
Failed to mount '/dev/sdc': Invalid argument
The device '/dev/sdc' doesn't seem to have a valid NTFS.
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?
FUSE exfat 1.2.3
ERROR: exFAT file system is not found.
mount: mounting /dev/sdc on /media/russ failed: Invalid argument
---------------8<---------------

I tried to give it a hint - no luck.

---------------8<---------------
root@beyonwizv2:~# mount -t ext4 /dev/sdc1 /media/russ
mount: mounting /dev/sdc1 on /media/russ failed: Invalid argument
root@beyonwizv2:~# mount -t ext4 /dev/sdc /media/russ
mount: mounting /dev/sdc on /media/russ failed: Invalid argument
root@beyonwizv2:~#
---------------8<---------------

This is not a new drive - the Wiz has been saving and retrieving programs from it for years. So 10 days ago, it was working fine.

Any thoughts?
I've clearly done something wrong above, so .... HELP!
And thanks in advance for that help, too.
Russ

[prl]

Have you tried doing fsck -n /dev/sdc1 to see whether fsck recognises the filesystem? As you probably know, the -n flag answers "no" to any question about whether fsck should try to change the HDD.

If it's an ext4 filesystem, and the problem is that the filesystem superblock has been clobbered, fsck may be able to recover a backup superblock from the HDD.

[ploughguy]

Thanks, Pete - I did some more googling and tried this, which seems to be working!

---------------8<---------------
root@beyonwizv2:~# fsck.ext4 /dev/sdc1
e2fsck 1.44.3 (10-July-2018)
V2: recovering journal
JBD2: Invalid checksum recovering block 0 in log
Journal checksum error found in V2
V2 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Inode 302597 has an invalid extent node (blk 206602243, lblk 0)
Clear<y>? yes
Inode 302597 extent tree (at level 1) could be shorter. Fix<y>? yes
Inode 302597, i_blocks is 5847104, should be 0. Fix<y>? yes
---------------8<---------------

And a minute or so later we have:

---------------8<---------------
Free blocks count wrong for group #7451 (12288, counted=16384).
Fix? yes

Free blocks count wrong (28027592, counted=52373067).
Fix? yes


V2: ***** FILE SYSTEM WAS MODIFIED *****
V2: 2222/357744 files (16.4% non-contiguous), 191817141/244190208 blocks
root@beyonwizv2:~#
---------------8<---------------

I restarted the Wiz and the Media button still shows nothing.

root@beyonwizv2:~# cat /media/autofs
cat: read error: Is a directory
root@beyonwizv2:~# mount /dev/sdc1 /media/russ
root@beyonwizv2:~# ls /media/russ
backup lost+found movie pictures timeshift
root@beyonwizv2:~#
root@beyonwizv2:~# ls /media/russ/movie/
20191117 2025 - SBS ONE HD - Inside The Orient Express.eit
20191117 2025 - SBS ONE HD - Inside The Orient Express.ts
20191117 2025 - SBS ONE HD - Inside The Orient Express.ts.ap
20191117 2025 - SBS ONE HD - Inside The Orient Express.ts.cuts
20191117 2025 - SBS ONE HD - Inside The Orient Express.ts.meta
---------------8<---------------

So we have content...
I remounted on /media/hdd, clicked the Media button on the remote which then asked me where the movie content was stored - selected /media/hdd/movie and all my stuff came back. Bingo

Thank you everyone for your help.

[prl]

root@beyonwizv2:~# cat /media/autofs
cat: read error: Is a directory

That is normal. /media/autofs is a directory, and directories can only be read by special system calls, not by normal file open/read operations that cat uses.

selected /media/hdd/movie and all my stuff came back. Bingo

Glad that you've got it sorted!

[ploughguy]

It’s happened again! At least, the symptoms are the same. Initial panic, then I think to myself “Self, I bet someone has seen this problem before.” Imagine my surprise to find that someone was me! (And only four months ago - clearly a lot of other stuff has gone bad to make me forget the previous trauma)

Thankfully, I seem to have documented the solution (at least in the previous case) here.

Hopefully it is the same problem with the same fix. All that time spend mucking about with Unix Level 6 on a PDP 11/40 in the 1970s is at last paying off.

Updates to follow.
Russ

[ploughguy]

OK, same fix again. I have summarized here for next time.
# Connect via ssh
ssh root@192.168.0.10

# Get parted to report on connected devices with the "p" command.
# It tells me I have a Disk /dev/sdc: 1000GB
# Also tells us the file system structure for partition number 1 (in my case ext4.)
# If you drive is not listed here, then the Wiz can't see it.
# Close the parted program with command q
~# parted
(parted) p
<bunch of connected device info here - see previous postings above in this thread.>
(parted) q

# Run the file system checker on the partition /dev/sdc1
# If you have a different structure to ext4, you need to identify the right fsck variant.
fsck.ext4 /dev/sdc1

# It runs for a minute or so. Hopefully it ends by reporting ***** FILE SYSTEM WAS MODIFIED *****
# Which means it was repairable.

Didn't bother to mount and test via rsh - just rebooted the Wiz and all my recordings reappeared on restart.

None of this is magic - and it chould be automated by WizOs:
- reconcile parted output against mounted devices.
- any missing? Run the appropriate file system checker.
- pop up a dialog to report that a recovery was done and some recordings may have been lost.

[ploughguy]

Ploughguy would like to thank the creator of this post for his excellent work - fixed my current problem completely...!
Can't help thinking that this should not be happening on something that aims to be an appliance.

I am using ext4 file systems - should I be using something else instead? I would have thought that in 2024, file system errors should be handled by redundant structural information and automatic recovery. No?

[prl]

Ext4 filesystems are journalling filesystems, with journals for both structural information and data. NTFS, by comparison, only has journalling for file system metadata (and is not well supported on Beyonwizes). Ext4 is also a newer (2006) filesystem format than NTFS (1993). Ext2, ext4's earliest predecessor, is the same age as NTFS.

https://en.wikipedia.org/wiki/Compariso ... pabilities

[peteru]

No consumer grade file system (capable of running on PVR hardware) is reliable when it comes to flaky hardware or power loss.

"Flaky hardware" includes many USB drives, especially those that enter various power saving states without being told to do so by the operating system. The most likely causes that lead to HDD corruption would be power loss (blackouts, turning devices off at the wall, etc.), unreliable cable/USB connection or a HDD that goes offline or enters power saving mode. Many laptop HDDs and portable enclosures have automatic power saving features. Those features must be disabled for long term reliability.

When it comes to recovering from file system corruption, the Beyonwiz, like most systems, takes the conservative approach of only correcting problems where the recovery is unlikely to lead to any loss of data that has been written to the disk completely. The idea is to limit the data loss to only the data that was being written to the disk at the time of failure. When this can not be done, the system will refuse to make any further changes to the file system to prevent loss of existing data. This gives the user an opportunity to perform data recovery if desired.

Taking a more aggressive approach of automatically bringing the file system to a consistent state, even at the risk of data loss, would be possible, but IMNSHO this would not be desirable. Doing so would result in the user randomly experiencing data loss, without any warnings and explanation.