> Hi gentoo-users,
> I'm running Gentoo flawlessly on my laptop for nearly one year now, but
> since yesterday, I'm in big trouble. At some instance (surfing in the web,..
> nothing horrible) the screen froze and the only thing I was able to do, was
> pressing the power button 4seconds to shut the computer down.
> I was never able to boot my system since then.
> It sayed always things like: Not able to find root file system (or
> So I plugged in my live-cd to recover the whole thing...
> But I wasn't able to mount the root partition, so I tried e2fsck, which
> turned out to find a whole lot of errors and told me that it corrected them.
Not such a good idea. For future reference, unless you don't mind
losing the data, always take a block-level snapshot, if possible,
before doing anything else. You don't know what state things are in,
writing to it could make the situation worse.
> Thus I retried to mount the file system, which resulted in an big error of
> mount, saying something about Kernel BUG (?!?)
D'oh! Congratulations, you found a kernel bug!
> At that point I realized that this could become a major problem for me,
> since all my personal data is on my root partition (I know, I should't do
> that...but thats the way things are right now)
Oh dear. You have backups, right?
> I used dd to make a copy of this partition to an external hard disk, and
> begun to recover it from there.
> dd gave no errors as it copied the partition, so I think this is no hardware
Hopefully. I'd be extra careful about backups for a while, though.
> I rerun e2fsck on the partition, it corrected a little more, but after that,
> it didn't found anything new, but I still wasn't able to mount the partition
> (nor the partition dump)
> The crutial part of the dmesg output seems to be:
> Assertion failure in cleanup_journal_tail() at fs/jbd/checkpoint.c:430:
> "blocknr != 0"
> Is this a known issue with ext3 filesystems?
Google says someone else hit it once upon a time, but it doesn't seem
to be listed on the kernel bugzilla. Your journal is corrupted and the
kernel is not being as careful as it should before using on-disk data.
If you remove the journal you will hopefully get some or all of your
data back. On a *COPY* of the partition image do the following to
replace the old journal with a new one:
tune2fs -O ^has_journal <image>
e2fsck -f <image>
tune2fs -j <image>
e2fsck -f <image>
If everything looks OK and the data you care about is all there then
you can go ahead and fix up your real disk. If you wouldn't mind
though, please keep a copy of the corrupted image. I'll prepare a
patch to fix the BUG and it would be helpful if you could test it once
it is ready.
> Thaks in andvance for any help,
"I never could learn to drink that blood and call it wine" - Bob Dylan
email@example.com mailing list