Current_Pending_Sector/Offline_Uncorrectable errors - will fix-disk help?

[Ian Manning]

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:

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)

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.

 

[prpr]

fix-disk uses a swap file to gain memory headroom for scanning the large partition, but it's obviously not enough.

So why not use a bigger swap file instead?

 

[/df]

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!"

 

[prpr]

Oh, yes, how dopey of me. I see it already allocates 1G worth of space...

 

[Ian Manning]

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:

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)

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:

 

[/df]

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.

 

[Ian Manning]

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.

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:

 

[Ian Manning]

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.


Any advice on where to go next?

 

[/df]

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.

 

[Ian Manning]

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.

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, as usual.

 

[/df]

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].

 

[Ian Manning]

OK like this?

 

[Ian Manning]

So I cleared the cache folder (rm /mnt/hd3/e2fscache/*)
...and re-ran fixdisk but it ended exactly the same way:

 

[prpr]

Any advice on where to go next?

It sounds to me like the time has come to backup, re-make the filesystem (re-format) on /dev/sda2, and restore.

 

[MymsMan]

you could try

find / -inum  1299709

to see which file/directory corresponds to the inode and manually deleting it with rm

 

[/df]

OK like this?
...

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.

 

[Ian Manning]

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

 

[Ian Manning]

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?

 

[/df]

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?
...

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.

 

[Ian Manning]

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.

Thank God for that - thanks!