fix-disk: sda1 - Unrecognised partition type

[Erp_Is_Not_Spam]

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.

Sure thing, I'd be more than happy to!

 

[HarveyB]

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!

Just to remind you.
If you use FTP then the files will remain encrypted. This is fine if you only ever intend to put them back on the same Humax box to play in the future.

If you intend to play them elsewhere you should either:
- use the webif decrypt function first
Or
- copy them to USB drive (for HiDef you will need to flag them as decrypt first).


Sent from my iPad using Tapatalk HD

 

[Erp_Is_Not_Spam]

Hi,

It's the OP here, from nearly 10 weeks ago. Sadly the inevitable seems to have just happened, as my Humax hard-drive has just started exhibiting serious problems again - in fact pretty much any function that needs to access the hard-drive seems to lock-up the device, whilst making worrying hard-drive clicking noises.

Thankfully since my last troubles I've managed to ftp off almost all of my most important recordings, so if it is time to go for a brand new hard-drive then it'd be of no great loss.

However, I thought I'd give Maintenance mode a quick try again, just in case the problem was fixable...

So I rebooted into Maintenance mode, chose the fix-disk option, and after a short wait I got the following result:

Please select option: 1
Any additional options (or press return for none):
Are you sure you wish to run the hard disk checker? [Y/N] y
Running /bin/fix-disk
Custom firmware version 2.19
 
Checking disk sda
 
Unmounted /dev/sda1
Unmounted /dev/sda2
Unmounted /dev/sda3
 
Running short disk self test
Error at LBA 380394692
Using superblock 0 on sda1
Using superblock 0 on sda2
Using superblock 0 on sda3
Dev: /dev/sda LBA: 380394692
LBA: 380394692 is on partition /dev/sda2, start: 2104515, bad sector offset: 378290177
dumpe2fs 1.41.14 (22-Dec-2010)
Using superblock 0
Block size: 4096
LBA 380394692 maps to file system block 47286272 on /dev/sda2
 
Checking to see if this block is in use...
debugfs 1.41.14 (22-Dec-2010)
/dev/sda2: Can't read an block bitmap while reading block bitmap
testb: Filesystem not open
Unknown error
 
Press return to continue:

Can anyone advise me on what to try next? Or is this finally a lost cause?

Any help would be much appreciated, but I'll totally understand if there's none forthcoming - I've already had far more than my fair share here, after all!

Many thanks,

erp.

 

[xyz321]

Try CF version 2.20.

 

[Erp_Is_Not_Spam]

Try CF version 2.20.

Hi xyz! Thanks for the suggestion!

I've now installed CF 2.20 and am currently trying a fix-disk again. So far it's got further than last time, so the new CF has definitely helped.

It looks like it succeeded in "re-writing a sector" after it attempted to repair a bad-block.

It then went on to start a short self test, at which point it reported "Pending sector error(s) found" and "LBA has not yet been found", and then it moved onto a long self test instead.

So I guess I'll report back here in about 3 hours time with how that goes...

 

[Erp_Is_Not_Spam]

By the way, is there any way that I can re-start the long test so that it automatically answers "Yes" to any prompt to "Attempt repair of bad block?". That seems to be happening a lot...

 

[xyz321]

Not at the moment, maybe something to add to the next version.

 

[Erp_Is_Not_Spam]

Hi again,

More than 31 hours later, and the process is still going...

I'm long past the stage of repairing the bad blocks, and I'm now (apparently) searching for inodes and marking blocks as in use.

Here's the latest output from the session:

Dev: /dev/sda LBA: 522460386
LBA: 522460386 is on partition /dev/sda2, start: 2104515, bad sector offset: 520
355871
dumpe2fs 1.41.14 (22-Dec-2010)
Using superblock 0
Block size: 4096
LBA 522460386 maps to file system block 65044483 on /dev/sda2
 
Checking to see if this block is in use...
debugfs 1.41.14 (22-Dec-2010)
Block 65044483 is marked as in use
 
