Description of problem:
After a fresh install from the "rawhide" tree, (already familiar) failed attempts to suspend the system with active KMS or resetting the system after an X freeze lead to error messages
"/dev/VolGroup00/LogVol00 contains a file system error, check forced
Type Ctrl -d to proceed with normal startup, (or give root password
for system maintenance)
..".
Without waiting for user input, the system then complains about a missing library /usr/lib/libfreebl3.so. Hereafter the system reboots immediately, and a file system check on /dev/VolGroup00/LogVol00 is performed automatically upon reboot, after which the system comes up as expected.
Version-Release number of selected component (if applicable):
kernel-2.6.31.6-2.fc12.x86_64
How reproducible:
Steps to Reproduce:
1. Reset system.
Actual results:
Upon rebbot, system complains about file system errors.
Expected results:
System picks up journal and checks file system integrity.
Additional info:
- /dev/VolGroup00/LogVol00 contains the root files system. /boot, /usr and
/home are hosted by different partitions/volumes.
- This issue seems to be a recent one arosen within the last two weeks.

After a fresh install from the "rawhide" tree using the 2009-08-18 boot.iso due to anaconda crashes of the most recent versions, no initrd entry is present in /etc/grub.conf, and subsequently, the kernel panics upon the next reboot.
After booting into rescue mode, chrooting and installing the latest device-mapper, dracut, lvm2 and kernel packages from Koji, the new kernel entry in /etc/grub.conf looks correct, and the system seems to boot as expected.
However, shortly after starting udev, the system reports "Unexpected inconsistencies of file system", and then "Automatic reboot in progress".
Even running fsck.ext4 on /dev/VolGroup00/LogVol00 has no effect: after rebooting the system, the same error messages about inconsistencies reappear.
There seems to be no way to rescue the system other than intalling it from scratch, possibly using ext3 instead of ext4 .. :o(

Created attachment 363426[details]
boot.log after forced reboot due to file system inconsistencies
Because of temporary problems with the power supply, the system happens to power off fairly frequently. Here is the typical boot log after the forced reboot triggered by the kernel after file inconsistencies have been detected which happens every time after a power cut. They always appear on the root [ext4] volume, never on /usr [ext4] or /home [ext3] volumes.

After a shutdown triggered by pressing the soft power button while investigating bug 526433, the system does not recover from the file system inconsistencies anymore. It always proceeds to the automatic reboot step and is hence caught in an endless loop of reboots.
In the past I had already tried to run fsck.ext4 in rescue mode but after rebooting the system from the system disk, the same inconsistencies were reported. The hardware profile of the affected system can be found at
http://www.smolts.org/client/show/pub_ce3d646e-2918-44c9-a6c0-10fb3d9a0180

The issue has been confirmed for two other systems, thus no faulty hardware. It might be worthwile checking the ext4 default settings. It seems that recent kernels are a bit too aggressive regarding maximizing disk I/O performance.

(In reply to comment #10)
Correct, local time zone is CEST (UTC+2h). I have to repeat that this issue is fairly recent, maybe 1-2 months old. It does not occur for current F11 even when the root volume has file type ext4.

Btw, before the automatic reboot is triggered with the announcement,
"Automatic reboot in progress."
there -is- a message
"Superblock last write time is in the future"
And yes, the hardware clock is set to the local time zone CEST.

Regarding the superblock write time in the future, it should be fixed as of bug 522969 's resolution in rawhide & f12, so you might update that to get that annoyance out of the way.
Other than that, there have been other reports of corruption problems in ext4 upstream, if you have a repeatable testcase we may have a patch you could try if you're handy with such things; it's on my list of things to look into today.
Thanks,
-Eric

Just adding to this report as I've seen these exact symptoms after upgrading my laptop from F11 to the Beta tonight, including the complaint about a missing libfreebl3.so.
I will try installing the updated e2fsprogs via the rescue image.
It's now also complaining that it's unable to write some udev-related files, before the "Welcome to Fedora" text appears.

Note

You need to
log in
before you can comment on or make changes to this bug.