• The forum software that supports hummy.tv will be upgraded to XenForo 2.3 on Wednesday the 20th of November 2024 starting at 7pm

    There will be some periods where the forum is unavailable, please bear with us. More details can be found in the upgrade thread.

Error when running fixdisk

GlassMan

New Member
Hi,

My hard disk suffered a major failure recently, which caused all the recordings to disappear. I ran a fixdisk, which found and fixed a lot of errors during the short & long self tests, but then ended in error. When I now run it, it ends with the below error.

It has fixed the disk enough to bring back the recorded programmes, and it is mostly working OK, although it has the odd bit of corruption during playback of recordings. I suspect the HD is on it's way out, but just wanted to get a complete run of the fixdisk to hopefully prolong it's life a little longer.

Code:
Please select option: fixdisk
Any additional options (-h for list or press return for none): -y -d
Are you sure you wish to run the hard disk checker (-y -d)? [Y/N] y
Running /bin/fix-disk
PART: [3 1 2]
FSCKOPTS: []

Checking disk sda (512 byte sectors)

Unmounted /dev/sda1
Unmounted /dev/sda2
Unmounted /dev/sda3


Running short disk self test

Pending sector error(s) found

LBA has not yet been found
A long test is required - this could take 1 hour(s) 54 minutes
Do you wish to continue? [Y/N]: Y
Running long disk self test
                  
Error - pending sectors but LBA not found
fix-disk: session terminated with exit status 1

Press return to continue:
 
Can you post the information from the disk diagnostics page in the web interface?

The error means that the disk firmware is reporting that there is one/are some faulty sectors somewhere, but a long disk test failed to find it/them. There are other ways to try and detect them but let's start by seeing how bad it is.
 
Thanks for your help, I've attached the output in PDF format, the Reallocated_Sector_Ct is looking pretty grim!!
 

Attachments

  • Humax HDR Fox T2 (humax) - Diagnostics.pdf
    194.4 KB · Views: 24
Thanks for your help, I've attached the output in PDF format, the Reallocated_Sector_Ct is looking pretty grim!!
The reallocated sector count is high and I am inclined to say that you should be considering replacing the hard drive but your immediate problem is probably related to attribute 198 offline_uncorrectable count of 5. What version of the custom firmware are you running?
 
The reallocated sector count is high and I am inclined to say that you should be considering replacing the hard drive but your immediate problem is probably related to attribute 198 offline_uncorrectable count of 5. What version of the custom firmware are you running?
Custom firmware version: 3.13 (build 4028)
Humax Version: 1.03.12 (kernel HDR_CFW_3.13)

I think you're correct about the drive needing replacing, although I'm wondering about going for FVP-5000T instead, but I wanted to see if it would continue for a bit longer if I addressed the disk issues.
 
I think you're correct about the drive needing replacing, although I'm wondering about going for FVP-5000T instead, but I wanted to see if it would continue for a bit longer if I addressed the disk issues.
It will probably continue for a bit longer. The thing to monitors is the rate per day that sectors are being reallocated. The 32% life remaining against Reallocated_sectors suggest to me that there are about another 900 sectors left in the pool and after that the problems will be much worse. Wait for one of the experts to explain how to find and fix the offline uncorrectable sectors.

I have an FVP-5000T and it is a Marmite box; some people hate them, some people are reasonably happy with them. For me the major virtue of the FVP is that subtitles work properly which as I get older is becoming ever more important. The ability to record three (or even four things at once) is occasionally useful as is the ability to download SD content to a Windows 10 computer decrypted. The down sides are that the user interface has an awful lot of inconsistencies, the box is slower to respond to the remote than the HDR and the recording performance is worse than the HDR when the EPG is being frequently updated due to a previous programme over running.

Personally I grit my teeth and use the FVP for most things. Somebody recently suggested that Humax had an improved FVP like box in the works. I have no idea if that is true but if it is, it might be worth prolonging the life of the HDR a bit.
 