Searching for inode...
debugfs 1.41.14 (22-Dec-2010)
Block Inode number 65044483 <block not found>
Dev: /dev/sda LBA: 522460387
LBA: 522460387 is on partition /dev/sda2, start: 2104515, bad sector offset: 520
355872
dumpe2fs 1.41.14 (22-Dec-2010)
Using superblock 0
Block size: 4096
LBA 522460387 maps to file system block 65044484 on /dev/sda2
 
Checking to see if this block is in use...
debugfs 1.41.14 (22-Dec-2010)
Block 65044484 is marked as in use
 
Searching for inode...
debugfs 1.41.14 (22-Dec-2010)
Block Inode number 65044484 <block not found>
Dev: /dev/sda LBA: 522460388
LBA: 522460388 is on partition /dev/sda2, start: 2104515, bad sector offset: 520
355873
dumpe2fs 1.41.14 (22-Dec-2010)
Using superblock 0
Block size: 4096
LBA 522460388 maps to file system block 65044484 on /dev/sda2
 
Checking to see if this block is in use...
debugfs 1.41.14 (22-Dec-2010)
Block 65044484 is marked as in use
 
Searching for inode...
debugfs 1.41.14 (22-Dec-2010)
Block Inode number 65044484 <block not found>
Dev: /dev/sda LBA: 522460389
LBA: 522460389 is on partition /dev/sda2, start: 2104515, bad sector offset: 520
355874
dumpe2fs 1.41.14 (22-Dec-2010)
Using superblock 0
Block size: 4096
LBA 522460389 maps to file system block 65044484 on /dev/sda2
 
Checking to see if this block is in use...
debugfs 1.41.14 (22-Dec-2010)
Block 65044484 is marked as in use
 
Searching for inode...
debugfs 1.41.14 (22-Dec-2010)
Block Inode number 65044484 <block not found>
Dev: /dev/sda LBA: 522460390
LBA: 522460390 is on partition /dev/sda2, start: 2104515, bad sector offset: 520
355875
dumpe2fs 1.41.14 (22-Dec-2010)
Using superblock 0
Block size: 4096
LBA 522460390 maps to file system block 65044484 on /dev/sda2
 
Checking to see if this block is in use...
debugfs 1.41.14 (22-Dec-2010)
Block 65044484 is marked as in use
 
Searching for inode...
debugfs 1.41.14 (22-Dec-2010)
Block Inode number 65044484 <block not found>
Dev: /dev/sda LBA: 522460391
LBA: 522460391 is on partition /dev/sda2, start: 2104515, bad sector offset: 520
355876
dumpe2fs 1.41.14 (22-Dec-2010)
Using superblock 0
Block size: 4096
LBA 522460391 maps to file system block 65044484 on /dev/sda2
 
Checking to see if this block is in use...
debugfs 1.41.14 (22-Dec-2010)
Block 65044484 is marked as in use
 
Searching for inode...
debugfs 1.41.14 (22-Dec-2010)
Block Inode number 65044484 <block not found>
Dev: /dev/sda LBA: 522460392
LBA: 522460392 is on partition /dev/sda2, start: 2104515, bad sector offset: 520
355877
dumpe2fs 1.41.14 (22-Dec-2010)
Using superblock 0
Block size: 4096
LBA 522460392 maps to file system block 65044484 on /dev/sda2
 
Checking to see if this block is in use...
debugfs 1.41.14 (22-Dec-2010)
Block 65044484 is marked as in use
 
Searching for inode...
debugfs 1.41.14 (22-Dec-2010)
Block Inode number 65044484 <block not found>
Dev: /dev/sda LBA: 522460393
LBA: 522460393 is on partition /dev/sda2, start: 2104515, bad sector offset: 520
355878
dumpe2fs 1.41.14 (22-Dec-2010)
Using superblock 0
Block size: 4096
LBA 522460393 maps to file system block 65044484 on /dev/sda2
 
Checking to see if this block is in use...
debugfs 1.41.14 (22-Dec-2010)
Block 65044484 is marked as in use
 
