problem with time

This seems to be the same issue as bug 63175.

Not exactly Colin. The check is done just one time per partition formated by ubiquity, on the first boot of the fresh install.

First boot->fsck of / -> reboot -> fsck of /home -> reboot -> OK

I am still seeing this problem on feisty RC. I live in GMT +8 timezone, and the hardware clock is set to localtime, because I have Windows installed. I choose Asia/Shanghai as my timezone in Ubiquity. Upon the first boot, fsck complains that the
superblock last mount time is in the future, and requires a reboot. Here are the relevant messages on the screen:

---------------------------------------------------------------------------
* Checking root file system...
fsck 1.40-WIP (14-Nov-2006)
/dev/sdb4: Superblock last mount time is in the future. FIXED.
/dev/sdb4: Superblock last write time is in the future. FIXED.
/dev/sdb4 has gone 49710 days without being checked, check forced.
/dev/sdb4: ***** REBOOT LINUX *****
/dev/sdb4: 98408/2064384 files (0.1% non-contiguous), 585723/4122680 blocks
fsck died with exit status 3

 * The file system check corrected errors on the root partition
 but requested that the system be restarted.
 * The system will be restarted in 5 seconds.
---------------------------------------------------------------------------

I think I have located the root cause of the problem. Ubiquity updates
the system clock to local time without changing the timezone accordingly,
which causes the last mount/write time 8 hours ahead in my case.
Everybody live in GMT + timezones shall experience the problem.

Colin, I think it's a separate bug from bug 63175, which shall be experienced
by users in the GMT minus timezones only. It is caused by the fact the kernel
considers the RTC time (the hardware clock) as UTC time, which makes the
initial system clock a couple of hours behind the UTC time for people living
in GMT minus timezones. Only after S50hwclock.sh does this mistake get corrected.

I tested an installation in VMWare using Asia/Tokyo and could not reproduce this problem. Can you give us a test case to allow us to isolate the problem?

What kind of informations/result of command do you need ?

On Fri, Apr 20, 2007 at 03:59:32PM -0000, Patrice Vetsel wrote:
> *** This bug is a duplicate of bug 63175 ***
> https://bugs.launchpad.net/bugs/63175
>
> What kind of informations/result of command do you need ?

I need instructions which can be performed by a developer to cause the
problem to occur.

--
 - mdz

Ok let me time. I'm installing and trying to reproduce bug under vmware+windows xp +feisty…

Assume you are currently in China, and the hardware clock of your computer is set to Beijing time (GMT+800) to accommodate the requirement of Windows. After booting the feisty desktop-i386 CD, the system clock is the correct GMT time, which is obtained from a time server on the network shortly after the network interface is up. When Ubiquity starts to do the real installation job, it updates the system clock to Beijing time, but without changing the timezone accordingly. You can notice the time change on the Gnome Date&Time applet and confirm that the timezone does not get updated by using the date command . This mistake makes the system clock 8 hours ahead of the current time, and hence the last modified/write time recorded in ext3 superblocks.

There is a loophole in the reasonings of my posts yesterday. I missed one important thing: when the RTC device is being added upon normal system booting, a udev rule gets applied to correctly initialize the system clock from the hardware clock, by taking timezone into consideration. This invalidates my conclusion about bug 63175, but on the contrary confirms the root cause of this bug (bug 89069).

just for the record
i had the same happening here.
The only reason i did not file a bug was i thought it is a feature.
(fsck during 1st boot just to be sure)

side note
happens with debian etch also

i am in cest (utc+2)

i install (with alternate CD) choosing german setting at begining and during 1st boot the fs gets checked.

PS.
on first partition also there is a win here

Patrice, are you sure your hardware clock was set to UTC time? By default, Windows XP presumes that the hardware clock is in local time.

So i'v installed windows xp home french under vmware
After i'v booted on feisty cd, select french on boot menu. creating 1 swap and 1 partition. Using all default options (french keyboard/french local time Europe/Paris...) Made installation and rebooted.

And the bug is here

Screenshot 2

Wenzhuo Zhang : indeed ! Hardware is local time.

Steps to reproduce:

Suppose the current time is 9:00 GMT, and you're in Shanghai, and your computer is connected to the Internet:

1. Enter BIOS and set RTC to 17:00, which is China Standard time GMT+800.

2. Boot feisty-desktop-i386 CD. You'll notice that the Gnome clock shows 9:00+, the current GMT time obtained from a time server by a script invoked by dhcp-client.

3. Start Install. Choose Asia/Shanghai as your timezone.

4. Shortly after installation step 7, you'll notice that the Gnome clock changes to 17:00+. Type date in gnome-terminal, you'll see that it's 17:00 UTC.

5. After Ubiquity installer finishes its job, type "sudo tune2fs -l <rootdevice>", you'll see that the last mount/write time is 17:00+. Since the current timezone is UTC, the last mount/write times are 8 hours ahead of current time.