If you want to join the many moaning about the FVP-5000T, then go ahead and buy one.

OOPS. You just beat me to it Martin.
 
Thanks for your help.

I've run the fixdisk with the -P option to skip the smart test, result below:

Code:
      /---------------------------------------------\
      |  M A I N T E N A N C E   M O D E   M E N U  |
      \---------------------------------------------/

  [ Humax HDR-Fox T2 (humax) 1.03.12/3.13 ]

 fixdisk - Check and repair hard disk.
   short - Run short hard-disk self test.
    long - Run long hard-disk self test.
   check - Check self-test progress.
    gptf - Re-format disk using GPT scheme.
     epg - Clear persistent EPG data.
    dlna - Reset DLNA server database.
       x - Leave maintenance mode (Humax will restart).
    diag - Run a diagnostic.
     cli - System command line (advanced users).

Please select option: fixdisk
Any additional options (-h for list or press return for none): -P -y
Are you sure you wish to run the hard disk checker (-P -y)? [Y/N] y
Running /bin/fix-disk

Checking disk sda (512 byte sectors)

Unmounted /dev/sda1
Unmounted /dev/sda2
Unmounted /dev/sda3

Skipped pending sector error tests

Checking partition tables...

MBR Status: MBR only
GPT Status: not present

Using superblock 0 on sda1
Using superblock 0 on sda2
Using superblock 0 on sda3


Fri Jan 17 16:50:57 GMT 2020: Checking partition /dev/sda3...
e2fsck 1.42.13 (17-May-2015)
Pass 1: Checking inodes, blocks, and sizes
Pass 1: Memory used: 240k/0k (157k/84k), time:  9.83/ 3.89/ 2.61
Pass 1: I/O read: 164MB, write: 0MB, rate: 16.68MB/s
Pass 2: Checking directory structure
Pass 2: Memory used: 340k/0k (260k/81k), time:  0.01/ 0.00/ 0.01
Pass 2: I/O read: 1MB, write: 0MB, rate: 122.38MB/s
Pass 3: Checking directory connectivity
Peak memory: Memory used: 340k/0k (260k/81k), time: 10.47/ 4.16/ 2.66
Pass 3A: Memory used: 340k/0k (260k/81k), time:  0.00/ 0.00/ 0.00
Pass 3A: I/O read: 0MB, write: 0MB, rate: 0.00MB/s
Pass 3: Memory used: 340k/0k (259k/82k), time:  0.00/ 0.00/ 0.00
Pass 3: I/O read: 0MB, write: 0MB, rate: 0.00MB/s
Pass 4: Checking reference counts
Pass 4: Memory used: 340k/0k (53k/288k), time:  0.99/ 0.97/ 0.01
Pass 4: I/O read: 0MB, write: 0MB, rate: 0.00MB/s
Pass 5: Checking group summary information
Pass 5: Memory used: 340k/0k (53k/288k), time:  2.66/ 1.92/ 0.05
Pass 5: I/O read: 1MB, write: 0MB, rate: 0.38MB/s

          18 inodes used (0.00%, out of 655776)
           0 non-contiguous files (0.0%)
           0 non-contiguous directories (0.0%)
             # of inodes with ind/dind/tind blocks: 3/2/0
      372651 blocks used (14.21%, out of 2622611)
           0 bad blocks
           1 large file

           7 regular files
           2 directories
           0 character device files
           0 block device files
           0 fifos
           0 links
           0 symbolic links (0 fast symbolic links)
           0 sockets
------------
           9 files
Memory used: 340k/0k (53k/288k), time: 14.15/ 7.05/ 2.73
I/O read: 166MB, write: 1MB, rate: 11.73MB/s
Fri Jan 17 16:51:12 GMT 2020

Fri Jan 17 16:51:12 GMT 2020: Checking partition /dev/sda1...
e2fsck 1.42.13 (17-May-2015)
Superblock has an invalid journal (inode 8).
Clear? yes

