CopyDisable

Friday, 14 December 2012

Ubuntu system time issue

Well, I would like to share a nice experience with you. One of our Ubuntu VM (running on Citrix Xen) had some problem, sometimes it’s root partition (which is a LVM volume) becomes read-only. On restart it stops with fsck checking the root partition and reporting error (as reported by Sysadmin team). On checking boot log I found

/dev/mapper/ET2012DevDB-root: Superblock last mount time (Thu Dec 13 10:44:16 2012,

                now = Fri Aug  3 03:04:03 2012) is in the future.

/dev/mapper/ET2012DevDB-root: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.

                (i.e., without -a or -p options)

/dev/xvda1: Superblock last write time (Thu Dec 13 14:55:07 2012,

                now = Fri Aug  3 03:04:03 2012) is in the future.

I found that this issue is related to time settings with the VM. Normally it happens because of time difference with the hardware (BIOS) clock.

As OS boots up it tries to mount the ROOT partition and it finds that the superblock of the partition has a future time, as it compares the time with the hardware clock. In the log you can find that the hardware clock is having time of August 2012 and right now we are in December 2012. So it finds that the superblock write time is in future. That’s why it starts the disk checking program fsck.

The date command was showing correct date and time, when I tried to check the hardware clock time

# hwclock --show
hwclock: Cannot access the Hardware Clock via any known method.
hwclock: Use the --debug option to see the details of our search for an access method.

On some searching I found that hwclock command does not work on guest VMs, as guest VMs cannot directly access the hardware clock.

So I talked to Sysadmin team and they changed the time of the VM (sync with in.pool.ntp.org).

Now after reboot, the VM started normally this time. On checking the boot.log this time I found:

/dev/mapper/ET2012DevDB-root: clean, 94294/425152 files, 791932/1698816 blocks

/dev/xvda1: Superblock last write time is in the future.

        (by less than a day, probably due to the hardware clock being incorrectly set).  FIXED.

 

Still there is some difference, but this time difference it is less than a day, so the file system check is ignored by the system.

So fine tuning the time this problem can be resolved Smile.