6. Upon the first boot, fsck complains the last write/mount times are in the future and forces a filesystem check and a system reboot.

Proposed fix: Ubiquity shouldn't touch the system clock. Leave it alone and all is set.

Proposed fix 2: Ubiquity can also set the system clock from the RTC using the chosen timezone. But it must offer users a chance at the same time to specify whether the RTC is in UTC.

On Fri, Apr 20, 2007 at 11:08:58PM -0000, Wenzhuo Zhang wrote:
>
> Assume you are currently in China, and the hardware clock of your
> computer is set to Beijing time (GMT+800) to accommodate the requirement
> of Windows.

OK, this was the missing bit of information. This problem is specific to
the situation where your hardware clock is set to local time. Depending on
how the installer deals with this, this may or may not in fact be a
duplicate fo bug 63175.

Colin, what do you say?

--
 - mdz

> this may or may not in fact be a duplicate fo bug 63175.

Just wanted to make clear. bug 63175 talks about fsck on *every* boot.
The bug here appears one and only at *first* boot after installation.
I use ext3 whereas the reporter in bug 63175 uses jfs - That might be the important difference though.

Matt Zimmerman wrote:
 > OK, this was the missing bit of information. This problem is specific to
> the situation where your hardware clock is set to local time. Depending on

and specific to users in GMT + timezones. By the way, I think most PCs have
their hardware clocks set to local time because of Windows.

Wenzhuo

Yes, I have this issue too.

I'm from Singapore and my timezone is set to GMT + 8.

After I ran sudo tune2fs, I got this error when I tried to boot up into Ubuntu.

In fact, it seems to take 2 boots to get fsck to resolve this issue. It's actually kinda annoying.

So, is there a temporary fix for this?

Same exact problem for me with final 7.04 'Feisty Fawn'.
Only at first boot after choosin ROME (CEST +2.00) as time zone during installation. The system hangs with 'fsck died with exit status 3' and reboots after 5 secons, afterthat all goes fine, or at least as appers.
It's an annoying problem that i think interests many users in '+' time zones. A fix or a workaround would be appreciated.

Thanks for you interest, i really appreciate your work ;)
Please reply as possible

Tried to set BIOS hour to UTC but same problem.

My opinion is that Ubuntu is the best OS ever created and this little missing can discourage seriously a first-time user who installs ubuntu after a life spent with XP, and a critical error at the first boot will bring him back to microsoft side. Something with time is really messed up, because at installation time (with Bios time set to local) when choosing time zone the hour appears wrong (ex.after setting Rome as choosen time-zone, time is shown with two hours more than the real, 8:00 appears as 10:00) but after reboot (2 reboots because of the critical error with fsck) all seems to works fine and the hour shown is the right one (8:00).
This problem should be checked as soon as possible because it can, as already said, discourage who for the first time is approaching this beautiful OS, at major reason if this regards the '+' time zones (this means millions of people).
Hoping for the best, and for an answer (this time ;) )

Bye, Marco.

PS If something seems not clear it's because i'm italian :)

No response?!?

On Fri, Jun 01, 2007 at 07:42:03AM -0000, tillicollaps3 wrote:
> *** This bug is a duplicate of bug 63175 ***
> https://bugs.launchpad.net/bugs/63175
>
> No response?!?

As you can see above, this bug is marked as a duplicate of bug 63175. This
means that further discussion should take place there, since this is a
duplicate report of the same problem.

--
 - mdz

Found a workaround for who has mine same problem (only at first boot after installation - Last mount in future - fsck died with exit status 3), thanks to #ubuntu-it.

Install normally ubuntu, after installation shutdown the system and does not start for so much hours as the difference (+) with GMT is (in my case ROME, boot system 2 hours after installing).
No error messages will appear on first Feisty boot.
enjoy ;)

Gutsy tribe 1 still has the problem. I think this bug is not a duplicate of bug #63175. This bug is the result of a bug in the installer, whereas bug #63175 is probably not.

Still seen in Gutsy Tribe-2 CD.

Proposed bug fix:

If system time has successfully synchronized to a time server, Ubiquity should leave the timezone setting alone.
If not, Ubiquity should offer users a chance to specify whether the hardware clock is UTC or localtime, and updates timezone setting according to user input.

I'v removed duplicate of this bug because :

our problem (fsck) is JUST at the first boot but most of this :

This bug do not exist on Edgy(bug 63175) just since Feisty and Gutsy

I'v removed duplicate (43239) of this bug because in this bug, in our case, fsck automatically check the disk (not in 43239) if the date of the last check seems to be wrong.

No more bug under Tribe5, so i close the Bug.

How is this solved, by fixing Ubiquity or by patching e2fsck to allow for 12 hours' time error? I don't think the latter is the right solution.