Recover Recordings instead of Formatting HDD

pomwombat

New Member
Hi all,

I'm new here, gradually evolving the family PVR environment from a Toppy with MyStuff over to a Fox T2 with customised firmware, but I'm only partly into the process...

Our HDR Fox T2 was running a little strangely last night... playback was suddenly very jerky, and the box was extremely slow to respond to the remote - even minutes to change a channel. I stopped playback, but I couldn't just power down, as a recording was in progress.

When, eventually, I could put the box into a proper shutdown, followed by a power cycle, it came back indicating that the HDD needs reformatting. No space available, no space used, and no recordings.

I'd rather make an attempt to recover the recordings, so I wanted to check what my options are nowadays, before I started fiddling with it. I found an old thread on this subject from 2 years ago, but I figure things may have changed a little.

It is a 1TB box, about 4 months old and still in warranty. I bought it with the intention of putting the custom firmware on, but only after I was sure it was going to keep working for a while - so the custom firmware isn't there yet.

As far as I can see, my options are:
- To try the standard Humax settings option to test the HDD
- To install the custom firmware, and use the "fix-disk" utility
- To take the HDD out, put it into a PC and use standard Linux HDD tools to recover things
- To give up, and re-format.

Am I missing anything there?

I'm erring towards the option of installing the custom firmware, and using the "fix-disk" utility. Is that an option for me, given that there won't be a disk available for any package manipulation?

Cheers
 
I'm erring towards the option of installing the custom firmware, and using the "fix-disk" utility. Is that an option for me, given that there won't be a disk available for any package manipulation?
Yes custom software fix-disk is your best option. The main part of the custom software installs in flash memory so the disk being unavailable isn't an issue,
 
Hmmm. That didn't go too well, for a first effort:

Code:
Running /bin/fix-disk
Custom firmware version 2.22
 
Checking disk sda
 
Unmounted /dev/sda1
Partition /dev/sda2 is already unmounted
Partition /dev/sda3 is already unmounted
/bin/fix-disk: line 511: arithmetic syntax error
 
Press return to continue:

I retried, but the only difference was that /dev/sda1 was already unmounted.

Should I try one of the options to perform a self-test? I guess, as a couple of partitions were mounted, the disk is at least semi-functioning.
 
af123 and xyz321 are the acknowledged experts for this sort of thing, I'm sure they will be along to advise...
 
Ta.

I've been in with the CLI, and taken a look. The whole system behaves *almost* like /dev/sda doesn't exist. The disk does power up, and spin up.

- "fdisk -l /dev/sda" returns an error:
Code:
humax# fdisk -l /dev/sda
fdisk: can't open '/dev/sda': Input/output error

- e2fsck returns errors for all 3 partitions:
Code:
humax# e2fsck /dev/sda1
e2fsck 1.41.14 (22-Dec-2010)
e2fsck: Attempt to read block from filesystem resulted in short read while trying to open /dev/sda1
Could this be a zero-length partition?

I can't find a mention of /dev/sda in /var/log/maintenance.boot.log

I can find a mention of /dev/sda in /var/log/rag.log
Code:
humax# cat rag.log
 
--------- Info for Modinit PID 345 ---------
345: Date:      Sat Jan  1 00:00:18 UTC 2000
345: MDEV:      sda1
345: ACTION:    add
345: Model:      HDR
345: Device:    /dev/sda1
345: Disk:      sda
 
 
--------- Info for Modinit PID 353 ---------
353: Date:      Sat Jan  1 00:00:18 UTC 2000
353: MDEV:      sda3
353: ACTION:    add
353: Model:      HDR
353: Device:    /dev/sda3
353: Disk:      sda
 
353:01/01/2000 00:00: Waiting for disk to become ready...
345:01/01/2000 00:00: Waiting for disk to become ready...
 
--------- Info for Modinit PID 348 ---------
348: Date:      Sat Jan  1 00:00:18 UTC 2000
348: MDEV:      sda2
348: ACTION:    add
348: Model:      HDR
348: Device:    /dev/sda2
348: Disk:      sda
 
