|
|
Dual-booting Debian/Windows 2000 and Daylight Saving Time (reprise)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.
|