Red Hat Bugzilla – Bug 133959
Restarting after a power hit fsck fails with "fsck.ext3: Invalid argument while checking ext3 journal for /
Last modified: 2015-01-04 17:10:09 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7)
Description of problem:
Machine has SELinux set to active and with default partition
recommendations at startup (which included two logical volumes in
Machine crashed from power loss. Upon restart let boot sequence
progress without intervention (did not select "Y" to force check).
error message returned to console is "fsck.ext3: Invalid argument
while checking ext3 journal for /"
system drops to maintenance prompt.
Next I ran "fsck -y" and there were a MASSIVE amount of fixes, perhaps
related to logical volumes? This box has been up less than 24 hours.
The fsck went on for more than an hour before I gave up and
reinstalled the OS.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install rawhide 9-27-04 on i386 w/ SELinux turned on and accept
default drive paritition configuration
2. Run x11perf -all, Evolution, OO and a few other apps
3. Turn off power
This is no e2fsprogs bug.
Is this a bug in a different component then? If so which component?
This is a kernel bug. Assigning to kernel.
is this still a problem with the final FC3 release + updates ?
Poweroff is, unfortunately, something we can't always do anything about in software.
When power fails, all sorts of things can start to go wrong. For example, as
the voltage starts to drop, RAM can start failing even while the rest of the
motherboard is working fine, and you end up writing bogus data to disk as the
system tries to complete existing IOs. Or bus errors can end up sending data to
the wrong part of the disk. Or the disk write caching can be ineffective and
data the OS thinks is on disk is actually not yet written through to permanent
So without more information, it's really not possible to say whether this is a
hardware or a software problem.
My orginal concern was that upon rebooting the message I got was:
fsck.ext3: Invalid argument while checking ext3 journal for /
That didn't make sense to me was receiving an "invalid argument" considering
that I had not entered anything.... simply booted the machine. Could it be that
my system was so hosed it couldn't find / and thus that was the problem? thus
resulting in the invalid argument error?
I tried to reproduce the problem by reloading the OS, etc. on the same version,
but was unable to make it happen again.
Perhaps cutting power and corrupting / would be another way to go about it? (I
am not quite sure how to do this, but would be willing to given some instructions)
The "invalid argument" means that the e2fsck fs checker got an EINVAL error from
the kernel. It looks like a corrupt journal descriptor. Without the rest of
the boot logs, I can't tell how much else of the root volume it was complaining
So all we know is, for reasons unknown, some of the static filesystem metadata
for the root fs was not properly found on reboot. Either there was corruption
in the LVM metadata or on the partition itself. We've no idea if it was
hardware or software which caused it, and it doesn't seem to be easily reproducible.
Forcibly corrupting "/" in software won't help much, there's not necessarily
much the OS can do without a root fs other than to try to recover it from a
Cutting power and looking for corruption might confirm it's a hardware problem,
if you're willing to risk trashing the machine repeatedly until it reproduces.
Otherwise, we probably just need to close this as non-reproducible for now, as
it does look more like power-induced hardware disk corruption than anything else.
Thanks for your comments. I concur and believe it reasonable to close this
issue for now.