HDD Errors and Warnings

Today I was greeted with this warning as I accessed the FOX T2 via the WebIf , it is ' Filesystem /mnt/hd2 0n /dev/sdb2 is read only. I am not sure how to interpret this, not sure if serious and indeed how to resolve it. I have ran the fixdisk utility twice in the hope that it might help resolve it but it persists. Could anyone shed any light, offer any solution etc. Thank you
 
Either a hardware failure or an accumulation of file system inconsistencies. No point speculating, it happens. Nobody can tell you any more about it until you post some actual data.
 
To expand a little, if the fs driver sees that the fs is readable but is "too corrupt to use safely", it mounts the fs RO instead of RW. The Humax software runs a minor disk check and repair ("preen") at startup, but errors not fixable by that can accumulate.

If you can create files on the other partitions (/dev/sdb1, /dev/sdb3), that would rule out the hardware having become RO.
 
Last edited:
To expand a little, if the fs driver sees that the fs is readable but is "too corrupt to use safely", it mounts the fs RO instead of RW. The Humax software runs a minor disk check and repair ("prune") at startup, but errors not fixable by that can accumulate.

If you can create files on the other partitions (/dev/sdb1, /dev/sdb3), that would rule out the hardware having become RO.
That's more like it, and a great explanation of the possible events. I refuse to condemn a HDD as faulty until all avenues are explored.
Now how does one go about accessing the partitions on the installed disk and how does one instruct the creation of files on a different partition?
 
Partition 3 (which fixdisk uses for temporary and log storage, if available) was fine but the repair of partition 2 failed because some filesystem data was so incorrect that handling it crashed the repair tool:
Code:
...
Error storing directory block information (inode=4320305, block=0, num=42709322): Memory allocation failed
...
Clearly the disk itself is not RO, at least. The SMART disk check passed, so there's no obvious damage to the disk.

You can try again to see if the earlier repairs have corrected the problem. If you get the same error (same numbers), you may have to try a different solution. Otherwise repeat until successful.

A different solution might be to back up any precious content (bearing in mind that by now some might be corrupted in some way) and then reformat the disk and restore the saved content; this does have the benefit of eliminating the non-precious content with extreme prejudice. Or to remove the disk and try to repair it using a USB-SATA dock and a Linux PC (could be using a live CD): a machine with more memory (even just address bits) might be able to bypass the crash and complete the repair.
 
I think history has now proved that repeated attempts to fix these errors with "Memory allocation failed" are not going to be successful on the Humax, so /df's latter two solutions would seem to be the only viable ones.
 
I have taken the HDD out and connected it to my laptop via USB, I have ran a smartctl -d sat --all /dev/sdc2 diagnostic. I obviously get a long output back, what do I look for in this output can I attach it to a post for someone to view with some feedback please. How do I do that from the cmd terminal?.
 
Having taken out the HDD and looked at it on my linux laptop, I decided to use fsck utility to troubleshoot and possibly fix the disk. The fsck /dev/sdx command is forced to stop with the error message fsck.ext3 for device /dev/sdx has exited with signal 9. This in indicative of a process forced to stop dead because of not enough swap. So the fsck utility cannot check the filesystem because there is not enough virtual memory. So how to fix this? Any ideas please?
 
Signal 9 = SIGKILL, or return code 9 = 8+1 = Operational error + File system errors corrected ?
 
Signal 9 = SIGKILL, or return code 9 = 8+1 = Operational error + File system errors corrected ?
Yes thank you for this explanation, it is essentially a kill operation intervention, an it is likely due to there being insufficient swap .
I have tried to look into the swapfile but it is read-only, therefore I am unable to increase it, if indeed it can be, I used the cmd dd if=dev/zero of=swap_file bs=1 count=1, the output was can't open /swap_file : RO filesystem.

Thus I am going to stop with this nonsense now, transfer best recordings off the HDD and format (ext3) and go from there.
Thanks guys for suggestions.
 
I have tried to look into the swapfile but it is read-only, therefore I am unable to increase it, if indeed it can be, I used the cmd dd if=dev/zero of=swap_file bs=1 count=1, the output was can't open /swap_file : RO filesystem.
That does not sound right. This is on another system, not the HDR-FOX – right?

In any case, before you could manipulate the swap file you would have to be turning swap off, and only then rebuild the swap file using OS commands. Something like (https://askubuntu.com/questions/927...-swapfile-without-removing-it-in-the-terminal):

First disable swap file:

Code:
sudo swapoff /swapfile

Now let's increase the size of swap file:

Code:
sudo dd if=/dev/zero of=/swapfile bs=1M count=1024 oflag=append conv=notrunc

The above command will append 1GiB of zero bytes at the end of your swap file.

Setup the file as a "swap file":

Code:
sudo mkswap /swapfile

enable swaping:

Code:
sudo swapon /swapfile


On a production system, if your operating system does not let you to disable the swap file using sudo swapoff /swapfile and you receive a messages similar to:

Code:
swapoff failed: Cannot allocate memory

Then You might consider having multiple swap files or create a new larger one, initialize it and then remove the old smaller one.
 
It is quite possible that the file system error is causing it to calculate a ludicrously high amount of storage is required to recover a file and that you will never be able to create a big enough swap file to cope, you will have a better chance on a PC than with the limited space available on the humax.
 
Back
Top