• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

Current_Pending_Sector/Offline_Uncorrectable errors - will fix-disk help?

/df said:
It's moved on. The problem is described here.

You could just continue until it works. Or, if you don't mind using the maintenance mode shell, this might sort it in one go (based on the link above, untested).

At the maintenance mode command line (cli), run mount[Enter] to check whether partition 3 (probably /dev/sda3) is mounted. If not, mount /dev/sda3 /mnt/hd3[Enter]. Create a cache directory on that partition for e2fsck mkdir -p /mnt/hd3/e2fscache[Enter].

Create a configuration file for e2fsck:
Code: 
cat <<EOM >/var/lib/humaxtv_backup/mod/e2fsck.conf
[scratch_files]
directory = /mnt/hd3/e2fscache
EOM
Check that the new file in fact contains lines 2 and 3 above as it should cat /var/lib/humaxtv_backup/mod/e2fsck.conf[Enter].

Now, go to an environment where this configuration should be used E2FSCK_OPTS=/var/lib/humaxtv_backup/mod/e2fsck.conf tmenu[Enter]. This should bring up the familiar maintenance mode menu (after PIN entry). When you run fix-disk from this menu, e2fsck should find out about the cache directory, fill it with data needed to fix a giant inode, and not run out of memory.

If this works it would be a candidate for updating fix-disk in the next CF. fix-disk uses a swap file to gain memory headroom for scanning the large partition, but it's obviously not enough. The [scratch_files] option might not have been available when fix-disk was created, but we have /sbin/e2fsck v1.42.13 in the CF now (as well as the same version that uses the 1.40 EXT2FS library in /usr/lib/ext2/bin, and as well as two versions in the repository, which wouldn't be accessible to fix-disk as their installations would be on the filesystem being fixed)
Click to expand...
Thanks - I'll try that.
In the meantime it reported a loss of the TV signal again - "The receiver is not receiving a signal or the signal is too weak". Signal strength and signal quality were both reported as 0%. The signal returned when I did a hard reboot.
 
fix-disk needs special swap file handling, as files on /mod, or indeed any hard disk filesystem, may not be accessible. It sets one up for partition 2 once it's fixed partition 3.

Would it save time to add this now?
"Doh!"
 
/df said:
It's moved on. The problem is described here.

You could just continue until it works. Or, if you don't mind using the maintenance mode shell, this might sort it in one go (based on the link above, untested).

At the maintenance mode command line (cli), run mount[Enter] to check whether partition 3 (probably /dev/sda3) is mounted. If not, mount /dev/sda3 /mnt/hd3[Enter]. Create a cache directory on that partition for e2fsck mkdir -p /mnt/hd3/e2fscache[Enter].

Create a configuration file for e2fsck:
Code: 
cat <<EOM >/var/lib/humaxtv_backup/mod/e2fsck.conf
[scratch_files]
directory = /mnt/hd3/e2fscache
EOM
Check that the new file in fact contains lines 2 and 3 above as it should cat /var/lib/humaxtv_backup/mod/e2fsck.conf[Enter].

Now, go to an environment where this configuration should be used E2FSCK_OPTS=/var/lib/humaxtv_backup/mod/e2fsck.conf tmenu[Enter]. This should bring up the familiar maintenance mode menu (after PIN entry). When you run fix-disk from this menu, e2fsck should find out about the cache directory, fill it with data needed to fix a giant inode, and not run out of memory.

If this works it would be a candidate for updating fix-disk in the next CF. fix-disk uses a swap file to gain memory headroom for scanning the large partition, but it's obviously not enough. The [scratch_files] option might not have been available when fix-disk was created, but we have /sbin/e2fsck v1.42.13 in the CF now (as well as the same version that uses the 1.40 EXT2FS library in /usr/lib/ext2/bin, and as well as two versions in the repository, which wouldn't be accessible to fix-disk as their installations would be on the filesystem being fixed)
Click to expand...
So I followed these instructions to the letter, but the fix-disk still gave the "Memory allocation failed" error (see below), plus another shedload of Illegal indirect block messages:
humax fixdisk finished 3.jpg
 
