Raffaele Belardi wrote: > So my hypothesis is that the bad blocks or sectors at the beginning of > the partition were not copied, or only partly copied, by dd, and due to > this the superblocks are all shifted down. Although I don't like to > access again the hw, maybe I should try: > # dd conv=noerror,sync bs=4096 if=/dev/hdb of=/mnt/disk_500/sdb.img > > to get an aligned image. Problem is I don't know what bs= should be. > Block size, so 4k? >
So, I re-created an image of the disk with the above. The first 512 bytes contain an MBR (I recognize the aa55 signature), then lots of nulls until what seems a part of the first superblock, obviously unusable. I manually searched for another superblock looking for the magic number and found one at 0x8007e00. According to mkfs the first sb backup should be at block 32768, so byte 0x8000000. Thus the image is shifted up of 0x7e00 bytes (probably the sum of MBR+Grub stage 1.5, although the numbers do not correspond with another drive I used to check). Now the problem is how to tell e2fsck to use sb at 0x8007e00? This is not divisible by block size (0x1000), I tried to specify a different block size with -B 512 but it complains that it's not legal size. Should I trim the first 0x7e00 bytes of the image and use e2fsck normally (with -b 32768)? If so, how can I remove the first 0x7e00 bytes without re-reading the whole image from damaged disc? Other options I may have? Is it possible to fake the kernel into using the sdb.img as a disk image, so mount it as a disk (not as a partition) so maybe it automatically skips the first 0x7e00 bytes and gives me an aligned first partition? thanks, raffaele -- [EMAIL PROTECTED] mailing list
