e2fsck hang on /dev/sda2

I know sda1,2 and 3 are not checked automatically, even though tune2fs shows that they should be. I've been negligent and haven't run the maintenance mode command "1 - Check and repair hard disk (fix-disk)" for about a year.

My humax has recently been hanging, and ignoring all remote control actions (even power off), and refusing to stop from the front panel power button. (I suspect the original cause was a series of power cuts and spikes associated with the transit of Tropical Cyclone Marcia.)

The web interface seems to work OK in most respects, except the simulated remote control app, which logs the power off command but nothing happens. I can enter and exit maintenance mode, and also issue the cli reboot command, but it returns to its dumb state within a minute or so.

When I run the check and repair (or e2fsck directly), the process always hangs at 11.1% on sda2. My humax has a 1TB disk, so I've tried waiting a few hours, but the progress indicator stays the same and phase 1 never completes.

It is running 1.02.29 firmware, which I believe is the latest. I experienced the problem with custom firmware 1.02.32-mod-2.17, which uses e2fsck 1.41.14. I found a couple of reference to phase 1 hangs which talked about a bug, so upgraded to custom firmware 1.03.12-mod-3.02 which installs e2fsck 1.42.10. I have reviewed the changelog and none of the later fixes for e2fsck seem relevant to my problem. e2fsck 1.42.10 also hangs at exactly the same point, 11.1% during phase 1.

I have used the web interface to delete quite a lot of recent recordings (which I have previously backed up), and the free space indication has increased by an appropriate amount. Currently there is about 200 GB free.

However, e2fsck still stubbornly hangs at the same point. I am dreading sucking all the files off the disk and reformatting it. Does anyone have any suggestions?
 
I think that's probably your only option really.
I've reached the point where I've deleted 1/4 TB of programs, so the disk is now about 60% full. However, e2fsck is still hanging forever at 11%. This makes me think the problem is an undetected loop in the free block chain, because the content of the disk appears to be playable, accessible, and the free space increases appropriately as I delete more files. I am 99% convinced I need to empty and reformat the partition.

Most of the remaining files are ts's. Under normal circumstances, I would wget each ts from the program info using the dnla server component, so that they would be decrypted and playable on other devices. I noticed the latest firmware tools include rsync... do you think the encryption logic will tolerate me rsyncing the raw files and then restoring them to the disk when it has been reformatted? (I remember windoze used to mix-in all sorts of hardware data to protect its license, so I am worried the humax might be equally unfriendly).
 
I noticed the latest firmware tools include rsync... do you think the encryption logic will tolerate me rsyncing the raw files and then restoring them to the disk when it has been reformatted?
As long as you put them back on the original box, you will be fine. (Decrypting them as they are recorded would be better as you never need to worry about it again, but that's for the future.)
You can use rsync, FTP, Samba, NFS, USB. Anything will do to get them off the disk. Some of these will decrypt as they go and some won't. Make sure you copy the .hmt and .nts files as well though (DLNA won't).
 
The only thing that matters re decryption is the machine itself, plus the .hmt sidecar file that goes with the .ts.

(prpr beat me to it)
 
The only thing that matters re decryption is the machine itself, plus the .hmt sidecar file that goes with the .ts.
(prpr beat me to it)
Thanks for letting me know. I expected the encryption to rely only on the machine itself (probably its serial number). However, it would be a real problem if it also depended on the disk drive after discovering I needed to swap the device for a new one!

In my case the hdparm statistics show the disk hardware is fine, so I could have rsync'd the encrypted files quickly and then put them back after reformatting the partition. Because I can't help being paranoid I decided to offload them via the DNLA server and then use avprobe to confirm the individual files are playable anywhere. Boy, that took a long time!
 
I now have only about 8 of the 800 GB left on the disk. I will copy those remaining programs tomorrow morning and then reformat the /dev/sda2 partition when the machine is idle and I have lots of spare time... I want to leave sda1 and sda3 as-is, so will not use the humax disk format "feature".

I've compared the tune2fs output from the humax and my linux laptop. As far as I can tell the file systems are very similar, with my laptop formatted as ext3. However, the magic of 0xEF53 could correspond to ext2, ext3 or ext4. The features include has_journal, so that means ext3 or ext4. With a little digging I discovered the cli mount command (with no arguments) lists the file systems of all mounted devices. /dev/sda2 is definitely ext3, so now I know how to reformat the single partition.
 
However, the magic of 0xEF53 could correspond to ext2, ext3 or ext4. The features include has_journal, so that means ext3 or ext4. With a little digging I discovered the cli mount command (with no arguments) lists the file systems of all mounted devices. /dev/sda2 is definitely ext3, so now I know how to reformat the single partition.
Not sure why you are digging for this information. This af123 blog post http://wiki.hummy.tv/wiki/2TB_Disk_Installation_Blog gives lots of information on the recommended file system options and specifically:

mkfs.ext3 -m 0 -O sparse_super -T largefile /dev/sda2
 
Not sure why you are digging for this information. This af123 blog post http://wiki.hummy.tv/wiki/2TB_Disk_Installation_Blog gives lots of information on the recommended file system options and specifically:

mkfs.ext3 -m 0 -O sparse_super -T largefile /dev/sda2
Thanks... I read the original posts on that topic about 3 years ago, but forgot that it mentioned the format command arguments. I tend to go back to linux basics when in doubt, but you have saved me the rest of the work!

I was trying to make this (my) thread useful to anyone looking at it later, so thanks for the link to the wiki. That will make it more useful.
 
I was trying to make this (my) thread useful to anyone looking at it later, so thanks for the link to the wiki. That will make it more useful.
Understood. For the record the 2TB drive in our HDR-FOX T2 was formatted using the commands in the af123 blog 18 months ago and has given no problems.
 
The reformat of sda2 was successful. However, I had overlooked the fact that the custom firmware uses the /mod directory on that partition, so I had not backed it up. Once I rebooted the humax worked fine, but the web interface had gone! It was replaced by a friendly invitation to reinstall, so I didn't mind much. It was a timely opportunity to install the packages that I use regularly, and also to review my settings.

I set up dropbear sshd for incoming client connections using only key exchange authentication. This is all documented elsewhere, but it took me a little while to discover that the authorized_keys file needs to be in /mod/.ssh/ (/root/.ssh is the standard location, but it is on a read-only file system). rsync from my linux laptop to the humax worked very well, so the machine is working normally again. A recent e2fsck when the partition was half-full completed all its 5 phases smoothly.

Thanks to everyone who helped me recover from the crisis.
 
Back
Top