*** ext3 journal has been deleted - filesystem is now ext2 only ***

Pass 1: Checking inodes, blocks, and sizes
Journal inode is not in use, but contains data.  Clear? yes

Inode 47 has illegal block(s).  Clear? yes

Illegal indirect block (25691658) in inode 47.  CLEARED.
Illegal indirect block (4195160) in inode 47.  CLEARED.
Illegal indirect block (4026988550) in inode 47.  CLEARED.
Illegal indirect block (3758548998) in inode 47.  CLEARED.
Illegal indirect block (3490109446) in inode 47.  CLEARED.
Illegal indirect block (3221669894) in inode 47.  CLEARED.
Illegal indirect block (2953230342) in inode 47.  CLEARED.
Illegal indirect block (2684790790) in inode 47.  CLEARED.
Illegal indirect block (4161775623) in inode 47.  CLEARED.
Illegal indirect block (3893358607) in inode 47.  CLEARED.
Illegal indirect block (3624919055) in inode 47.  CLEARED.
Too many illegal blocks in inode 47.
Clear inode? yes

Inode 40 has illegal block(s).  Clear? yes

Illegal indirect block (12189714) in inode 40.  CLEARED.
Illegal indirect block (118358287) in inode 40.  CLEARED.
Illegal indirect block (722211853) in inode 40.  CLEARED.
Illegal indirect block (1275739659) in inode 40.  CLEARED.
Illegal indirect block (2198363401) in inode 40.  CLEARED.
Illegal indirect block (3121002759) in inode 40.  CLEARED.
Illegal indirect block (4127514373) in inode 40.  CLEARED.
Illegal indirect block (922948612) in inode 40.  CLEARED.
Illegal indirect block (2701323266) in inode 40.  CLEARED.
Illegal indirect block (3120603905) in inode 40.  CLEARED.
Illegal indirect block (1686175744) in inode 40.  CLEARED.
Too many illegal blocks in inode 40.
Clear inode? yes

Inode 15 has illegal block(s).  Clear? yes

Illegal block #13 (8454158) in inode 15.  CLEARED.
Illegal block #14 (3725452814) in inode 15.  CLEARED.
Illegal block #15 (3507217932) in inode 15.  CLEARED.
Illegal block #16 (2617885194) in inode 15.  CLEARED.
Illegal block #17 (1409775112) in inode 15.  CLEARED.
Illegal block #18 (553990662) in inode 15.  CLEARED.
Illegal block #19 (3523405571) in inode 15.  CLEARED.
Illegal block #20 (2164310017) in inode 15.  CLEARED.
Illegal block #44 (2168095232) in inode 15.  CLEARED.
Illegal block #45 (51459301) in inode 15.  CLEARED.
Illegal block #46 (33817602) in inode 15.  CLEARED.
Too many illegal blocks in inode 15.
Clear inode? yes

Inode 13 has illegal block(s).  Clear? yes

Illegal block #13 (6094864) in inode 13.  CLEARED.
Illegal block #14 (3960339214) in inode 13.  CLEARED.
Illegal block #15 (940328461) in inode 13.  CLEARED.
Illegal block #16 (2836033547) in inode 13.  CLEARED.
Illegal block #17 (3037244169) in inode 13.  CLEARED.
Illegal block #18 (2600902919) in inode 13.  CLEARED.
Illegal block #19 (2416218629) in inode 13.  CLEARED.
Illegal block #20 (1526891267) in inode 13.  CLEARED.
Illegal block #21 (1560304129) in inode 13.  CLEARED.
Illegal block #35 (2172158208) in inode 13.  CLEARED.
Illegal block #36 (51473342) in inode 13.  CLEARED.
Too many illegal blocks in inode 13.
Clear inode? yes

Pass 1: Memory used: 144k/0k (66k/79k), time: 11.26/ 0.36/ 0.44
Pass 1: I/O read: 17MB, write: 1MB, rate: 1.51MB/s
Recreate journal? yes

