Bug 583361 - the system thinks that the hardware clock is set to UTC when it is not
the system thinks that the hardware clock is set to UTC when it is not
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: util-linux-ng (Show other bugs)
14
All Linux
low Severity high
: ---
: ---
Assigned To: Karel Zak
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-04-18 02:08 EDT by atswartz
Modified: 2010-08-09 13:29 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-08-09 13:29:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description atswartz 2010-04-18 02:08:52 EDT
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 14:30:01 EDT
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-18 23:02:46 EDT
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 10:39:05 EDT
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 11:44:29 EDT
(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-21 23:56:24 EDT
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-29 23:43:24 EDT
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 19:12:05 EDT
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 19:57:50 EDT
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 00:01:22 EDT
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 18:35:50 EDT
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 07:23:43 EDT
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

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