Searching for inode...
debugfs 1.41.14 (22-Dec-2010)
Block Inode number 65044484 <block not found>
Dev: /dev/sda LBA: 522460394
LBA: 522460394 is on partition /dev/sda2, start: 2104515, bad sector offset: 520
355879
dumpe2fs 1.41.14 (22-Dec-2010)
Using superblock 0
Block size: 4096
LBA 522460394 maps to file system block 65044484 on /dev/sda2
 
Checking to see if this block is in use...
debugfs 1.41.14 (22-Dec-2010)
Block 65044484 is marked as in use
 
Searching for inode...
debugfs 1.41.14 (22-Dec-2010)
Block Inode number 65044484 <block not found>
Dev: /dev/sda LBA: 522460395
LBA: 522460395 is on partition /dev/sda2, start: 2104515, bad sector offset: 520
355880
dumpe2fs 1.41.14 (22-Dec-2010)
Using superblock 0
Block size: 4096
LBA 522460395 maps to file system block 65044485 on /dev/sda2
 
Checking to see if this block is in use...
debugfs 1.41.14 (22-Dec-2010)
Block 65044485 is marked as in use
 
Searching for inode...
debugfs 1.41.14 (22-Dec-2010)
Block Inode number 65044485 <block not found>
Dev: /dev/sda LBA: 522460396
LBA: 522460396 is on partition /dev/sda2, start: 2104515, bad sector offset: 520
355881
dumpe2fs 1.41.14 (22-Dec-2010)
Using superblock 0
Block size: 4096
LBA 522460396 maps to file system block 65044485 on /dev/sda2
 
Checking to see if this block is in use...
debugfs 1.41.14 (22-Dec-2010)
Block 65044485 is marked as in use
 
Searching for inode...
debugfs 1.41.14 (22-Dec-2010)
Block Inode number 65044485 <block not found>
Dev: /dev/sda LBA: 522460397
LBA: 522460397 is on partition /dev/sda2, start: 2104515, bad sector offset: 520
355882
dumpe2fs 1.41.14 (22-Dec-2010)
Using superblock 0
Block size: 4096
LBA 522460397 maps to file system block 65044485 on /dev/sda2
 
Checking to see if this block is in use...
debugfs 1.41.14 (22-Dec-2010)
Block 65044485 is marked as in use
 
Searching for inode...
debugfs 1.41.14 (22-Dec-2010)
Block Inode number 65044485 <block not found>
Dev: /dev/sda LBA: 522460398
LBA: 522460398 is on partition /dev/sda2, start: 2104515, bad sector offset: 520
355883
dumpe2fs 1.41.14 (22-Dec-2010)
Using superblock 0
Block size: 4096
LBA 522460398 maps to file system block 65044485 on /dev/sda2
 
Checking to see if this block is in use...
debugfs 1.41.14 (22-Dec-2010)
Block 65044485 is marked as in use
 
Searching for inode...
debugfs 1.41.14 (22-Dec-2010)
Block Inode number 65044485 <block not found>
Dev: /dev/sda LBA: 522460399
LBA: 522460399 is on partition /dev/sda2, start: 2104515, bad sector offset: 520
355884
dumpe2fs 1.41.14 (22-Dec-2010)
Using superblock 0
Block size: 4096
LBA 522460399 maps to file system block 65044485 on /dev/sda2
 
Checking to see if this block is in use...
debugfs 1.41.14 (22-Dec-2010)
Block 65044485 is marked as in use
 
Searching for inode...
debugfs 1.41.14 (22-Dec-2010)
Block Inode number 65044485 <block not found>
Dev: /dev/sda LBA: 522460400
LBA: 522460400 is on partition /dev/sda2, start: 2104515, bad sector offset: 520
355885
dumpe2fs 1.41.14 (22-Dec-2010)
Using superblock 0
Block size: 4096
LBA 522460400 maps to file system block 65044485 on /dev/sda2
 
Checking to see if this block is in use...
debugfs 1.41.14 (22-Dec-2010)
Block 65044485 is marked as in use
 
