Hi, I have also noticed this issue now when I migrate my system from a RHEL to Scientific License 6.3 My installation procedure also with a kick start file, without specifying any input.
Regards, Arul From: [email protected] [mailto:[email protected]] On Behalf Of Michael Duvall Sent: Wednesday, October 30, 2013 10:29 PM To: [email protected] Subject: Re: Superblock last mount time (<date> now <date>) is in the future. Bill, My initial thought is that the CMOS battery is failing. Afterall, the Lenovo T61p dates back to 2007. If there were a problem with fsck, I would think that it would be seen by lots of people on lots of different platforms. Regards, -- Michael Duvall Systems Analyst, Real-Time [email protected]<mailto:[email protected]> (954) 973-5395 direct (954) 531-4538 mobile [cid:[email protected]] CONCURRENT | 2881 Gateway Drive | Pompano Beach, FL 33069 | www.real-time.ccur.com<http://www.real-time.ccur.com/> -----Original Message----- From: Bill Askew <[email protected]<mailto:bill%20askew%20%[email protected]%3e>> To: [email protected]<mailto:[email protected]> <[email protected]<mailto:%[email protected]%22%20%[email protected]%3e>> Cc: Bill Askew <[email protected]<mailto:bill%20askew%20%[email protected]%3e>> Subject: Superblock last mount time (<date> now <date>) is in the future. Date: Wed, 30 Oct 2013 12:45:50 -0400 Hi everyone I am running SL6.2 64bit on a Lenovo T61p. We don't always set the date to the current date and sometimes the date is in the past. If the year is 2010 - 2012 I get the following message at boot up. Checking filesystem /dev/mapper/VolGroup-lv_root: Superblock last mount time (Wed Oct 30 12:11:30 2013, now = Sat Oct 30 06:27:50 2010) is in the future. /dev/mapper/VolGroup-lv_root: UNEXPECTED INCONSISTENCY: RUN fsck MANUALLY. [FAILED] *** An error occurred during the file system check. *** Dropping you to shell; the system will reboot *** when you leave the shell. Give root password for maintenance (or type Control-D to continue): This looks to me like a bug in fsck. I can work around the boot up failure by modifying rc.sysinit to run fsck with the –y option. Alternatively I have created /fsckoptions with –y (this gets removed by rc.sysinit after boot up). I would appreciate any other suggestions on how to work around this problem. Thanks
<<inline: image001.jpg>>