Massive apologies for wasting your time. Apparently having noticed that I typed the name of the critical environment variable wrongly, I somehow let the wrong one through. It should have been E2FSCK_CONFIG, as now updated. And then really if that doesn't work, you just have to repeat the -P -y procedure until it succeeds; and maybe run a short SMART test afterwards for confidence.

In either case you should check whether there are files in the directory you created, let us know, and delete them.
 
/df said:
Massive apologies for wasting your time. Apparently having noticed that I typed the name of the critical environment variable wrongly, I somehow let the wrong one through. It should have been E2FSCK_CONFIG, as now updated. And then really if that doesn't work, you just have to repeat the -P -y procedure until it succeeds; and maybe run a short SMART test afterwards for confidence.

In either case you should check whether there are files in the directory you created, let us know, and delete them.
Click to expand...
No probs. So it should have been E2FSCK_CONFIG=/var/lib/humaxtv_backup/mod/e2fsck.conf tmenu ?
If so, still no luck - I just tried that and got the "Memory allocation failed" error again:
humax fixdisk finished 4.jpg
 
So I seem to have hit a dead end - I have run fixdisk -2 -P -y several times now, and the last 3 times it has reported the same illegal block (#52467724) before hitting the memory allocation error and aborting. It is not currently reporting any other illegal blocks before aborting.
humax fixdisk same block.jpg

Any advice on where to go next?
 
Did you get to check the cache directory? Maybe TFM lies? But people have reported this configuration operating as expected without resolving the crash.

I don't remember the diagnostics about fix-disk.progress before, but probably not relevant.

How about taking off the -y, rejecting the attempt to fix 959908, and letting it try to fix the rest. There may be a way of fixing the problem inode with debugfs but that's a research issue.
 
/df said:
Did you get to check the cache directory? Maybe TFM lies? But people have reported this configuration operating as expected without resolving the crash.

I don't remember the diagnostics about fix-disk.progress before, but probably not relevant.

How about taking off the -y, rejecting the attempt to fix 959908, and letting it try to fix the rest. There may be a way of fixing the problem inode with debugfs but that's a research issue.
Click to expand...
Not sure how to go about checking the cache directory???

I tried fixdisk without the -y, and wasn't offered the option to ignore fixing block #52457724 - it "cleared" it without asking, then aborted with the memory allocation failure,humax fixdisk no-y.jpg as usual.
 
Follow the instructions as for creating the directory, but instead of the mkdir command ls -l /mnt/hd3/e2fscache[Enter].

To clear the directory, rm /mnt/hd3/e2fscache/*[Enter].
 
you could try
Code: 
find / -inum  1299709
to see which file/directory corresponds to the inode and manually deleting it with rm
 
Ian Manning said:
OK like this?
...
Click to expand...
Defo.

So that shows which failure mode we're in. Maybe your problem inode is so broken that it causes e2fsck to try to allocate more memory than is addressable. Maybe a newer e2fsprogs might do better, but as the set of ext2/3/4 users with 128MB RAM and 2TB+ drives may be quite small this sort of issue is probably not being addressed in the shiny new-ish 64-bit world.

I support the other suggestions above.
 
OK I have another (new) 2Tb drive I think I'll install that in the Humax and copy back the recordings from the current drive via USB
 
So I just installed the new 2TB drive, and reinstalled the full web IF. The first time I accessed the web IF I got this warning. The drive was bought as new from Amazon - a Seagate ST2000VM003. Do I need to return the drive?
humax hdd warning.jpg
 
Ian Manning said:
So I just installed the new 2TB drive, and reinstalled the full web IF. The first time I accessed the web IF I got this warning. The drive was bought as new from Amazon - a Seagate ST2000VM003. Do I need to return the drive?
...
Click to expand...
I believe this message always appears if the disk SMART statistics have changed. It should probably check that the disk is actually the same as the last one.

You could run the long test and review the SMART statistics after that to check the disk quality.
 
/df said:
I believe this message always appears if the disk SMART statistics have changed. It should probably check that the disk is actually the same as the last one.

You could run the long test and review the SMART statistics after that to check the disk quality.
Click to expand...
Thank God for that - thanks!
 
You must log in or register to reply here.
Back
Top