Creating journal (8192 blocks):  Done.

*** journal has been re-created - filesystem is now ext3 again ***
Restarting e2fsck from the beginning...
Pass 1: Checking inodes, blocks, and sizes
Pass 1: Memory used: 144k/0k (65k/80k), time: 11.07/ 0.39/ 0.43
Pass 1: I/O read: 17MB, write: 0MB, rate: 1.54MB/s
Pass 2: Checking directory structure
Entry '#15' in /lost+found (12) has deleted/unused inode 15.  Clear? yes

Entry '#40' in /lost+found (12) has deleted/unused inode 40.  Clear? yes

Entry '#47' in /lost+found (12) has deleted/unused inode 47.  Clear? yes

Entry '#13' in /lost+found (12) has deleted/unused inode 13.  Clear? yes

Pass 2: Memory used: 144k/0k (75k/70k), time:  0.12/ 0.00/ 0.00
Pass 2: I/O read: 1MB, write: 0MB, rate: 8.20MB/s
Pass 3: Checking directory connectivity
Peak memory: Memory used: 144k/0k (76k/69k), time: 26.48/ 1.01/ 1.61
Pass 3A: Memory used: 144k/0k (76k/69k), time:  0.00/ 0.00/ 0.00
Pass 3A: I/O read: 0MB, write: 0MB, rate: 0.00MB/s
Pass 3: Memory used: 144k/0k (75k/70k), time:  0.00/ 0.00/ 0.00
Pass 3: I/O read: 0MB, write: 0MB, rate: 0.00MB/s
Pass 4: Checking reference counts
Pass 4: Memory used: 144k/0k (53k/92k), time:  0.13/ 0.13/ 0.00
Pass 4: I/O read: 0MB, write: 0MB, rate: 0.00MB/s
Pass 5: Checking group summary information
Block bitmap differences:  -(527--8728) -18416 -(18432--18433) -(19584--19585) -(21847--21849) -21854 -(24931--24937) -(24939--24943) -(25416--25599) -(26106--26157) -(28077--28350) -(28464--28671) +32494 -(34890--34958) -36024
Fix? yes

Free blocks count wrong for group #0 (2414, counted=15169).
Fix? yes

Free blocks count wrong for group #1 (28697, counted=28767).
Fix? yes

Free blocks count wrong (212404, counted=225229).
Fix? yes

Inode bitmap differences:  -13 -15 -40 -47
Fix? yes

Free inodes count wrong for group #0 (7278, counted=7282).
Fix? yes

Free inodes count wrong (65771, counted=65775).
Fix? yes

Pass 5: Memory used: 144k/0k (52k/93k), time:  1.01/ 0.69/ 0.01
Pass 5: I/O read: 1MB, write: 1MB, rate: 0.99MB/s

/dev/sda1: ***** FILE SYSTEM WAS MODIFIED *****

          33 inodes used (0.05%, out of 65808)
          19 non-contiguous files (57.6%)
           0 non-contiguous directories (0.0%)
             # of inodes with ind/dind/tind blocks: 20/20/0
       37835 blocks used (14.38%, out of 263064)
           0 bad blocks
           1 large file

          21 regular files
           3 directories
           0 character device files
           0 block device files
           0 fifos
           0 links
           0 symbolic links (0 fast symbolic links)
           0 sockets
------------
          24 files
Memory used: 144k/0k (52k/93k), time: 27.64/ 1.84/ 1.62
I/O read: 17MB, write: 1MB, rate: 0.61MB/s
Fri Jan 17 16:51:40 GMT 2020

Creating swap file...
Setting up swapspace version 1, size = 1073737728 bytes
UUID=583d0edb-8946-491d-abf0-8c17d8dc3b7a

