Aaron Toponce

I've been encountering an interesting issue recently with Debian running as a guest in side of VirtualBox on Windows XP. When I initially installed Debian, I told it to adjust the hardware clock to UTC. Of course, this was the mistake I made. Windows operating systems want the hardware clock set to local time, then the software clock can just read the time directly without changes. Historically, Unix and Linux operating systems set the hardware clock to UTC, then offset the time based on your timezone. So, without thinking, while installing Debian, I told it to adjust the hardware clock to UTC. However, it doesn't seem to have worked, as my hardware clock has stayed on local time.

Why is this a problem? Well, when booting Debian in VirtualBox, it wants to mount the volumes (just a file residing in Windows), but the last mount date timestamp shows a date in the future. This is because I'm 7 hours behind UTC. So, on every boot, I am dropped to an sulogin prompt, where I need to provide the root password to fix the system. Because the last mount date timestamp is in the future, I need to run:

# e2fsck -fy /dev/work/root

This will update the timestamp to the current hardware clock time, at which point I can reboot, and remount the drives. However, when init is loaded, it executes /etc/init.d/hwclock.sh. This script either sets or does not set the hardware clock based on a setting in /etc/default/rcS. Pulling up the file, this is what I found:

#
# /etc/default/rcS
#
# Default settings for the scripts in /etc/rcS.d/
#
# For information about these variables see the rcS(5) manual page.
#
# This file belongs to the "initscripts" package.

TMPTIME=0
SULOGIN=no
DELAYLOGIN=no
UTC=yes
VERBOSE=no
FSCKFIX=no
RAMRUN=no
RAMLOCK=no

Notice the setting "UTC=yes". This means to change the hardware clock to UTC time when booting. Of course, this also means setting the timestamp on the mounted filesystems to the UTC date. Because Windows is my host operating system, I don't want to do this. So, changing the value to "no" fixes the issue I'm having with the last mount time on my volumes being in the future. I probably should have mentioned that this init system is good old fashioned SysV Init. I haven't upgraded to Upstart yet, although that's on the TODO. I'm not sure how this post would change with Upstart in the picture, but when I upgrade, I'll likely post the solution if I'm faced with the same issue again.

Hope this post helps someone in the future who has also had this problem.