fix-disk: sda1 - Unrecognised partition type

Erp_Is_Not_Spam

New Member
Hi,

Today my HDR-FOX-T2-1TB got the dreaded "The HDD storage must be formatted to use recording functions" error message. Of course I'd rather not do as the message instructs, as I'd rather not lose the hours of recordings stored on there.

So after reading around online for a while, I decided to install the Custom Firmware and try running the fix-disk command.

I ran fix-disk from MAINTENANCE mode, but sadly it didn't really work out very well. Here's the output I received:

Code:
Humax HDR-Fox T2 (humax) 1.02.32/2.19
 
To return to the menu, type: exit
 
humax# fix-disk
Running /bin/fix-disk
Custom firmware version 2.19
 
Checking disk sda
 
Running short disk self test
Error at LBA 3   
Partition sda1 - Unrecognised partition type, aborting...
humax#

Sadly I'm now at a loss as to what to try next. Is there anything else I can try, or do I just need to consign this disk to scrap?

Any help, advice or suggestions would be hugely appreciated.

Thanks in advance,

erp.
 
Code:
Error at LBA 3 
Partition sda1 - Unrecognised partition type, aborting...
humax#

Sadly I'm now at a loss as to what to try next. Is there anything else I can try, or do I just need to consign this disk to scrap?
Sounds like the partition table is on a dodgy sector. It should be fixable. Wait for expert advice.
 
In the absence of a hard disk guru, I would say there is probably something that can be typed in on the command line, that is, by telnetting into your HDR as you did to run fix-disk. I presume you did telnet in and got the HDR to re-boot into Maintenance mode before typing in 'fix-disk', as this is usually done via the Telnet Menu. It is worth waiting for a response from someone who can talk you through it, rather than going ahead and formatting the HDD
 
in the meantime run the fdisk -l command from the telnet prompt on the Humax as the partition table is probably corrupted and post the results

humax# fdisk -lu /dev/sda

you should get something like:

Disk /dev/sda: 1000 GB, 1000202273280 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953520065 sectors
Units = sectors of 1 * 512 = 512 bytes

Device Boot Start End Blocks Id System
/dev/sda1 2 2104514 1052226 83 Linux
/dev/sda2 2104515 1932539174 965209297 83 Linux
/dev/sda3 1932539175 1953520064 10482412 83 Linux


If you don't get something like the above then the partition table is corrupt.

The error message is unknown partition type, which should be Id 83, I don't see how that
can be wrong, but if it is you're in luck as it's dead easy to fix.

You can re-write the whole partition table back to the disk, but you need to know the exact sizes,
I've cut/pasted the above from a different thread so the start/end/blocks may be different from factory.

I hope somebody here can confirm the partition table and hopefully paste the commands to re-write it.
Depending, obviously what the result is of the fdisk -lu

Once the partition table has been restored you should be able to access the disk.
Get the recordings off it asap, save to usb drive or PC, and reformat the disk and check for errors

The first thing to do then is to run the fdisk -lu /dev/sda command
if that fails with an error message such as: can't open device
then if it's under warranty it needs to be returned,
outside of warranty you could check physical cable connections to drive, once powered off.
 
Hi guys,

Thanks for giving me at least a glimmer of hope!

Sadly I didn't have much luck with fdisk -lu, here's the output:

Code:
Humax HDR-Fox T2 (humax) 1.02.32/2.19
 
To return to the menu, type: exit
 
humax# fdisk -lu /dev/sda
fdisk: can't open '/dev/sda': Input/output error
humax#

However, I did manage to get something like the output that was suggested by guessing at a different command:

Code:
humax# fix-disk -B -F -P
Running /bin/fix-disk
Custom firmware version 2.19
 
Checking disk sda
 
Skipped pending sector error tests
Partition table is missing/corrupt. If the disk has not been formatted by
the Humax, recovery by fix-disk may not be successful.
 
Searching for partitions...
 
Partition 1 starts @ 2, ends @ 2104514
Partition 2 starts @ 2104515, ends @ 1932539174
Partition 3 starts @ 1932539175, ends @ 1953520064
Do you wish to attempt repair of the partition table? [Y/N]: y
 
/dev/sda:
re-reading partition table
fdisk: can't read from /dev/sda
New partition table has been created
fdisk: can't open '/dev/sda': Input/output error
 
File system checks skipped
humax#

I've no idea whether this is still useful information or not? I hope it is!

Thanks for your help so far!

erp.
 
Try the following;

hdparm --repair-sector 0 --yes-i-know-what-i-am-doing /dev/sda

