1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

sda1 recovery failed - zero length partition

Discussion in 'HD/HDR-FOX T2 Customised Firmware' started by Brian Burch, Dec 26, 2012.

  1. Brian Burch

    Brian Burch Member

    e2fsck: Attempt to read block from filesystem resulted in short read while trying to open /dev/sda1
    Could this be a zero-length partition?
    Some background:
    Humax HDR Fox T2 with 1TB disk is about 5 months old.
    Firmware is 1.02.29
    Custom Firmware is 2.13

    Suddenly got the pop-up saying HDD must be formatted for no apparent reason. Can't find any of the 400GB recorded programs and cannot use any pvr features on live TV.

    I telnet via ethernet cable connection from my linux client. I ran fix-disk and the humax rebooted into MAINTENANCE mode on its display. I reconnected with telnet. I ran fix-disk again, but it immediately aborted saying sda1 had an unrecognised partition type.

    /proc/scsi/scsi says I have a ST31000424CS ATA drive at Rev: SC13.
    /proc/partitions lists sda, sda1, sda2, sda3
    e2fsck /dev/sda1 failed again with the message at the top of this post.

    e2fsck /dev/sda3 kept failing when I replied "y" to create lost+found, but ran successfully when I replied "n". The error was "memory allocation failed while trying to read bitmaps". sda3 is currently in "clean" state according to tune2fs. When I mount it on /mnt/hd3 it only contains cookie.txt (and an empty lost+found directory, so I must have got lucky!)

    e2fsck /dev/sda2 takes a long time to run, and if I reply "y" to create the lost+found directory, it always fails with the "read bitmaps" message. I ran it again, replied "n", and was relieved to find it completed all 5 phases. The report said the partition still has errors. tune2fs said the filesystem was not clean, but it did contain 1800 files and 118 directories.

    I mounted the partition on /mnt/HD2 and manually created a lost+found directory. I chmod'd it to match the other directories on the file system. I was VERY relieved to find the "My Video" directory contained a lot of my recordings. After umount, e2fsck ran successfully. Phew!

    I feel that I have achieved 90% recovery. Presumably I can ftp these files off the disk (I realise they are encrypted) and put them back later. It will take a long time, even on a 100 mbs LAN. I suspect all will be back to normal if I could only fix sda1...

    humax# fdisk -l /dev/sda
    fdisk: can't open '/dev/sda': Input/output error
    Worries me a lot because it should be reading the partition table, which is (presumably) telling the system that I have sda1, sda2, sda3 and allowing me to check the file systems on 2 and 3.

    and I still get these errors.
    humax# tune2fs -l /dev/sda1
    tune2fs 1.41.14 (22-Dec-2010)
    tune2fs: Attempt to read block from filesystem resulted in short read while trying to open /dev/sda1
    Couldn't find valid filesystem superblock.
    humax# e2fsck -v /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?
    So, not surprisingly, I still get this:
    humax# fix-disk
    Partition 1 - Unrecognised partition type, aborting...
    Do you think fdisk is just confused by the zero-length sda1, or is the partition table really corrupt?

    What ought to be on a clean sda1? Can I recover or recreate it?
  2. af123

    af123 Administrator Staff Member

    It does sound like you're almost there. Usually checking a 1TB disk needs a swap file creating somewhere (fix-disk uses the third partition temporarily for this) which explains the out of memory errors you were seeing.

    sda1 contains EPG data and information about background operations - nothing you care about and if it can be formatted again the Humax should recreate everything necessary.

    Have you tried gfdisk? That should be installed with CFW 2.13

    humax# gfdisk -l /dev/sda
    You can run fix-disk just on a single partition but you seem to have sda2 and sda3 in order. CFW 2.14 has some improvements in that area too, but I don't think they would help with this particular problem.

    Edit: Don't worry about the lost+found directories. A disk formatted via the Humax software doesn't have them. They're created by e2fsck ready to hold any recovered inodes.
  3. Brian Burch

    Brian Burch Member

    That is very reassuring for me. Thank you for replying so quickly.

    Good to know, but having the lost+found allows e2fsck to mark the big partition as clean, so it was worth doing.

    I haven't come across gfdisk before - I used fdisk because it is part of the busybox package. The gfdisk report is more helpful, but equally scary!
    Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
    Building a new DOS disklabel. Changes will remain in memory only,
    until you decide to write them. After that, of course, the previous
    content won't be recoverable.
    Disk /dev/sda: 1000 GB, 1000202273280 bytes
    255 heads, 63 sectors/track, 121601 cylinders
    Units = cylinders of 16065 * 512 = 8225280 bytes
       Device Boot      Start         End      Blocks   Id  System 
    Now that you have explained the contents of sda1, I would be happy to reformat it. However, the partition table looks corrupt and I'm really worried that formatting sda1 (as ext3, I presume) might trash sda2 with all my precious recordings...
  4. af123

    af123 Administrator Staff Member

    Yes, I think you are going to have to archive the recordings off over the LAN or to a USB disk just in case.

    If /proc/partitions shows you the number of blocks on each of sda1,2,3 then I think the way forward is to recreate the partition table, probably using gfdisk. It isn't a one-to-one mapping though. If you search on here for fdisk you'll find partition table (fdisk -lu) output that other people have posted from their 1TB disks. If you get it the same as it was and are able to write it to the disk then you should be able to format sda1 and be back in business with all recordings intact. Presumably there is something there though as you're able to check and repair sda2 & sda3.

    Here's mine from a 2TB - the blocks in /proc/partitions don't match the fdisk output but are close.

    humax# grep sda /proc/partitions
      8    0 1953514584 sda
      8    1    1052256 sda1
      8    2 1941969300 sda2
      8    3  10490444 sda3
    humax# gfdisk -l /dev/sda
    Disk /dev/sda: 2000 GB, 2000396321280 bytes
    255 heads, 63 sectors/track, 243201 cylinders
    Units = cylinders of 16065 * 512 = 8225280 bytes
      Device Boot      Start        End      Blocks  Id  System
    /dev/sda1              1        132    1060258  83  Linux
    /dev/sda2            132      241896  1941969330  83  Linux
    /dev/sda3          241896      243201    10482412  83  Linux
    You can have several goes until tune2fs is still happy to read sda2,sda3!

    To reformat sda1 once you're happy with the partition table, do:

    humax# mkfs.ext3 -m 0 -O sparse_super /dev/sda1
  5. af123

    af123 Administrator Staff Member

    Here's a post with partition information for a 1TB disk in it:


    humax# fdisk -lu
    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
  6. Brian Burch

    Brian Burch Member

    Wow! Don't you have a home to go to? It is Boxing Day evening where I am in the UK. I'm looking at this forum because my humax is wrecked, but you must be some sort of angel!

    Here is what I get...
    humax# cat partitions
    major minor  #blocks  name
      31    0      24576 mtdblock0
      31    1      2048 mtdblock1
      31    2      2048 mtdblock2
      31    3      1664 mtdblock3
      31    4        384 mtdblock4
      31    5      2048 mtdblock5
      31    6      32768 mtdblock6
      8    0  976762584 sda
      8    1    1052256 sda1
      8    2  965217330 sda2
      8    3  10490445 sda3
    I'm very encouraged. These block counts match the 1 TB fdisk layout (that you posted above) exactly.

    I'll spend several hours tomorrow pulling the encrypted files off the humax with ftp as you suggest. I don't want to lose them after so much work.

    Is it right that these files will NEVER be playable on a different humax machine? I MUST put them back on this disk drive, or on a different disk drive in the SAME machine, if I ever want to play them again? (My humax currently will not run the web server from the custom firmware, so I am not able to capture them as decrypted streams).

    IF I get this sorted out, I need to get the smartmontools installed so I can find out whether the disk drive is failing - at the moment I don't know.
  7. Black Hole

    Black Hole Felonius Gru

    Unless you decrypt them first, yes.
  8. Brian Burch

    Brian Burch Member

    This worked very well for me - it recursed through all the subdirectories too.
    wget --ftp-user=humaxftp --ftp-password=0000 --recursive protocol+hostname+directory
    where protocol is "ftp://" and hostname is "humax.mydomain" and the directory is "'/My Video'" (must be quoted to prevent the shell breaking the argument at the space character).
    That is annoying because I just wanted to be helpful. The forum editor will not allow me to put a trivial url into my post, so I was forced to break it into its components! I'm not sure it is helpful any more.
  9. Black Hole

    Black Hole Felonius Gru

    What if you enclosed it in plain.../plain tags?
  10. Brian Burch

    Brian Burch Member

    No, that isn't permitted for me: "spam protection until you have made 10 posts" to this forum. I am about half-way there at the moment!

    Because so much of that wget command is applicable to all users, I thought it would be nice to let people cut'n'paste it direct to their shell prompt. If you agree, perhaps you could de-obfuscate it for me?
  11. Black Hole

    Black Hole Felonius Gru

    I'll try:

    wget --ftp-user=humaxftp --ftp-password=0000 --recursive 'ftp://humax.mydomain/My Video'

    (must be quoted to prevent the shell breaking the argument at the space character).
  12. Brian Burch

    Brian Burch Member

    My backup is complete, although I cannot be sure of its quality because (as we already new) the files on my desktop system are encrypted. I even tried putting some SD programs onto a usb stick, but the humax is not able to find anything... although that might be because it hasn't got a valid sda yet.

    I started to reconstruct the partition table with gfdisk, but was unable to make it match the example from the 1TB system above. When I looked closely, I could see that my 1TB drive is slightly different.
    Disk /dev/sda: 1000 GB, 1000202273280 bytes
    255 heads, 63 sectors/track, 121601 cylinders, total 1953520065 sectors
    Units = sectors of 1 * 512 = 512 bytes
    The example given earlier was a disk with 1000.2 GB and 1000204886016 bytes.

    I feel it is crucial to get sda2 (the media partition) exactly right, otherwise the existing filesystem I am trying to recover will not map properly. I searched this forum for my exact disk size and only got one other hit, "manual-format-of-hdd.2730" (post-32854). Unfortunately, the OP had partition alignment problems and so I do not trust the numbers.

    /proc/partitions gives the partition sizes, but not the boundaries. tune2fs gives the blocksizes of sda2 and sda3, but the units don't seem to be the same as those used by gfdisk.

    Is there somewhere else (perhaps in /proc?) where I can find the start boundaries that tune2fs is currently using?

    If I were to actually let the humax reformat my disk, the partition definitions MUST be stored somewhere on my existing system. If I could find that script or data file, surely it must be a perfect match for my particular drive geometry?
  13. xyz321

    xyz321 Well-Known Member

    Try posting the output of 'hexdump -C -n 512 /dev/sda', with any luck it will not produce an I/O error;)

    Later, or better still:

    cat /sys/block/sda/sda[1-3]/start
  14. Brian Burch

    Brian Burch Member

    humax# hexdump -C -n 512 /dev/sda
    hexdump: /dev/sda: Input/output error
    Pity. That sounded like a good idea to me! I expect I could use dd, but your next suggestion seemed a lot more human-friendly.

    That worked!

    /sys/block/sda/sda1 start == 2 and size == 2104513
    /sys/block/sda/sda2 start == 2104515 and size == 1930434660
    /sys/block/sda/sda3 start == 1932539175 and size == 20980890
    /sys/block/sda/sda size == 1953525168
    ...which is quite plausible as a representation of the partition table that allows tune2fs to locate sda2 and sda3.

    I calculate:
    1. sda1 and sda2 are not quite contiguous (1 block gap).
    2. sda2 and sda3 are separated by quite a big gap of 2094515 blocks.
    3. sda3 does not span to the end of the disk - there is free space of 5103 blocks.

    Do you agree with my conclusions?

    I fed these start and size numbers into "gfdisk -u /dev/sda" and the in-storage partition table looks like this:
    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
    Is there any way to verify this table before actually commiting the change?

    If I write this table to disk, and if the numbers are wrong, will I lose everything after I reboot? (or can I use gfdisk to tinker some more?)
  15. Brian Burch

    Brian Burch Member

    That conclusion was wrong - there is no gap at all, as shown in the gfdisk print that followed.
  16. xyz321

    xyz321 Well-Known Member

    I think you should be pretty safe with these numbers, they are the same as in the previous post.

    Edit. The start and end values are the same but the partition sizes (shown as a number of blocks) are different. May need more investigation...

    Later, I think it will be OK. The difference in the number of blocks is probably due to differences in the calculations used by fdisk and gfdisk.
  17. Brian Burch

    Brian Burch Member

    Don't be confused by the sizes from the OP's 1TB disk, which isn't identical to mine. Were you calculating ONLY from MY /sys/block/sda and gfdisk values?

    I tried to write the new table. Not surprisingly gfdisk got an error on the read, so I replied "i" to ignore it. Unfortunately, it then got "Error: Input/output error during write on /dev/sda" too. Before you ask... the word MAINTENANCE is on the humax display panel, and df shows that I don't have any /dev/sdx's mounted (paranoid umount /mnt/hdx's fail too). Have I overlooked something important, or is it telling me I can't actually write the new partition table to the device (digging into 20+ year memories, isn't that using bios int13 support?)

    IF the I/O error on read and write to the first block (partition table) is a real I/O error, isn't that the one section of the disk which cannot be re-allocated? If yes, I need a new disk.
  18. xyz321

    xyz321 Well-Known Member

    I think the first block on the disk is faulty so you would need to force it to be reallocated. I suggest from maintenance mode, unmounting any of sda's partitions which are already mounted and then writing zeros to the first block of /dev/sda using the following:

    umount /dev/sda1
    umount /dev/sda2
    umount /dev/sda3
    dd if=/dev/zero of=/dev/sda bs=4096 count=1
    Then recreate the partition table using the numbers above and reboot into maintenance mode again, then run:

    fix-disk -S
  19. Brian Burch

    Brian Burch Member

    Confirmed as not necessary in my case.

    This looked like a good idea to me because zeroing the first 4k bytes of the device would wipe out any residual data that might have been making the partition table ambiguous. Being naturally pessimistic, I expected to get another I/O error, BUT the dd write was successful!

    Unfortunately, when I used gfdisk to define the new partition table, it still got I/O errors on both the read and the write.

    I expected the successful dd write to trigger the drive to re-allocate block zero (now containing binary zeros) to a different physical location, and then transparently map all requests for block zero to the new location. Therefore, I did not think I needed to reboot - you didn't say so either. Besides, rebooting with a zero partition table might possibly lose the current good values in /sys/block/sda.

    Did I misunderstand your advice? If not, do you have an explanation why dd apparently worked and gfdisk still getting an I/O error on the write? Perhaps it isn't a device-status I/O error, but some kind of logical error? I'm wondering whether I can manually construct a valid partition table block and then dd it to block zero?
  20. xyz321

    xyz321 Well-Known Member

    After a reboot are the partitions still present?

    Edit: I see you haven't rebooted in which case it would be best to use fdisk to confirm that the partition table is correct. If that produces an I/O error then use hexdump to dump the partition table.

    hexdump -Cv -n 512 /dev/sda
    I think there is a pending sector write problem somewhere on the disk which may be producing these I/O errors. I would recommend running a smartctl test on the disk - this should find the location of the problem sector(s). You may not be able to install it using the package management system if /dev/sda2 is not accessible or read-only. In this case it can be copied onto the flash drive and run from there.