Bug 583361

Summary: the system thinks that the hardware clock is set to UTC when it is not
Product: [Fedora] Fedora Reporter: atswartz
Component: util-linux-ngAssignee: Karel Zak <kzak>
Status: CLOSED WORKSFORME QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 14CC: atswartz, GoinEasy9, kzak, mzdunek, nphilipp, scottro11
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-08-09 17:29:58 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description atswartz 2010-04-18 06:08:52 UTC
Description of problem:For the last few days I have been getting a: Superblock last write time is in the future, in my boot.log.  The system time is then offset back five hours.  I have never had it set to UTC and never even went near the settings.  I'm not sure that the system-config-date is the correct package to file this against, but hwclock was not an option.  This is a recent problem and is happening to both a GNOME install from an alpha live-cd and a KDE install from a beta on two different machines.   


Version-Release number of selected component (if applicable):


How reproducible:every reboot for the last three days


Steps to Reproduce:
1.reboot
2.system changes time during boot
3.need to change time before shutdown to changes don't get written to BIOS
  
Actual results:
above

Expected results:
Since the hardware clock is set to local time, the system time does not need to be adjusted.  

Additional info:
[andrew@790x ~]$ date
Sat Apr 17 23:46:22 CDT 2010
[root@790x ~]# hwclock --show
Sat 17 Apr 2010 11:47:38 PM CDT  -0.462134 seconds
 /etc/adjtime
-11.373764 1271563714 0.000000
1271563714
LOCAL
[andrew@790x ~]$ ls -l /etc/localtime
-rw-r--r--. 3 root root 3543 Apr  6 09:23 /etc/localtime
[andrew@790x ~]$ ls -l /usr/share/zoneinfo/America/Chicago
-rw-r--r--. 3 root root 3543 Apr  6 09:23 /usr/share/zoneinfo/America/Chicago
[andrew@790x ~]$ uname -r
2.6.34-0.19.rc2.git4.fc14.x86_64

Comment 1 GoinEasy9 2010-04-18 18:30:01 UTC
I'm having similar problems, this is what the secure.log shows:

Apr 17 01:43:22 localhost userhelper[2933]: pam_timestamp(gnome-system-log:auth): timestamp file `/var/run/sudo/GoinEasy9/unknown:root' has unacceptable age (14827 seconds), disallowing access to gnome-system-log for user GoinEasy9
Apr 17 01:43:26 localhost userhelper[2933]: pam_timestamp(gnome-system-log:session): updated timestamp file `/var/run/sudo/GoinEasy9/unknown:root'
Apr 17 01:43:26 localhost userhelper[2941]: running '/usr/sbin/gnome-system-log ' with root privileges on behalf of 'GoinEasy9'

Comment 2 Scott Robbins 2010-04-19 03:02:46 UTC
I'm showing the same issue. I don't have system-config-date or Gnome installed.

In dmesg it lists the correct date and time.  

uname -r 2.6.34-0.28.rc3.git3.fc14.i686.PAE

No mention of timestamp in /var/log/secure.log

Comment 3 atswartz 2010-04-19 14:39:05 UTC
I have the same issue on another KDE install, that is why I didn't know what package to file it against.

Comment 4 Nils Philippsen 2010-04-19 15:44:29 UTC
(In reply to comment #0)
> Description of problem:For the last few days I have been getting a: Superblock
> last write time is in the future, in my boot.log.  The system time is then
> offset back five hours.  I have never had it set to UTC and never even went
> near the settings.  I'm not sure that the system-config-date is the correct
> package to file this against, but hwclock was not an option.

Hwclock is part of the util-linux-ng package, changing component.

Comment 5 GoinEasy9 2010-04-22 03:56:24 UTC
After update tonight, problem still persists, and, if it's related, weather location in Clock loses it's location and has to be reset.

Comment 6 GoinEasy9 2010-04-30 03:43:24 UTC
I read a post on the fedora forum that claimed in yesterday's update util-linux-ng reverted back (if updating to a newer version is actually reverting back) to the version in F13, util-linux-ng-2.17.2-3.fc13.i686.rpm, and that fixed the problem. In tonight's update I didn't see that reversion happen.  When I tried to pull the file in from koji, it would require my downgrading (or upgrading) 2 other files:

could not do simulate: util-linux-ng-2.17.2-3.fc13.i686 requires libblkid = 2.17.2-3.fc13 util-linux-ng-2.17.2-3.fc13.i686 requires libuuid = 2.17.2-3.fc13

I don't know if that will just cause more problems so I'm waiting for that version to be included in the F14/rawhide repo.  Since it is a newer version of what is in the F14 repo presently - util-linux-ng-2.17.2-1.fc14.i686.

Comment 7 atswartz 2010-05-03 23:12:05 UTC
I am no longer having time problems on either machine.  Although on one, I now have util-linux-ng-2.17.2-3.fc13.x86_64 and the other util-linux-ng-2.17.2-1.fc14.x86_64, so it must have been a different package that was causing the problem.

Comment 8 atswartz 2010-05-05 23:57:50 UTC
I now have "downgraded" the util-linux-ng-2.17.2-3.fc13.x86_64 package to the f14 version (util-linux-ng-2.17.2-1.fc14.x86_64) and all is well.

Comment 9 GoinEasy9 2010-05-06 04:01:22 UTC
I am also no longer having a problem with time.  The problem must have been elsewhere.  I have had the following version of the apps all along.

util-linux-ng-2.17.2-1.fc14.i686
libuuid-2.17.2-1.fc14.i686
libblkid-2.17.2-1.fc14.i686

Comment 10 Marek Zdunek 2010-06-06 22:35:50 UTC
I have dual boot with windows, when i reboot to other os clock speeds up +2h, my timezone is +2h from GMT

hwclock --localtime
pon, 7 cze 2010, 00:31:18  -0.072457 sekund

from boot.log
/dev/sdb2: Superblok last mount time is in the future.
	(by less than a day, probably due to the hardware clock being incorrectly set)  POPRAWIONO.

kernel 2.6.33.5-112.fc13.x86_64

util-linux-ng.x86_64   2.17.2-5.fc13

Comment 11 Bug Zapper 2010-07-30 11:23:43 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping