UTC should be "no" when installing under VirtualBox

I've seen this after what I *thought* was a normal / safe shutdown. I'll pay careful attention to future shutdowns and report if I can confirm.

User accidentally changed status.

I'm not sure if Micah's message means this is *not* fixed, but I can confirm the problem. I did unclean shutdown and the problem went away on restart fsck.

We have a proposed patch that we are testing that fixes the problem for ext4; if that patch works, then the upstream author will supply a patch for ext3 as well and they should be in our kernel for alpha 6.

Replacement kernel images for i386 are available here for testing (ext4 only):

http://people.canonical.com/~apw/lp427822-karmic/

Only fixes ext4 (so far).
http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-karmic.git;a=commit;h=380d5fd820ea762f894601871c1da118cdf1a13c

This bug was fixed in the package linux - 2.6.31-10.33

---------------
linux (2.6.31-10.33) karmic; urgency=low

  [ Leann Ogasawara ]

  * [Upstream] dvb-usb: fix tuning with Cinergy T2
    - LP: #421258

  [ Tim Gardner ]

  * [Config] Unconditionally copy files from sub-flavours lists.
    (really, really fix it this time)
    - LP: #423426
  * [Config] Set CONFIG_CACHEFILES=m for all flavours

  [ Upstream Kernel Changes ]

  * ext4: Don't update superblock write time when filesystem is read-only
    - LP: #427822

 -- Tim Gardner <email address hidden> Tue, 15 Sep 2009 07:50:21 -0600

Here's the patch for ext3.

Fixes ext3:

http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-karmic.git;a=commit;h=ad65780959cb5fc04f2b64c6b2eec34272d10e81

This is believed to be fixed in the latest upload of the linux package. Changelog:

linux (2.6.31-10.34) karmic; urgency=low

  [ Ted Tso ]

  * [Upstream] ext3: Don't update superblock write time when filesystem is
    read-only
    - LP: #427622

Is the e2fsprogs task still relevant, or should it be closed invalid?

On Wed, Sep 16, 2009 at 10:23:30AM -0000, Steve Langasek wrote:
> Is the e2fsprogs task still relevant, or should it be closed invalid?

It should be closed invalid.

I wonder how to apply the patch??
Here, at boot, it inevitably runs in circles, showing the inconsistencies. Meaning that I can't enter Ctrl-D or whatnot. At least, I tried everything. It simply keeps flashing by the inconsistencies on all partitions. The only thing it does accept is Ctrl-Alt-Del, for a reboot.
I don't want to lose this install, and ought not have to lose it, I guess. There must be a way to stop the mountall from repeatedly trying to mount and flashing by the 'time is in the future'.

What to do, please?

Uwe

Uwe, sounds like you have a more complicated issue. However, I'd suggest you upgrade your system in a chroot, see https://wiki.ubuntu.com/ChrootRecovery

I did a update-manager -d last night (Sept 22 CST) and it rendered the system useless after the first reboot, I was stuck in this cycle. I don't think Uwe is experiencing more complicated issue, I think a lot of people are experiencing it. I will monitor this bug if you want me to test anything to provide additional information.

Why not wait until the UTC passed the date of the last write ?
For gmt+4, is to wait 4hours beforce booting the system again.
So the condition of the bug won't be present.
Then update to the correct version.

Problem fixed for me by one of recent updates. ext4, GMT+4.

Seems there was a regression since Alpha 6.
Problem came back with updates from yesterday, and today's updates didn't seem to have fixed it, although I can't be sure since fschk is only launched if errors in the filesystem are found on bootup.

GMT+2 - fortunately this lets me retry less than 2h after first boot.

To be precise:
Ext4
I last experienced this bug today after rebooting from my update to kernel 2.6.31-10.35
Seems it was OK before that (except that I have a whole lot of messages on bootup in addition to the PBLK one which I got used to since post alpha 5).
The bug was a recurring issue on almost every other update.

Sébastien Bernard wrote:
> Why not wait until the UTC passed the date of the last write ?
> For gmt+4, is to wait 4hours beforce booting the system again.
> So the condition of the bug won't be present.
> Then update to the correct version.
>
>

I'm not clear what you mean with 'update to the correct version' here.
The correct version of what? Kernel?
But the old kernel (2.6.28.15) does the same thing here, when I boot to
it. It was still around after the update.
Therefore I am a bit lost with your words.

Uwe

Sébastien:

If I understand this bug correctly (and my experience corroborates this) it's not a timing issue between shutdown and startup - it's a timing issue between various parts of the startup process, so waiting with the machine powered down should not have any effect on the bug.

Still affecting Ubuntu alpha 6 with updates as of 27 Sep 09.

I can boot the first time in the morning, but if I shut down then attempt to boot again, I never get to the login screen.

I've attached yesterday's syslog with the first (successful) then subsequent (unsuccessful) boot attempts; hope it helps.

Ubuntu alpha 6 in VBox 3.0.6 on ubuntu 8.04.3.

When I reboot ubuntu 9.10 after doing an update (apt-get dist-upgrade) I frequently have to fsck my filesystem, because the superblock last mount time is two hours in the future. Doesn't feel like a fixed problem to me.

Or is this yet another timezone/fsck problem?

I have no fsck-problems if I just reboot (without doing any updates).

My timezone is Europe/Berlin (GMT +1 + summertime, so currently GMT +2).

@Michael Kofler:
Do you use 9.10 in a virtual machine or on a real machine ?

I am always seeing this in a virtual machine on reboot (same timezone like you).
But I am not sure whether it is a bug of VirtualBox.

@Glenn -- the bug related there should trigger an fsck running on your console, when that completes you should then see the normal login screen. If you never get it then it seems you have a different bug.

@Micheal -- I am supprised that an update could trigger this issue. The issue should only show up on a 'crash' ie when the system is not shutdown correctly. The filesystem has to be marked dirty. That said we would also expect that to be fixed by a pair of kernel patches one for ext2 and one for ext3. Could you confirm which version of the kernel you see this on (cat /proc/version_signature) and also which filesystem type your root filesystem is. Thanks!

This is the message I get, running karmic alpha 6 with latest updates, after I did a "sudo reboot" in a terminal. Note the different time values shown.

On Thu, 2009-10-01 at 10:31 +0000, Daniel Fett wrote:

> This is the message I get, running karmic alpha 6 with latest updates,
> after I did a "sudo reboot" in a terminal. Note the different time
> values shown.
>
I would guess that you're in UTC+0200 ?

Most importantly - what *was* the correct time when you took this
screenshot?

So far in all of the reports, it's been the last mount time that was
incorrect rather than the "now" time - is that true for you too?

Scott
--
Scott James Remnant
<email address hidden>

@Andy -- the bug indeed triggers an fsck, however it can't run as the hard drive is encrypted. I can't run a manual fsck either because the boot process skips right by it then hangs. I'm attempting to attach a screenshot showing the hang point.

Edit - attach clearer screenshot.

@Andy -- the bug indeed triggers an fsck, however it can't run as the hard drive is encrypted. I can't run a manual fsck either because the boot process skips right by it then hangs. I'm attempting to attach a screenshot showing the hang point.

This happened to me today with karmic beta. I installed in virtualbox, and it seemed
to work fine, but then to set up shared folders, I had to reboot... now it says

  /dev/sda1: Superblock last mount time (Fri Oct 9 12:47:47 2009,
    now = Fri Oct 9 :5:54:32 2009) is in the future.

I'm in Los Angeles, UTC+7 or so, so it does seem like a UTC/localtime disagreement.)

So it doesn't seem fixed to me. Workaround: at the diagnostic root prompt, type
  mount -o remount /
  ^D
and then CTL-ALT-DEL. (presumably the reboot command would have done fine, too.)
It then seems to boot normally.

On Fri, 2009-10-09 at 20:01 +0000, Dan Kegel wrote:

> /dev/sda1: Superblock last mount time (Fri Oct 9 12:47:47 2009,
> now = Fri Oct 9 :5:54:32 2009) is in the future.
>
> I'm in Los Angeles, UTC+7 or so, so it does seem like a UTC/localtime
> disagreement.)
>
Which of the two was the _correct_ time?

Scott
--
Scott James Remnant
<email address hidden>

I'm getting the same behavior as described by https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/427822/comments/23.

- running Karmic in VirtualBox 3.0.8
- /proc/version_signature: Ubuntu 2.6.31-13.43-generic
- my timezone is Europe/Berlin (currently GMT+2)

/dev/sda1: Superblock last mount time (Sat Oct 10 20:00:26 2009, now = Sat Oct 10 18:05:13 2009) is in the future.

Where "now" (18:05:13) is the correct time.
The error can indeed be triggered by just installing available updates through update-manager.