Fri Jan 17 16:52:06 GMT 2020: Checking partition /dev/sda2...
e2fsck 1.42.13 (17-May-2015)
Pass 1: Checking inodes, blocks, and sizes
Pass 1: Memory used: 1476k/4672k (1144k/332k), time: 1345.31/775.33/85.69
Pass 1: I/O read: 7518MB, write: 0MB, rate: 5.59MB/s
Pass 2: Checking directory structure
Pass 2: Memory used: 1476k/9344k (1130k/347k), time:  2.42/ 0.60/ 0.14
Pass 2: I/O read: 5MB, write: 0MB, rate: 2.06MB/s
Pass 3: Checking directory connectivity
Peak memory: Memory used: 1476k/9344k (1130k/347k), time: 1368.92/793.82/85.93
Pass 3A: Memory used: 1476k/9344k (1143k/334k), time:  0.00/ 0.00/ 0.00
Pass 3A: I/O read: 0MB, write: 0MB, rate: 0.00MB/s
Pass 3: Memory used: 1476k/9344k (1126k/351k), time:  0.15/ 0.04/ 0.00
Pass 3: I/O read: 1MB, write: 0MB, rate: 6.64MB/s
Pass 4: Checking reference counts
Pass 4: Memory used: 1476k/0k (1080k/397k), time: 56.13/55.22/ 0.10
Pass 4: I/O read: 0MB, write: 0MB, rate: 0.00MB/s
Pass 5: Checking group summary information
Pass 5: Memory used: 1984k/0k (1068k/917k), time: 153.06/118.56/ 1.39
Pass 5: I/O read: 29MB, write: 0MB, rate: 0.19MB/s

        7606 inodes used (0.03%, out of 29860704)
         217 non-contiguous files (2.9%)
          11 non-contiguous directories (0.1%)
             # of inodes with ind/dind/tind blocks: 341/150/15
    60088052 blocks used (50.41%, out of 119209984)
           0 bad blocks
          48 large files

        5882 regular files
         354 directories
           0 character device files
           0 block device files
           0 fifos
           2 links
        1361 symbolic links (1361 fast symbolic links)
           0 sockets
------------
        7599 files
Memory used: 1984k/0k (1068k/917k), time: 1578.36/967.64/87.42
I/O read: 7552MB, write: 1MB, rate: 4.78MB/s
Fri Jan 17 17:18:25 GMT 2020
Removing extra swap space.

Finished
fix-disk: session terminated with exit status 0

Press return to continue:
 
I've run the fixdisk with the -P option to skip the smart test, result below:
So what does the disk diagnostic look like now? It looks as though the problems were in Partition 1 which is used for EPG data and the DLNA database so the recordings should be fine.
 
I Also ran a "badblocks -s -b 512 /dev/sda", which ended with no errors:

Code:
humax# which badblocks
/sbin/badblocks
humax# badblocks -s -b 512 /dev/sda
Checking for bad blocks (read-only test): done
humax#

The bad blocks seem to have gone now:

1579289108868.png
 
Just run a complete fixdisk which ended without error, so looking OK I think........apart from the high reallocated count!
Personally I grit my teeth and use the FVP for most things. Somebody recently suggested that Humax had an improved FVP like box in the works. I have no idea if that is true but if it is, it might be worth prolonging the life of the HDR a bit.

Thanks for this, with a bit of luck it will carry on working for a while and I'll keep my eye out for new Humax devices.
 
Just run a complete fixdisk which ended without error, so looking OK I think........apart from the high reallocated count!

Yes, it looks ok now and there is no way to tell how it will do from now on. You may have just had a one-off flurry of bad sectors which are now remapped.

Thanks for this, with a bit of luck it will carry on working for a while and I'll keep my eye out for new Humax devices.

If you do end up replacing it, please consider offering it to people here for refurbishment or spares.
 
At one point, my own hard drive had severe issues, I removed the hard drive from the Humax Fox-T2 and placed it in my old Apple Macintosh Mac Pro, I have a small hard drive with a Linux distro which is able to read the filesystem of a Humax drive (all the other hard drive(s) are disconnected), so just the small capacity Linux boot drive, the Humax drive and a destination drive

