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