On Sat, 2009-10-10 at 16:28 +0000, Alexander Gitter wrote:

> I'm getting the same behavior as described by
> https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/427822/comments/23.
>
> - running Karmic in VirtualBox 3.0.8
> - /proc/version_signature: Ubuntu 2.6.31-13.43-generic
> - my timezone is Europe/Berlin (currently GMT+2)
>
> /dev/sda1: Superblock last mount time (Sat Oct 10 20:00:26 2009, now =
> Sat Oct 10 18:05:13 2009) is in the future.
>
> Where "now" (18:05:13) is the correct time.
> The error can indeed be triggered by just installing available updates through update-manager.
>
*sigh*

If "now" is correct, why would the last mount time be incorrect?

Was this the second time you booted the machine, or a different?

The bit about installing updates intrigues me, you're saying that
updates result in this happening on the next reboot?

Scott
--
Scott James Remnant
<email address hidden>

> Was this the second time you booted the machine, or a different?

This machine has been booted a couple of times already and it usually comes up without an error.

> The bit about installing updates intrigues me, you're saying that updates result in this happening on the next reboot?

Exactly. It doesn't seem to be coupled to any particular package or something like this.
Last time there was only one single update (https://lists.ubuntu.com/archives/karmic-changes/2009-October/010704.html). After update-manager was finished, I rebooted the machine with the fusa and got the error I posted above.

I did some more tests and interestingly the error appears on the first _reboot_ after an update. It seems as if there can be any number of shut down/start up cycles inbetween - those won't trigger the error. I tested different variants of that a couple of times and it seems to be reproducible.

By the way, it doesn't matter if I have the VirtualBox guest additions installed or not. But I could also try this out on a physical box if that helps.

To follow up on my last post, the problem doesn't seem to be related to updates at all. Further tests have shown that the error can be produced everytime the system is rebootet - provided that there was at least one shutdown since the last reboot.
(There just hasn't been the need to reboot except after updates that required it, so...)

Also did a fresh install with ext3 and I'm able to reproduce the issue there, too.

I changed /etc/init/mountall.conf to print out the current time before it execs mountall:
--- snip ---
console output

script
    echo "/etc/init/mountall.conf: `date`"
    . /etc/default/rcS
--- /snip ---

Now have a look at the attached picture. You can see that the output from mountall.conf contains the wrong date.
At the very bottom I had tune2fs print out the last mount time and it's indeed the wrong one. Thus leading to an fsck error on next reboot. If I don't do a reboot but a shutdown instead, the error won't show up on next boot, because the time would be wrong again.
Also notice that 'date' spits out the correct time after I was able to login.

An installation on my physical machine has the issue, too. But it happens pretty randomly there and I haven't found a regularity (such as 'after each shutdown') as with VirtualBox.

Turns out that in /etc/default/rcS UTC was set to "yes", when instead it should've been "no" as I use a local timezone.
So this is probably an installer bug after all.

Okay my last comment wasn't quite correct. Of cource UTC is correctly set to "yes" when os-prober indicates that Ubuntu is the only operating system. So the thing with the wrong time might really be a VirtualBox bug.

Now here is something interesting, I tried this out with Jaunty.
I realised that the underlying problem exists there, too. The filesystem has a last mount time in the future, just as with Karmic. But Jaunty doesn't seem to check whether the last mount time is in the future. (or automatically corrects it, I don't know exactly)

Indeed, jaunty had a switch to fsck to "automatically repair" that issue - upstream put it there claiming we had buggy init scripts.

We took it out because we're damned sure our scripts are right (the fact the "now" time is always correct when you hit the fsck shell confirms that), and wanted to see what other bugs were underneath.

Enough duplicates of this issue now appear, which after debugging turn out to be local configuration issues, hardware clock reliability issues, virtualisation issues, and simple human error issues, that I'm convinced that "automatic repair" is the right way forward.

I'll be patching e2fsck today to fix that issue with -a again

Colin, feel free to bat this to virtualbox for having the wrong timezone in its emulated hardware clock ;-)

Sorry I shouldn't have added the VirtualBox bugwatch, as it's obviously another bug. It's relatd to this one though.

http://www.virtualbox.org/ticket/1310

It seems to me this is now resolved in virtualbox upsream, e2fsprogs and linux kernel. Thus making ubiquity tasks redundant. Please correct this status if there is still something left to do on ubiquity side.