Somewhat tardily, I noticed that the solution I had used before to ensure Debian did not handle the change to daylight saving time had stopped working on my dual-boot Debian/Windows 2000 machine. Windows 2000 had changed to British Summer Time, but the next Debian boot produced a system that was one hour too fast.
At first I assumed that the UTC setting had changed back to "yes"
due to upgrades. However, that wasn't the case; UTC=no was
still set in the /etc/default/rcS file.
After banging my head against hwclock for a while, I
finally discovered that the invocation of hwclock.sh was
too early in the boot process. In /etc/rcS.d the order of
the startup scripts is as follows:
README S22hwclock.sh S40networking S01glibc.sh S25libdevmapper1.00 S43portmap S02mountvirtfs S30checkfs.sh S45mountnfs.sh S05bootlogd S30etc-setserial S46setserial S05initrd-tools.sh S30procps.sh S48console-screen.sh S05keymap.sh S35mountall.sh S55bootmisc.sh S10checkroot.sh S36mountvirtfs S55urandom S18hwclockfirst.sh S38pppd-dns S70nviboot S18ifupdown-clean S39dns-clean S70screen-cleanup S20module-init-tools S39ifupdown S70x11-common S20modutils S40hostname.sh S71xserver-xorg
You will note that hwclock.sh is set to run before the
disks are mounted. This means that it cannot access
/etc/localtime which is a link to the machine's timezone.
Hence, when hwclock.sh sets the system time, it uses the
default timezone of UTC, not the correct local timezone of BST.
To allow hwclock.sh to know the local time zone, I
renumbered it to S36hwclock.sh, thereby ensuring it was run
after the local disks had been mounted, and the script could then
access /etc/localtime. The new contents of
/etc/rcS.d are shown below:
README S25libdevmapper1.00 S40networking S01glibc.sh S30checkfs.sh S43portmap S02mountvirtfs S30etc-setserial S45mountnfs.sh S05bootlogd S30procps.sh S46setserial S05initrd-tools.sh S35mountall.sh S48console-screen.sh S05keymap.sh S36hwclock.sh S55bootmisc.sh S10checkroot.sh S36mountvirtfs S55urandom S18hwclockfirst.sh S38pppd-dns S70nviboot S18ifupdown-clean S39dns-clean S70screen-cleanup S20module-init-tools S39ifupdown S70x11-common S20modutils S40hostname.sh S71xserver-xorg
I can only assume that one of the many apt-get upgrade
processes I had run caused this mis-ordering of startup scripts.
I suspect this entry is mostly bogus, and anyway is now untrue of the current Debian stable Wheezy. See this later entry.
