fix-disk: sda1 - Unrecognised partition type

Ok, I just had to repeat the process for 4, 5, 6 & 7, and now fix-disk has got a little further:
Code: 
Running /bin/fix-disk
Custom firmware version 2.19
 
Checking disk sda
 
Running short disk self test
                 
No pending sectors found - skipping sector repair
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]:

Should I answer Yes?
 
Ok! It looks like fix-disk is now giving this its best shot - it's currently at 40% through pass 1 of sda2.

So I have a slightly off-topic question: I'm working on this from my laptop, so I was just worried about what might happen if I for some reason lose my wi-fi connection? Will I be able to telnet back in and start receiving the output from the process again? If not, how will I be able to tell that it's finished?
 
If you lose the connection it will probably abort. If you then telnet in it will always be a new session (you can have multiple telnet connections).

When convenient you may want to do a long test using fix-disk -l. This should pick any remaining problems with the disk but note that it will take several hours to run. It takes over two hours on my 500G box.
 
Thanks for the info xyz321! I will will try my damnedest to stay connected then.

Alright, fix-disk has finished, and here's the output:
Code: 
Running /bin/fix-disk
Custom firmware version 2.19
 
Checking disk sda
 
Running short disk self test
                 
No pending sectors found - skipping sector repair
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
New partition table has been created
 
Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
 
  Device Boot      Start        End      Blocks  Id System
/dev/sda1              2    2104514    1052256+ 83 Linux
/dev/sda2        2104515  1932539174  965217330  83 Linux
/dev/sda3      1932539175  1953520064    10490445  83 Linux
 
 
Checking partition /dev/sda3...
e2fsck 1.41.14 (22-Dec-2010)
/dev/sda3: recovering journal
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure                                         
Pass 3: Checking directory connectivity
/lost+found not found.  Create? yes
 
Pass 4: Checking reference counts
Pass 5: Checking group summary information                                   
                                                                             
/dev/sda3: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sda3: 13/655776 files (0.0% non-contiguous), 239244/2622611 blocks
 
Checking partition /dev/sda1...
e2fsck 1.41.14 (22-Dec-2010)
e2fsck: Superblock invalid, trying backup blocks...
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure                                         
Pass 3: Checking directory connectivity
/lost+found not found.  Create? yes
 
Pass 4: Checking reference counts
Pass 5: Checking group summary information                                   
Free blocks count wrong for group #0 (24038, counted=24037).
Fix? yes
 
Free blocks count wrong for group #1 (32243, counted=30903).
Fix? yes
 
Free blocks count wrong (250398, counted=249057).
Fix? yes
 
Free inodes count wrong for group #0 (7301, counted=7300).                   
Fix? yes
 
Free inodes count wrong for group #1 (7312, counted=7310).
Fix? yes
 
Directories count wrong for group #1 (0, counted=1).
Fix? yes
 
Free inodes count wrong (65797, counted=65794).
Fix? yes
 
/dev/sda1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sda1: 14/65808 files (7.1% non-contiguous), 14007/263064 blocks
 
Creating swap file...
Setting up swapspace version 1, size = 1073737728 bytes
UUID=759b6653-9b26-4e09-be1d-449c0f1ce73f
 
Checking partition /dev/sda2...
e2fsck 1.41.14 (22-Dec-2010)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure                                         
Pass 3: Checking directory connectivity                                       
/lost+found not found.  Create? yes                                           
 
Pass 4: Checking reference counts
Pass 5: Checking group summary information                                   
                                                                             
/dev/sda2: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sda2: 1573/60334080 files (28.9% non-contiguous), 231924371/241304332 blocks
Removing extra swap space.
Are you having problems with a delete loop? [Y/N]: n
Skipped
 
Finished

I'm not knowingly experiencing a delete loop, so I hope it's OK that I said No to that...
 
You're right! It's worked! Thank you so very much! Both you and prpr have been so incredibly, unbeievably helpful. And thanks to everyone else who replied too!

You've already done so much that I feel kinda bad to ask any more questions... but, what would you recommend I do now? Are these problems a sign that the disk is on its way out and I should backup as soon as possible? Or is it possible that it'll run fine OK now for a good while longer?

And, finally, with regards to backing-up encrypted HD recordings, if I were to copy them to a new drive, and use that drive to replace the current troubled drive in the Humax, would the encrypted content play again? Or is it somehow tied to the drive itself?

Thank you, thank you, thank you.
 
An encrypted recording will play on the same Humax only, regardless of what media you play it from (could even be a USB stick). If you use FTP to extract the .hmt files for HiDef recordings, pass them through Foxy on a PC, and put them back - the recordings will then be decrypted on USB copy just like StDef recordings,
 
