----- Original Message ----- 
From: "David E. Fox" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, February 27, 2004 21:00
Subject: Re: [newbie] Bad superblock


> On Fri, 27 Feb 2004 11:06:14 -0600
> "Hoyt Bailey" <[EMAIL PROTECTED]> wrote:
>
>
> > lilo. This worked but when I booted into 10.0 there was an error which
> > I couldnt clear or get around so master reset was pushed to get out of
> > the system.  On rebooting to 9.2 several times I noticed scroll past
> > on the
>
> Hoyt - this might be similar to my experience with 10.0. I'm on rc1
> (updated through urpmi) but my 9.2 partition on /dev/hda7 had (and may
> still have) serious problems booting successfully. There were
> indications that /etc/fstab on that partition was scrambled (zero bytes
> interspersed with text) and the boot loader (lilo) on /dev/hda isn't all
> that good compared to the boot loader on /dev/hdb that boots up 10.0.
> Moral - don't have two bootable partitions :) as it can get confusing.
>
> If rescue could simply boot hda7 from the CDROM it would be a lot easier
> to get into 9.2 and/or get the fix. Thomas Backlund posted some help
> recently, but I don't remember the exact subject, you might want to
> search the archives.
>
> Other distributions I have used in the past allow this by just typing
> 'linux boot=/dev/hda7' on the command line of the rescue disk, but
> Mandrake doesn't allow this choice.
>
> I also noticed that the modules for the kernel were not accessible,
> which doesn't let me do all that much. I tried copying them over, but
> that didn't work either.
>
> And, I think you may be confusing the boot partition table with the
> superblock. Those are two completely different things.
>
> > screen a note that said bad superblock and the boot was switched to
> > 10.0 by the computer now that is all I can boot into even though the
> > boot process
>
> Well, in case it really is a bad superblock (have you mounted the
> partitions from rescue?) then e2fsck will fix it, and if there really is
> a damaged superblock, the filesystem (I assume for the moment you are
> using ext2) stores copies every 8192 blocks, with the first block
> starting at 1, so then the 2nd copy is at 8193, the third at 8193+8192,
> and so forth. If you type "e2fsck -b 8193 /dev/hda (use the right
> partition) it should be able to clear things up.
>
> Once cooker stabilizes somewhat, I'm planning on moving it from
> /dev/hdb6 back to the original place, /dev/hdb7. simply because
> /dev/hdb7 is much bigger, and that gives me extra space to store things
> :). It would be kinda neat to just save the state of the system at
> present (i.e, all the rpms and their versions and so forth, and
> automatically grab any rpms that are in contrib. mklivecd may be what
> I'm looking for, but I haven't tried it yet.
>
David
Richard Urwin proposed a theory. With which I agree. I installed 10.0rc1 on
the second disk while it was the only disk in the system (hda).  Then
reinstalled the main disk which had 9.2 on (hda).  I then rebooted 10.0 and
the system had two OS's on apparantly the same disk & since the mount tables
both directed the system to use different inodes on hda it got confused and
did the best it could.  At the same time it drove me crazy (the hidden
purpose of computers).  Anyway I erased the slave disk and converted it to
fat32 to act as my music file.  This released 9.2 to act by its self and it
is indeed screwed up e2fsck repaired 6 filesystems, there shold only be 3.
I will reinstall 10.0 on the main disk and that should get me back to a sort
of reallity.  I wish I had a program to reduce the windows part to half its
size but I'll have to live with it.

Thanks;
Hoyt



Want to buy your Pack or Services from MandrakeSoft? 
Go to http://www.mandrakestore.com

Reply via email to