Comment 40 for bug 8414

Summary:

hwclock needs the rtc module, because it needs the /dev/rtc device.

The rtc module is loaded automatically if there is an PNP0b00 device on the system, this appears to be true on both i386 and amd64 machines.

The above would have been broken for a while in dapper due to the general breakage of the kernel's PNP subsystem which has been fixed for a while.

The rtc module also appears to be explicitly seeded in /etc/modules "just in case" -- I suspect this is a bogus fix, but there may be machines which don't list the rtc in their pnp table (pre-PCI i386 and i486 perhaps)

That's loaded by /etc/rcS.d/S15module-init-tools when it iterates /etc/modules

hwclock is started in two places. The first is by a udev rule that is activated whenever the /dev/rtc device is added to the system; this is pretty failsafe no matter where the device shows up in the boot process.

The other is by /etc/rcS.d/S50hwclock.sh explicitly, which is the first point after /usr has been mounted.

So as far as I know, this should be completely fixed in dapper.

Other interesting hwclock-related bugs (while we're on the subject):
- hwclock needs /etc/localtime which is a symlink to something under /usr, which may be on a different filesystem
- dhclient fails in amusing ways if UTC=no and hwclock has not been run
- thus /usr can't be on a dhcp networked filesystem if UTC=no
- also if rtc is loaded by /etc/modules, it'll be loaded after dhclient is started, so that won't work either