You can then copy all your recordings off your Humax drive (/dev/sda2) on to a suitably sized disk, then using the Linux distro of your choice, use the erase all partitions option, you can also run some surface scanning software to search for bad blocks (sectors), if the surface test is successful, return the hard drive to the Humax and do a new drive install, install your custom firmware environment, then you can ftp all your recordings back to the Humax

(An old desktop PC would suffice, but needs SATA, but ideally, a fast(ish) processor and a realistic amount of RAM)

I use an old Buffalo Terastation four drive raided server as a Humax recordings back-up, so regularly FTP between my Humax and the Terastation
 
Just run a complete fixdisk which ended without error, so looking OK I think........apart from the high reallocated count!
Interesting that the reallocated sector count didn't increase when you fixed the offline uncorrectable sectors. I agree that the way forward is to just keep an eye on the reallocated sector count. As the problems reported previously were in one small partition then if future problems were to occur in the same location then a possible radical way to extend the life would be to move the partition boundaries around to leave the problematic region unused.
 
At one point, my own hard drive had severe issues, I removed the hard drive from the Humax Fox-T2 and placed it in my old Apple Macintosh Mac Pro, I have a small hard drive with a Linux distro which is able to read the filesystem of a Humax drive (all the other hard drive(s) are disconnected), so just the small capacity Linux boot drive, the Humax drive and a destination drive

You can then copy all your recordings off your Humax drive (/dev/sda2) on to a suitably sized disk, then using the Linux distro of your choice, use the erase all partitions option, you can also run some surface scanning software to search for bad blocks (sectors), if the surface test is successful, return the hard drive to the Humax and do a new drive install, install your custom firmware environment, then you can ftp all your recordings back to the Humax
That is certainly a way to do it but what advantage does it have compared to running the repair on the Humax itself?
 
I hadn't heard of such a facility until recently, fixdisk does a lot, but can only do so much if the hard drive inodes etc are very badly messed up, it appears that the inode structure is not related to the recording made, all the fixdisk is doing is checking all the linux housekeeping flags are in order, I had to run fixdisk on my long serving Humax Fox-T2, (the one that has had many replacement hard drives, it took about four days to finally stop showing errors or more accurately, inaccuracies or inconsistencies, the Humax then became faster at showing directory listings, moved between directories faster and there also seemed to be less picture breakups while watching a recording

A fixdisk run has just been completed this morning following a reported system crash event in the web-if page, the run took 1hr 20mins, time depends also on how full your recordings drive is, having too many non series recordings at the root level can impede performance, so move to a related folder, eg sports, movies, diy or motoring

The other smaller partitions sd1 and sd3, though small are even more important if used for the system itself

Attached are some screen grabs from an FTP programme of my long serving Humax Fox-T2, you will see in hd1, this shows the dvbepg file, hd2 shows the three main folder, My Video, My Photo and My Music, the last pic shows a bit more folder structure and a webif folder, so if the directory structure housekeeping system is messed up or out of sync, then performance will suffer, a bit like trying the ready a street map with some areas damaged by water drops blurring the map
 

Attachments

  • file structure hd1.JPG
    file structure hd1.JPG
    19.4 KB · Views: 5
  • file structure hd2.JPG
    file structure hd2.JPG
    19.2 KB · Views: 4
  • file structure webif.JPG
    file structure webif.JPG
    19.6 KB · Views: 4
all the fixdisk is doing is checking all the linux housekeeping flags are in order
Correct, but nonetheless it has been available within the CF for many years and has solved many people's problems without having to remove the HDD. Surface scans were useful in the old days when a drive was just that and the driver electronics were on the interface board in your computer, but now all the controller stuff is on-board the HDD itself, with complex mapping schemes calibrated at factory to map out defective blocks, it isn't recommended to go messing with that (even if such facilities are accessible).
 
Back
Top