348:01/01/2000 00:00: sda2 is candidate for mod [/mnt/hd2]
348:01/01/2000 00:00: Waiting for disk to become ready...
345:01/01/2000 00:00:  disk ready after 0 seconds
348:01/01/2000 00:00:  disk ready after 0 seconds
345:01/01/2000 00:00: /dev/sda1 is formatted as ext2/3
345:01/01/2000 00:00: /dev/sda1 is NOT removable.
345:01/01/2000 00:00: Waiting for the disk to mount...
348:01/01/2000 00:00: /dev/sda2 is formatted as ext2/3
348:01/01/2000 00:00: /dev/sda2 is NOT removable.
348:01/01/2000 00:00: Waiting for the disk to mount...
353:01/01/2000 00:00:  disk ready after 0 seconds
353:01/01/2000 00:00: /dev/sda3 is formatted as ext2/3
353:01/01/2000 00:00: /dev/sda3 is NOT removable.
353:01/01/2000 00:00: Waiting for the disk to mount...
345:01/01/2000 00:00:  /dev/sda1 mounted on /mnt/hd1
345:01/01/2000 00:00:  mounted after 0 seconds.
345:01/01/2000 00:00: Waiting for modinit to complete.
348:01/01/2000 00:00:  still waiting...
345:01/01/2000 00:00:  still waiting...
353:01/01/2000 00:00:  still waiting...
345:01/01/2000 00:00:  still waiting...
348:01/01/2000 00:00:  still waiting...

The last messages continue for a while longer.

I should note that I'm doing this with the aeial unplugged. That shouldn't make a difference to something this basic, should it?
 
I've done an extra bit of tracing, by looking at the fix-disk script.

It looks like the system believes /dev/sda exists as a disk - it is present in /sys/block, and /dev/block/sda includes entries for sda1, sda2 and sda3; all with reasonable size and start values.
It thinks it is a PCI device, with a size.

However, doing almost anything with the device returns an I/O error. But not quite everything...

Code:
humax#
humax# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/root                21888     21888         0 100% /
tmpfs                    62492        32     62460   0% /tmp
tmpfs                    62492         0     62492   0% /media
/dev/mtdblock1            2048       544      1504  27% /var/lib/humaxtv
/dev/mtdblock2            2048      1236       812  60% /var/lib/humaxtv_backup
/dev/sda1              1035692     37252    945828   4% /mnt/hd1
humax#
humax#
humax# dd if=/dev/sda of=/dev/zero bs=512 count=1
dd: /dev/sda: Input/output error
humax# dd if=/dev/sda1 of=/dev/zero bs=512 count=1
1+0 records in
1+0 records out
512 bytes (512B) copied, 0.000000 seconds, 16.0EB/s
humax# dd if=/dev/sda2 of=/dev/zero bs=512 count=1
dd: /dev/sda2: Input/output error
humax# dd if=/dev/sda3 of=/dev/zero bs=512 count=1
dd: /dev/sda3: Input/output error
humax#
humax#
humax#
humax# dd if=/dev/sda1 of=/dev/zero bs=512 count=10
10+0 records in
10+0 records out
5120 bytes (5.0KB) copied, 0.000000 seconds, 16.0EB/s
humax# dd if=/dev/sda1 of=/dev/zero bs=512 count=20
20+0 records in
20+0 records out
10240 bytes (10.0KB) copied, 0.000311 seconds, 31.4MB/s
humax# dd if=/dev/sda1 of=/dev/zero bs=512 count=30
30+0 records in
30+0 records out
15360 bytes (15.0KB) copied, 0.000408 seconds, 35.9MB/s
humax# dd if=/dev/sda1 of=/dev/zero bs=512 count=40
dd: /dev/sda1: Input/output error
humax#

In 20+ years of dealing with Linux, I don't think I've come across a disk that behaves quite like this. Should I expect the disk to be manipulated on the Humax in a fairly standard way? Looking on the forum, and looking through the fix-disk script, suggests it ought to work as any other Linux system.

The disk looks totally U/S, but it could of course be something on the system board or cable. That leaves me with a catch22 as to whether to try removing the disk to retrieve the recordings, or to return the box under warranty... if I can find the receipt!
 
Oh, and should this thread be moved over to the CF forum now? I guess I've moved a little away from the standard firmware.
 
Ta.

