[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: A solution to Kernel Panic ... on ext3 only!



On Thu, May 23, 2002 at 10:08:03AM +0800, Uwe Dippel wrote:
> Please accept, that I wrote the stuff as closely as possible. I had even
> taken a few notes. If you are not a filesystem hacker, you'll probably
> just try to repair the whole stuff and this is what I did. You are
> probably right on the "too many illegal blocks". In any case, I answered
> all with '-y' and found the situation as described after reboot: 
> "Mounting /proc filesystem 
> Creating root device 
> Mounting root filesystem 
> ext3: No journal on filesystem on ide0(3,6) 
> mount: error 22 mounting ext3 
> pivotroot: pivot_root(/sysroot, /sysroot/initrd) failed: 
> Freeing unused kernel memeory: 220k free 
> Kernel panic: No init found" 
> (Please don't bash me for mistakes copying this manually twice!) 

OK, given what you've told me, I suspect you can reproduce the failure
simply by running coverting your root partition back to ext2 (boot a
rescue system, and then run the command "tune2fs -O ^has_journal" to
remove the journal), and but leave the fstab entry as ext3.

I don't keep a have a recent Red Hat system hanging around, so I can't
test it myself, but it seems pretty clear from what you've
describe. (I probably should have a RH machine around, but it's s a
pain to keep up with security package updates for two different
distributions, and all of my machines are running Debian these days.
I should have one, though, since it's handy for debugging these sorts
of boot script-specific problems, which tend to be distribution
specific.)

Anyway, what happens is that mount is failing because the fstab entry
is saying that the filesystem is ext3, but since the ext3 mount is
failing, the root filesystem is never mounted, which makes the
pivotroot operation fail, and that's why you're getting the "no init
found" error message.

One of way of making things more robust is to use an /etc/fstab entry
which looks like this:

/dev/hda1      /        ext3,ext2    defaults        1 1

This will cause mount and fsck to first try ext3, and then ext2, so
that in the case where the filesystem is converted back to ext2 due to
a filesystem error, the system will actually come back up cleanly.
The only gotcha here is that the code to support having a list of
filesystems in /etc/fstab is relatively new, and I don't know what
version of Red Hat youre running; if it's too old, it might not have a
sufficiently new enough version of mount and fsck (in the util-linux
and e2fsprogs packages, respectively).

Another way of solving the problem would be to add something like the
following to the Red Hat's initrd linuxrc, before it tries to mount
the real root partition:

ext3root=`awk '{ if (($2 == "/") && ($3 == "ext3")) {print $1;}}' /etc/fstab`
if test -n "$ext3root" ; then
	tune2fs --j $ext3root > /dev/null
fi

The tune2fs command is a no-op if the filesystem already has a
journal, but if it doesn't, it will automatically add a journal to the
filesystem.  So this is nice, both because it allows Red Hat to
recover from a missing journal automatically, but also because it
means it becomes very simple to convert your root filesystem to ext3.
All you need to do is to edit /etc/fstab so that root's fs type is
ext3, and then reboot the system.

> And here my enhancement proposal drops in: The data were quite well,
> only mounting as ext3 failed. And this was non-trivial to find out,
> since - as described - the 'Repair' option of the Install-CDROMs also
> complained about this "...Invalid Argument ..... You don't have any
> Linux partitions". Re-install is option of choice, you might think; but:
> no, deleting the journal and a normal fsck on the resulting ext2 brought
> everything back to normal

Yes, you're right.  The system ought to be more robust about the
discrepancy between what's in /etc/fstab and whether the filesystem is
ext3 or ext2.  However, this is a distribution specific problem, not
one which I can fix in e2fsprogs.  So what I'd suggest you do is to
file an enhancement request with Red Hat.  (Or Stephen, who works for
Red Hat, may be able to file this enhancement request for you.)

I will file a similar enhancement request for Debian.

						- Ted





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]