Re: [gentoo-amd64] Re: not amd64 specific - disk failure

[Raffaele BELARDI <raffaele.belardi@st.com>]

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
-- 
gentoo-amd64@gentoo.org mailing list