I tried that this evening: It looks like it starts listing every block number, until it gets to 29311179, and then ends "Killed". I didn't kill it though.

I tried a second time. It has reached 29343710 so far, but stopped outputting anything. Now it gives the appearance of having crashed - it doesn't respond to ctrl-c, or a new telnet session. I then rebooted...

If I restrict badblocks to the first 100 blocks, and then run it on sda, sda1, sda2 and sda3, I get results that match an earlier post: I get a few blocks OK from sda1, followed by failures, but all the others fail entirely.

Code:
humax# badblocks -v -o /dev/zero /dev/sda 100
Checking blocks 0 to 100
Checking for bad blocks (read-only test): done
Pass completed, 101 bad blocks found.
 
humax# badblocks -v -o /dev/zero /dev/sda1 100
Checking blocks 0 to 100
Checking for bad blocks (read-only test): done
Pass completed, 94 bad blocks found.
 
humax# badblocks -v -o /dev/zero /dev/sda2 100
Checking blocks 0 to 100
Checking for bad blocks (read-only test): done
Pass completed, 101 bad blocks found.
 
humax# badblocks -v -o /dev/zero /dev/sda3 100
Checking blocks 0 to 100
Checking for bad blocks (read-only test): done
Pass completed, 101 bad blocks found.

and

Code:
humax# badblocks -v /dev/sda1 100
Checking blocks 0 to 100
Checking for bad blocks (read-only test): 0 0.00% done, 0:00 elapsed
8
9
10
11
12
...
98
99
100
done
Pass completed, 94 bad blocks found.
 
Weird. I'd have the disk out and in a PC to repeat the tests, just to pin down whether it is the disk or the Humax at fault.
 
You both hit the conundrum there.

If it were outside warranty, the disk would have already been in the PC. But it is inside warranty, so ought to go back.

But there are two little gotchas:

- The recordings are a "nice to have" but by no means essential; some of them are still being recorded in parallel (in SD) on the old Toppy.
- Humax no longer make the Fox T2, yet it is still the best option for stepping away from the Toppy (which, with MyStuff, is downright excellent at handling searches for things to record, and for scheduling those recordings)

If I were reasonably sure that it was just the disk that was faulty, I'd contemplate ignoring the warranty, at the cost of (worst case) a new, larger disk. With Fox T2's being discontinued, the best I could replace it is a refurbished or used one anyway.

However, the symptoms would allow for problems with the interface hardware; for that I'd probably rather return it and take my chances on a refurb.

It is still bizarre that the disk can be read sufficiently well for it to identify the 3 partitions, and include them in /sys, yet can't read sector 0 using CLI. It is bizarre that the first 15 blocks of /dev/sda1 are readable, yet the same blocks are unreadable through device /dev/sda. My natural curiosity *wants* to take it out and put it in a PC to fathom things out further, but I think it is probably better to send it back.

Unless someone can suggest some other things to try with the disk in situ...
 
BTW...

When I choose the option to "Test disk" from the Humax on-screen menus, the system reboots.

I haven't yet asked it to reformat, as I still hold out hope that I can save the recordings. However, if I want to return it, I guess I'm going to have to perform that step. Even though I expect it to fail equally.
 
Are your recordings decrypted? If not (as I suspect), then they are effectively gone already, as you can only decrypt them in that particular Humax, but that particular combo of disk and Humax aren't working.
You have nothing to lose by formatting, and probably nothing to gain either (apart from satisfying the droids who deal with warranty returns) as the disk blocks aren't going to fix themselves by whatever filesystem init. the Humax software performs.
 
I would have though that, if the encrypted files could be extracted from the old drive and copied back to the same Humax (with a new replacement drive), that the Humax would still be able to decrypt these files
 
It would, but seemingly either the disk is toast or the Humax is, and you need both parts working to make it decrypt.

If the old drive is working, then what do you achieve by copying it to a new drive and putting that in the Humax?
If the old drive isn't working, then you've lost your files already.
Either way, you've lost your files.
I thought I'd explained this in #17, but you seem to want to argue the toss about logic.
 
The last thing in the world I would do is waste my time arguing with you. If some or all of the files can be extracted then they are not " effectively gone already" are they
 
Back
Top