Searching for inode...
debugfs 1.41.14 (22-Dec-2010)
Block Inode number 65044485 <block not found>
Dev: /dev/sda LBA: 522460401
LBA: 522460401 is on partition /dev/sda2, start: 2104515, bad sector offset: 520
355886
dumpe2fs 1.41.14 (22-Dec-2010)
Using superblock 0
Block size: 4096
LBA 522460401 maps to file system block 65044485 on /dev/sda2
 
Checking to see if this block is in use...
debugfs 1.41.14 (22-Dec-2010)
Block 65044485 is marked as in use
 
Searching for inode...
debugfs 1.41.14 (22-Dec-2010)
Block Inode number 65044485 <block not found>
Dev: /dev/sda LBA: 522460402
LBA: 522460402 is on partition /dev/sda2, start: 2104515, bad sector offset: 520
355887
dumpe2fs 1.41.14 (22-Dec-2010)
Using superblock 0
Block size: 4096
LBA 522460402 maps to file system block 65044485 on /dev/sda2
 
Checking to see if this block is in use...
debugfs 1.41.14 (22-Dec-2010)
Block 65044485 is marked as in use
 
Searching for inode...
debugfs 1.41.14 (22-Dec-2010)
Block Inode number 65044485 <block not found>
Dev: /dev/sda LBA: 522460403
LBA: 522460403 is on partition /dev/sda2, start: 2104515, bad sector offset: 520
355888
dumpe2fs 1.41.14 (22-Dec-2010)
Using superblock 0
Block size: 4096
LBA 522460403 maps to file system block 65044486 on /dev/sda2
 
Checking to see if this block is in use...
debugfs 1.41.14 (22-Dec-2010)
Block 65044486 is marked as in use
 
Searching for inode...
debugfs 1.41.14 (22-Dec-2010)
Block Inode number 65044486 <block not found>
Dev: /dev/sda LBA: 522460404
LBA: 522460404 is on partition /dev/sda2, start: 2104515, bad sector offset: 520
355889
dumpe2fs 1.41.14 (22-Dec-2010)
Using superblock 0
Block size: 4096
LBA 522460404 maps to file system block 65044486 on /dev/sda2
 
Checking to see if this block is in use...
debugfs 1.41.14 (22-Dec-2010)
Block 65044486 is marked as in use
 
Searching for inode...
debugfs 1.41.14 (22-Dec-2010)
Block Inode number 65044486 <block not found>
Dev: /dev/sda LBA: 522460405
LBA: 522460405 is on partition /dev/sda2, start: 2104515, bad sector offset: 520
355890
dumpe2fs 1.41.14 (22-Dec-2010)
Using superblock 0
Block size: 4096
LBA 522460405 maps to file system block 65044486 on /dev/sda2
 
Checking to see if this block is in use...
debugfs 1.41.14 (22-Dec-2010)
Block 65044486 is marked as in use
 
Searching for inode...
debugfs 1.41.14 (22-Dec-2010)

Is it usual for this part of the process to take so long, or is this a sign that the disk is essentially irreparably damaged?

(Basically, is it time I called this quits?)

 

[xyz321]

More than 31 hours later, and the process is still going...

(Basically, is it time I called this quits?)

The process it is currently going through is supposed to show the names of any files which contain the bad blocks. It does take a long time but since you have quite a large number of bad blocks it will take a very long time.

I suggest you try to abort it with ctrl-C. When you get back to the prompt re-run fix-disk with the -B and -P options. These options will make it skip the initial tests and move to the file system checks.

 

[Erp_Is_Not_Spam]

Thanks for the quick advice xzy!

Sadly my telnet session doesn't currently seem to be responding to Ctrl-C...

 

[xyz321]

Try creating a new telnet session, then type 'killall fix-disk'.

 

[Erp_Is_Not_Spam]

I don't know whether it was because I closed my previous session beforehand, but when I started a new telnet session and tried the killall command you suggested, no such process was found. Even when I tried a ps command, no "fix-disk" process was listed.

Regardless, I've now kicked-off a fix-disk -B -P, and that's currently on its merry way...

 

