Bug 133959

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

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

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

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.