sda1 recovery failed - zero length partition

B

Brian Burch

Member
Code: 
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.

Code: 
/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...

Code: 
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.
Code: 
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:
Code: 
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?
 
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

Code: 
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.
 
af123 said:
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.
Click to expand...
That is very reassuring for me. Thank you for replying so quickly.

af123 said:
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.
Click to expand...
Good to know, but having the lost+found allows e2fsck to mark the big partition as clean, so it was worth doing.

af123 said:
Have you tried gfdisk? That should be installed with CFW 2.13
Code: 
humax# gfdisk -l /dev/sda
Click to expand...

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!
Code: 
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 
humax#

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...
 
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.

Code: 
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:

Code: 
humax# mkfs.ext3 -m 0 -O sparse_super /dev/sda1
 
Here's a post with partition information for a 1TB disk in it:

http://hummy.tv/forum/threads/recor...s-scrambled-or-not-available.2718/#post-32709

Code: 
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
 
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...
Code: 
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
humax#
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.
 
Brian Burch said:
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?
Click to expand...

Unless you decrypt them first, yes.
 
Brian Burch said:
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.
Click to expand...
This worked very well for me - it recursed through all the subdirectories too.
Code: 
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.
 
Black Hole said:
What if you enclosed it in plain.../plain tags?
Click to expand...
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?
 
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).
 
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.
Code: 
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?
 
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:

Code: 
cat /sys/block/sda/sda[1-3]/start
 
xyz321 said:
Try posting the output of 'hexdump -C -n 512 /dev/sda', with any luck it will not produce an I/O error;)
Click to expand...
Code: 
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.

xyz321 said:
Later, or better still:
Code: 
cat /sys/block/sda/sda[1-3]/start
Click to expand...
That worked!

Code: 
/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:
Code: 
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?)
 
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.
 
xyz321 said:
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...
Click to expand...
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?

xyz321 said:
I think you should be pretty safe with these numbers, they are the same as in the previous post.
Click to expand...
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.
 
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:

Code: 
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:

Code: 
fix-disk -S
 
xyz321 said:
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:
Code: 
umount /dev/sda1
umount /dev/sda2
umount /dev/sda3
Click to expand...
Confirmed as not necessary in my case.

xyz321 said:
Code: 
dd if=/dev/zero of=/dev/sda bs=4096 count=1
Click to expand...
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?
 
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.

Code: 
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.
 
You must log in or register to reply here.
Back
Top