Then re-run fix-disk without any additional parameters.

If this is successful then I would re-run fix-disk with the '-l' option (will take a few hours).

Edit: Actually thinking about it further. Running fix-disk with just the -l option may fix it without resorting to using the hdpam command above.


Scratch all that - see prpr's post #8 below.
 
Seeing as it was sector 3 that was being complained about, then I would try this:
Code:
hdparm --read-sector 3 /dev/sda
and if that gives the expected i/o error then this:
Code:
hdparm --repair-sector 3 --yes-i-know-what-i-am-doing /dev/sda

Not quite sure why fix-disk can't cope with this. It seems to try accessing the partition table before verifying that the disk surface is OK. This is doomed to failure if (as in this case) it seems to be the partition table that has the bad sector.
 
Yes, I am not sure how this bug crept in since I tested this scenario at one point. Moving the inode searches until after the SMART scan has completed is a better solution and will be included in the next version.

I will amend my previous post.
 
I'm not sure your suggestion to check sector 0 was wrong - it might be right. There may be problems with sectors 0 and 3.
I would try:
Code:
humax# badblocks -v /dev/sda 100 0
and see what it says.
 
From earlier experiments if sector 3 is marked as bad then it will have problems reading sector 0. If sector 3 is repaired then sector 0 should become readable.

The badblocks command can show false positives.
 
just a thought, comments welcome

can Erp dd the first 1k from /dev/sda and save it somewhere just in case, not really necessary and probably be difficult without a thumb drive.

and if somebody's got a factory 1TB disk, dd the first 1k, send it to Erp and let him dd it back onto /dev/sda, again from a thumb drive

or am I missing something here?
 
can Erp dd the first 1k from /dev/sda and save it somewhere just in case, not really necessary and probably be difficult without a thumb drive.
No because it will fail with I/O errors.
and if somebody's got a factory 1TB disk, dd the first 1k, send it to Erp and let him dd it back onto /dev/sda, again from a thumb drive
To be able to fix the disk low-level direct I/O has to be performed. The most reliable way is to use hdparm (which is also used by fix-disk).

Also some disks can have a slightly different partition table, so copying between machines may not be the best solution.
 
The badblocks command can show false positives.
So you've said before, but does it generate false negatives as well? If not, then if it runs and shows no problems, then we can assume all those sectors are good.
 
Hi guys,

Thanks enormously for your help so far!

I've ran the commands you've suggested, and below is a full copy of the output:

Code:
humax# hdparm --read-sector 3 /dev/sda
 
/dev/sda:
reading sector 3: FAILED: Input/output error
 
humax# hdparm --repair-sector 3 --yes-i-know-what-i-am-doing /dev/sda
 
/dev/sda:
re-writing sector 3: succeeded
 
humax# badblocks -v /dev/sda 100 0
 
Checking blocks 0 to 100
Checking for bad blocks (read-only test): 0 0.00% done, 0:08 elapsed
1 1.00% done, 0:24 elapsed
2 2.00% done, 0:32 elapsed
3 3.00% done, 0:40 elapsed
4 4.00% done, 0:48 elapsed
5 5.00% done, 0:56 elapsed
6 6.00% done, 1:03 elapsed
7 7.00% done, 1:11 elapsed
done                               
Pass completed, 8 bad blocks found.

I'm afraid I am no good at interpreting these results though; so it looks like sector 3 has been repaired, but I'm guessing it's not completely fixed? And there are some bad blocks on the disk, but where and on which sector?

Any further advice would be hugely appreciated!

Thanks again,

erp.
 
Ah, still not much joy:
Code:
humax# fix-disk

Running /bin/fix-disk
Custom firmware version 2.19
 
Checking disk sda
 
Running short disk self test
Error at LBA 9   
Partition sda1 - Unrecognised partition type, aborting...

Although this error is at a different LBA value than before... Is that a good thing?

(Also, should I have supplied any parameters?)
 
OK, you need to fix LBA 9 using:

Code:
hdparm --repair-sector 9 --yes-i-know-what-i-am-doing /dev/sda

Then re-run fix-disk again.
 
Ok, here are the results for LBA 9:
Code:
humax# hdparm --repair-sector 9 --yes-i-know-what-i-am-doing /dev/sda
 
/dev/sda:
re-writing sector 9: succeeded
 
humax# fix-disk
 
Running /bin/fix-disk
Custom firmware version 2.19
 
Checking disk sda
 
Running short disk self test
Error at LBA 4   
Partition sda1 - Unrecognised partition type, aborting...

Should I now repeat for LBA 4?
 
Back
Top