Ping Akoellh - Time Bug M8

English Install/Boot/Login
#1

Hi
Have you loaded M8 yet? Whilst I see there is a note on bootup with
FIXED, the time error was still present for me on a fresh install.
Running mkinitrd fixed the issue, but I see 534816 is closed, but to
open a new bug.

Was wanting to see if you are still having the problem first…

–
Cheers Malcolm °¿° (Linux Counter #276890)
SUSE Linux Enterprise Desktop 11 (x86_64) Kernel 2.6.27.29-0.1-default
up 5 days 22:04, 2 users, load average: 0.11, 0.08, 0.03
GPU GeForce 8600 GTS Silent - CUDA Driver Version: 190.18

#2

I “only” did an upgrade via zypper dup (my bandwidth is a little “limited” at the time), so I can not compare my results with yours.

As I kept “localtime” there were no issues, will switch back to utc and see what happens.

#3

I loaded M8 a couple of hours back. After correctly setting the time as part of the install, and then going for an evening drink with my wife, I came back to the PC and noted the time was out by something like 5 hours ? I went to YaST and corrected the time. It then took about a minute before it corrected. Its now reading properly. This is an old slow PC (athlon-1100 with 1GB RAM and with KDE-4.3.1 and GeForce FX5200, and proprietary nVidia driver and I do have desktop effects enabled which slows things down more).

I’m going to leave it run over night and see if time stays.

#4

Really strange, the problem with faulty mount times is still there if you use utc.

  • switched back to utc

  • ran mkinitrd

  • halted the machine and started it up again


Fri Oct  2 22:55:36 CEST 2009

Last mounted on:          <not available>
Last mount time:          Sat Oct  3 00:53:26 2009
Last write time:          Sat Oct  3 00:53:26 2009
Last checked:             Wed Sep 16 19:46:30 20098

So I expected trouble on next boot anyway and did not care about doing a full halt and start (which was the only way to trigger the wrong behavior before M8) and did a simle reboot.

However, on next boot there was no problem with booting but a message

“last mount time of /dev/sda2 was in the future, possibly due to buggy init scripts - FIXED” (yeah, that “buggy” part was really there)

appeared.

So I am trying to reproduce this and not use reboot but fully halting the machine and starting it up again.

Although the differences in “date”-output and the last mount time is still there, I don’t get this message any longer on next boot if I do a full “halt - start again” cycle.

For the real fun part, now only rebooting seems to trigger this message but at least there is no longer a problem with having to run fsck manually.

So next I tried to:

  • halt

  • start

  • check if the different times are there (yes they are)

  • halt

  • start again

ans there was really no message about a mount time in the future on startup.

Checking the last mount time with tune2fs showed the problem still to be there (2h difference) and so I did a last “reboot” and guess what?

Exactly:

“last mount time of /dev/sda2 was in the future, possibly due to buggy init scripts - FIXED”.

I really have no idea how to categorize this, the bug is certainly not fixed but worked around or at least the real problem with wrong mount times is still definitely there.

#5

Hi
I have no idea either, at least it’s not readjusting the BIOS time!

tune2fs here shows a 2 hour difference as well;


# date
Fri Oct  2 17:07:51 CDT 2009

tune2fs /dev/sda5 -l |grep Last
Last mounted on:          <not available>
Last mount time:          Fri Oct  2 16:54:11 2009
Last write time:          Fri Oct  2 16:54:11 2009
Last checked:             Thu Oct  1 15:42:38 2009

–
Cheers Malcolm °¿° (Linux Counter #276890)
openSUSE 11.2 Milestone 8 (i586) Kernel 2.6.31-10-desktop
up 0:12, 2 users, load average: 0.14, 0.27, 0.18
ASUS eeePC 1000HE ATOM N280 1.66GHz | GPU Mobile 945GM/GMS/GME

#6

Hi oldcpu
Just keep an eye on the boot messages, they seem to have a work around
for the halt to booting, but if you run the tune2fs command, what do
you get?

–
Cheers Malcolm °¿° (Linux Counter #276890)
openSUSE 11.2 Milestone 8 (i586) Kernel 2.6.31-10-desktop
up 0:15, 2 users, load average: 0.04, 0.17, 0.16
ASUS eeePC 1000HE ATOM N280 1.66GHz | GPU Mobile 945GM/GMS/GME

#7

Erm

no, that’s perfectly fine, the two hours difference are

a) for “Last checked” not for “Last mount Time”

b) two hours in the past

You are running the system with “–localtime” I guess?

#8

Hi
Yes, localtime it’s Thursday as well, so I’m guessing that was the boot
before I ran mkinitrd…

–
Cheers Malcolm °¿° (Linux Counter #276890)
SUSE Linux Enterprise Desktop 11 (x86_64) Kernel 2.6.27.29-0.1-default
up 6 days 0:15, 2 users, load average: 0.09, 0.07, 0.01
GPU GeForce 8600 GTS Silent - CUDA Driver Version: 190.18

#9

To sum things up for my installations.

The problem with false dates for mount time on the file system is only present when the clock is set to utc.

Checked several times with both installations and no inconsistencies there with localtime.

After switching back from utc to localtime, running mkinitrd is needed (as expected) to fix the inconsistency.

#10

After letting the PC run all night (and clock was fine), I rebooted. Immediately after the reboot, time was off by two hours.

I have not tried to run tune2fs.