Erp_Is_Not_Spam said:
Are these problems a sign that the disk is on its way out and I should backup as soon as possible? Or is it possible that it'll run fine OK now for a good while longer?
Click to expand...
It depends. Using the web interface of the custom firmware Under Diagnostics>Hard drive. What are the Raw Values of ID 5 (reallocated sector count), ID 9 (Power on hours), ID 197 (Current_pending_sector0, 198 (Offline Uncorrectable)?
 
I hadn't had the full web interface installed, but I've just done it now (I hope that wasn't actually a foolish thing to do on a potentially-dying drive! I should've thought that one through first...)

Here are the values asked for:
Code: 
5 Reallocated_Sector_Ct PO--CK 0
9 Power_On_Hours -O--CK 3406
197 Current_Pending_Sector -O--C- 0
198 Offline_Uncorrectable ----C- 0

Is this... good?
 
Erp_Is_Not_Spam said:
Is this... good?
Click to expand...
All looks good to me. We recently had a failing drive and as an experiment I persisted with it longer than felt safe. In our case the drive steadily reallocated sectors at a rate of about 2 or three a day (with experience you could spot the reallocations as a brief stutter in playback) until it reached about 1500 reallocated sectors at which point the rate of reallocation began to rise rapidly and the box became unpleasant to use and I replaced the drive. The significant difference is that in our case the reallocations were being managed automatically by the drive and were in sectors used purely for data; the impact is much more severe if it affects the partition table (as you found) or any of the other data structures (INodes etc) used by the file system. Personally I would persevere with this drive and see how it goes.
 
Those figures look OK.
I would repeat the badblocks test if I were you and if sectors 1 and 2 still report bad then try reading/fixing those as well (I think you did all the rest).
Then you need to do a long Smart test (using "fix-disk -l" as xyz321 suggested or the following):
Code: 
humax# smartctl -t long /dev/sda
It'll probably take 4-5 hours to run I'd guess and you can get the results using:
Code: 
humax# smartctl -l selftest /dev/sda
and report back. You can do this in normal operation mode - it doesn't require maintenance mode. It should hopefully say something like this:
Code: 
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error      00%      5294        -
 
xyz321 said:
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.
Click to expand...
Could I make another request please... make it respond to "fix-disk -h" in normal mode, not just maintenance mode.
 
Hey prpr,

Running badblocks again finished almost instantaneously, and seemingly with success:
Code: 
humax# badblocks -v /dev/sda 100 0
Checking blocks 0 to 100
Checking for bad blocks (read-only test): done                                
Pass completed, 0 bad blocks found.

Was I right to use the same parameters as last time? Or should I have done it without any this time?

I'm going to set the long test going overnight, and I'll see what comes back in the morning!
 
Since the problems appear to be at the beginning of the disk I would say that your recordings should be reasonably safe. The first partition (which was the only one showing errors) only contains the epg. If you do find that is corrupt then you can delete the epg files on /mnt/hd1 since they will be regenerated.
 
Ok, so I think the long test has come back OK:
Code: 
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error      00%      3410        -

Here's the full output:
Code: 
humax# smartctl -l selftest /dev/sda
 
smartctl 5.41 2011-06-09 r3365 [7405b0-smp-linux-2.6.18-7.1] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net
 
=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error      00%      3410        -
# 2  Short offline      Completed without error      00%      3405        -
# 3  Short offline      Completed: read failure      90%      3405        7
# 4  Short offline      Completed: read failure      90%      3405        6
# 5  Short offline      Completed: read failure      90%      3405        5
# 6  Short offline      Completed: read failure      90%      3404        4
# 7  Short offline      Completed: read failure      90%      3404        9
# 8  Short offline      Completed: read failure      90%      3403        3
# 9  Short offline      Completed: read failure      90%      3403        3
#10  Short offline      Completed: read failure      90%      3403        3
#11  Short offline      Completed: read failure      90%      3403        3
#12  Short offline      Completed: read failure      90%      3403        3
#13  Short offline      Completed: read failure      90%      3403        3
#14  Extended offline    Completed: read failure      90%      3403        3
#15  Short offline      Completed: read failure      90%      3403        3
#16  Short offline      Completed: read failure      90%      3403        3
#17  Short offline      Completed: read failure      90%      3403        3
#18  Short offline      Completed: read failure      90%      3403        3
#19  Short offline      Completed: read failure      90%      3403        3
17 of 17 failed self-tests are outdated by newer successful extended offline self-test # 1

I must admit this did at first look quite worrying to my inexperienced eyes, but would I be right in saying that it's only result #1 that I need to pay attention to, as it supersedes the other (earlier) results?
 
Yes, it is only the first result you need to look at. The previous test results will have come from earlier fix-disk runs.
 
Fantastic! Things are looking pretty good then, it seems! Oh this makes me really happy. :)

I think I'm going to FTP off some choice recordings this afternoon, just for peace of mind's sake.

Thanks again for the help, everyone!
 
Erp_Is_Not_Spam said:
Fantastic! Things are looking pretty good then, it seems! Oh this makes me really happy. :)

I think I'm going to FTP off some choice recordings this afternoon, just for peace of mind's sake.
Click to expand...
Good plan. Please keep us posted how this works out say in 3 months time if no further problems. I would like to formulate some guide lines on when the hard drives should be replaced.
 
You must log in or register to reply here.
Back
Top