Red Hat Bugzilla – Bug 522809
Boot fails, last mount time in the future
Last modified: 2014-03-25 21:01:40 EDT
I've got 2 different RHEL 5.4 hosts which have shown this problem. kvm-83-105.el5_4.1 kernel-2.6.18-164.el5 libvirt-0.6.3-20.1.el5_4 All of my guests are rawhide. I have no idea if that is applicable. Sometimes (not always) when I try to boot a guest it will fail to boot and drop me into filesystem recovery mode because the 'last mount time' of the / and the /boot filesystem (the only 2 filesystems inside my vms) is in the future. The time in the future is never > 60 minutes in the future. It does not always happen. Another off thing is the /boot often says that it 'last modify time' is in the future (I have never seen / indicate it's last modify time was in the future) Running fsck on both filesystems allows everything to boot just fine (until the next time) I believe it may be reproducible by booting a vm and then crashing it or using the 'force off' option to forcibly power it down rather than rebooting it cleanly. I'm not sure what all I can collect or do to help pin down the problem. I do know that when the mount fsck fails and drops into recovery mode the date inside the vm is correct.
Pls retry to check if its rawhide or kvm
Can you give us numbers about what the times are? output of the "date -u" command before the crash, and after the crash, are welcome. Also, please include your guest dmesg.
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
This request was erroneously denied for the current release of Red Hat Enterprise Linux. The error has been fixed and this request has been re-proposed for the current release.
If this still happens and there is a way to reproduce the bug, please reopen.