Re: Suggestions after gpart and e2retrieve both failed?

[leslie . polzer]

On Mon, Feb 06, 2006 at 09:55:45AM +0100, address@hidden
wrote:

> Using parted under Knoppix, I tried using "resize" to free up about
> 10GB at the end of the ext2 partition. I then made a new win32
> partition in the space. I had a dim memory that Windows always wanted
> to be the first partition, but I couldn't remember if that was
> actually the first *disk*.
It does not have to be the first partition (Windows will ignore all
except FAT anyway), but these conditions must be satisfied:

1) the first stage boot loader must be able to find the second stage on
the first (BIOS-wise) hard-disk and the first FAT partition.
2) the partition must be primary.

  And of course the disk label must be MS-DOS, which is satisfied by your
setup.

> So I tried again. This time I used SystemRescueCd, which I'd found
> on the internet and thought looked interesting. I deleted the win32
> partition. Then I tried to move the existing partition up a few GB.
> I knew that "move" doesn't like moving to overlapping partitions,
> so I used "resize" instead.
That doesn't help.  When resizing the start of the partition must stay
fixed.  There is no way to move the start of a partition to an
overlapping target in GNU Parted right now.

> the version of parted on SystemRescueCd most definitely segfaulted.
As a note to the other readers, this was most likely 1.6.23.

> Then, when I tried to reboot Linux, it refused to boot. Interestingly,
> GRUB actually manages to find the right kernel file: even when I edit
> the command and "tab out" the filename. The kernel file does boot:
> it's only when it tries to mount the root filesystem that it fails.
> So somehow, someway, some recovery tool should be able to recover my
> kernel image, and probably more besides.


> I tried running gpart to see if the partition table was confused.
> Unfortunately, it seemed to recognise some vestigial win32 partition
> instead of the ext2 partition I was really after:
I can imagine very well what happened here: gpart is sometimes
unreliable because it just does some very raw guessing of file system
signatures all over the whole disk.

I'd like to have the output of the Linux fdisk command sequence "p x p".

> Scan finished
>
> Superblocks: #1 (155131640 Ko) : copy 0 1 3 5 7 9 25 27 49 81 125 243
> 343 625 729 #2 (155131640 Ko) : copy 0 0 0 0 #3 (155131640 Ko) : copy
> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 #4 (155131640 Ko) : copy 0 #5 (155131640
> Ko) : copy 0 0 #6 (155131640 Ko) : copy 0 0 #7 (155131640 Ko) : copy 0
> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 #8 (60000 Ko) : copy
> 0 1 3 5 7 Superblock #7 has been choose.
>
> *** glibc detected *** double free or corruption (!prev): 0x0805b428
> *** Aborted
This is a bug in e2retrieve.

> I don't really understand what that information means, but #1 looks
> far more promising to me than #7. Clearly #8 is one of the smaller
> partitions I attempted to create.
This is information strictly pertaining to the ext2 file system and does
not have anything to do with partitions.

> As far as I can tell, e2retrieve
> doesn't have any way for me to override which superblock it uses.
But "mount" has.  I suggest the following steps:

  1) use dumpe2fs on the file system to see where the super blocks lie.
  2) use 'mount -o sb=' to choose one of those when mounting.

You can also try e2fsck, which does good recovery esp. on mildly damaged
file systems.

> Here's what my partition table looks like now:
>
> Information: The operating system thinks the geometry on
> /UNIONFS/dev/hda is 19457/255/63. Therefore, cylinder 1024 ends
> at 8032.499M. (parted) p Disk geometry for /UNIONFS/dev/hda:
> 0.000-152627.835 megabytes Disk label type: msdos Minor Start End Type
> Filesystem Flags 1 0.031 151495.773 primary ext3 boot 2 151495.774
> 152625.344 extended 5 151495.805 152625.344 logical linux-swap
>
> Well, that's all the information I can think of including here. Please
> let me know if you have any suggestions. I guess my next step is to
> try to modify the source code of e2retrieve to make it use the right
> superblock: but I have no idea about ext2 filesystems, and I don't
> even know what a "superblock" is, so I'd rather not if I can avoid it.
I can explain it to you if you still need it after my instructions.
  For now it should suffice if you know that the super block is the
starting point of all operations on an ext2 file system.  Without the
super block (or one of its copies that are scattered throughout the file
system) you will have problems working with the file system in any way.

  Hope that helps,

    Leslie

-- 
gpg --keyserver pgp.mit.edu --recv-keys 0x52D70289
http://nic-nac-project.de/~skypher/

pgp4ZAW7iJzk8.pgp
Description: PGP signature