[Erp_Is_Not_Spam]

Alright, so that fix-disk -B -P finished in fairly quick time, possibly "successfully" (?). I've attached the log to this message, although sadly Windows 8 Telnet doesn't seem to keep much history by default (I should clearly install Putty or something instead).

However, I've just exited Maintenance mode and rebooted the Humax, to see what its current status is. When I first went into the Media menu, it showed 100GB more than I expected in free space, and no recorded programs listed at all. Then when I rebooted for the second time, I could no longer even access the Media menu, and instead it showed a "The disk needs formatting to use recording features" message (or something to that effect)...

This sounds suspiciously like the error message I initially encountered when I wrote my first plea-for-help message here, but I'm not sure if the underlying cause is the same, so I don't know whether I should try out the exact same efforts to fix it (hdparm --repair-sector..., etc.)?

Any suggestions what to try next?

 

[xyz321]

That doesn't sound at all good. What is the SMART status of the disk?

smartctl -A /dev/sda

 

[Erp_Is_Not_Spam]

Oh no.

I'm afraid I'm not quite sure how to read the output, but here's the SMART status:

humax# smartctl -A /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 Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG    VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate    0x000f  100  100  006    Pre-fail  Always      -      7555
  3 Spin_Up_Time            0x0003  100  100  000    Pre-fail  Always      -      0
  4 Start_Stop_Count        0x0032  100  100  020    Old_age  Always      -      1
  5 Reallocated_Sector_Ct  0x0033  100  100  036    Pre-fail  Always      -      0
  7 Seek_Error_Rate        0x000f  100  253  030    Pre-fail  Always      -      0
  9 Power_On_Hours          0x0032  096  096  000    Old_age  Always      -      3530
10 Spin_Retry_Count        0x0013  100  100  097    Pre-fail  Always      -      0
12 Power_Cycle_Count      0x0032  099  099  020    Old_age  Always      -      1722
184 End-to-End_Error        0x0032  100  100  099    Old_age  Always      -      0
187 Reported_Uncorrect      0x0032  088  088  000    Old_age  Always      -      12
188 Command_Timeout        0x0032  100  253  000    Old_age  Always      -      0
189 High_Fly_Writes        0x003a  100  100  000    Old_age  Always      -      0
190 Airflow_Temperature_Cel 0x0022  071  071  045    Old_age  Always      -      29 (Min/Max 29/29)
194 Temperature_Celsius    0x0022  029  040  000    Old_age  Always      -      29 (Min/Max 0/29)
195 Hardware_ECC_Recovered  0x001a  100  100  000    Old_age  Always      -      7555
197 Current_Pending_Sector  0x0012  098  098  000    Old_age  Always      -      95
198 Offline_Uncorrectable  0x0010  098  098  000    Old_age  Offline      -      95
199 UDMA_CRC_Error_Count    0x003e  200  253  000    Old_age  Always      -      0
 
humax#

 

[xyz321]

Is this still the original (factory fitted) disk? The figures look reasonably good apart from attributes 197 & 198 which suggest it is still having problems reading some sectors. However, the raw read error rate looks very low in comparison to other disks.

 

[Erp_Is_Not_Spam]

Oh right! Yes, this is still the original disk. I haven't made any hardware changes, the only modification I've done is installed the CF.

 

[xyz321]

Here are some options (none of which are very satisfactory):

• Run fix-disk again - it will take a long time since there are still 95 sectors to fix. Also there is no guarantee of success; or
• Remove disk and connect to PC, then run Seatools to try to fix it; or
• Try a security erase. This will wipe all the data but you have probably lost everything anyway; or
• Fit a new disk - probably the safest option in the long term.

 

[Ezra Pound]

Interestingly, Line 194 suggests that the drive has never gone above 40 Deg. C which means the fan would have never turned on (unless forced on by the 'fan' utility), I wonder how it managed to keep so cool

 

[prpr]

Those SMART figures are all bizarre IMHO (0 seek error rate, 1 start/stop but 1772 power cycles, temperature, raw/recovered errors etc.).