Re: Suggestions after gpart and e2retrieve both failed? message 9 of 20)

[parted . mexon]

address@hidden wrote:
> On Mon, Feb 06, 2006 at 09:55:45AM +0100, address@hidden
> wrote:
>
> > 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.

Hmm, so this should have worked.  Just random acts of suckage from 
Windows then.  My guess would be that some piece of code written in 1999 
isn't ready for hard drives bigger than about 80GB.

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

OK.  This probably means my project to install Windows on this hard disk 
is doomed.  How is resize supposed to behave when you ask it to move the 
start of a partition?  Because it seems to me as though it just ignored me.

> As a note to the other readers, this was most likely 1.6.23.

Confirmed: 1.6.23.  My R.I.P. CD from last November turns out to have 
1.6.24.  I should have stuck with that.

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

Bugger: forgot to bring that into work.  Sorry.  I'll do that tomorrow.

> But "mount" has.  I suggest the following steps:
>
>   1) use dumpe2fs on the file system to see where the super blocks lie.

Here's edited highlights:

...
Group 0: (Blocks 0-32767)
  Primary superblock at 0, Group descriptors at 1-10
  Block bitmap at 11 (+11), Inode bitmap at 12 (+12)
  Inode table at 13-521 (+13)
  8 free blocks, 2874 free inodes, 3283 directories
Group 1: (Blocks 32768-65535)
  Backup superblock at 32768, Group descriptors at 32769-32778
  Block bitmap at 32779 (+11), Inode bitmap at 32780 (+12)
  Inode table at 32781-33289 (+13)
  2 free blocks, 1700 free inodes, 3635 directories
...
Group 729: (Blocks 23887872-23920639)
  Backup superblock at 23887872, Group descriptors at 23887873-23887882
  Block bitmap at 23887883 (+11), Inode bitmap at 23887884 (+12)
  Inode table at 23887885-23888393 (+13)
  32200 free blocks, 16263 free inodes, 0 directories
...
Group 1183: (Blocks 38764544-38782909)
  Block bitmap at 0, Inode bitmap at 0
  Inode table at 0-508
  0 free blocks, 0 free inodes, 0 directories

dumpe2fs: /dev/hda1: error reading bitmaps: Can't read an block bitmap

>   2) use 'mount -o sb=' to choose one of those when mounting.

I decided to focus on the last backup superblock, on the grounds that
it would probably be furthest away from the damage.  I had a lot of
trouble figuring out what the argument to "mount -o sb=" should be.
The raw number I was working with was 23887872.  I first tried that
number, then the group number (729), then I looked up the manpage for
mount and figured out that I probably had to divide the number by 1024
(23328).  None of these worked, all with the same error.  For example:

# mount /dev/hda1 /mnt/linux -o sb=23328
mount: wrong fs type, bad option, bad superblock on /dev/hda1,
       missing codepage or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

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

# e2fsck /dev/hda1
e2fsck 1.38 (30-Jun-2005)
Group descriptors look bad... trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/hda1

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

So I tried it with a -b argument of 23887872 (I know that's several
orders of magnitude higher than the example.  This is unix; for all I
know the example could have been written in 1972).  That fails as so:

e2fsck: Invalid argument while trying to open /dev/hda1
(plus the previous message)

Using an argument of 23328 gives a "bad magic number" message the same
as before.  I've also tried the above with the superblocks at 32768
and 98304.  I guess I could go through them all, one by one, if you
think it might help.

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

Let's say I have a vague notion that there's an inode table somewhere on 
my disk, and this has pointers to the raw data that makes up my files. 
So the super block is the bit that points to the inode table?  And 
probably contains other interesting stuff about the filesystem, like the 
fact that it's ext3 instead of ext2.