Two other things about running rdate:
1. It would be best to run it only once. Maybe twice if we have to; 3
and 4 times are right out. Slow.
2. It would be best if d-i could run rdate before partman, assuring that
the disks are formatted with the time set correctly.
We could move tzsetup to run before partman and do it from there;
although it's slightly out of scope for tzsetup, there are other ways
that tzsetup can use rdate information[1]. Or we could add a new udeb
that runs rdate. This would let experts skip it in the menu, and it
could store the rdate info for use by tzsetup, clock-setup, etc.
We can only run rdate before partman if we don't need to look at
os-proper to decide whether to run rdate. The only case I listed where
we might not want to run rdate is when there's another OS installed.
It's probably wrong to set the clock in cases such as a windows install
that is set to using a different time zone than you tell d-i to use, or
a system that has the clock set to 1999 to avoid Y2K issues, license key
expiry, etc. But otherwise, as long as d-i gets the localtime setting
right for the other OS, it should be ok to set the clock.
We could either decide we don't want to worry about supporting such
broken setups. Or, we could ask before setting the clock. IMHO, if we
ask a question, it should only be shown if the clock is far off of
normal. Ie, not for a 10 minute adjustment. But, it would be tricky for
the udeb that called rdate to display a question before setting the
date, since it wouldn't be able to use the user's timezone, since it
runs before tzsetup. Anyone want to use debconf templates to localise a
string like «Your clock is 1 hour and 10 minutes fast. Fix it?» ? Aargh.
Running hwclock also has some complications. We'd need to copy any
/dev/rtc to /target, or bind mount d-i's /dev to /target for the hwclock
run, or something. For the nslu2 there are some special cases that are
handled in nslu2-utils that d-i would have to deal with: We'd need to
include the rtc-dev kernel module in d-i, load it, and make a /dev/rtc ->
/dev/rtc0 symlink. Probably there are other special cases for other
subarches, especially on arm.
--
see shy jo
[1] rdate's offset information could be used to guess at a good default
timezone for countries with multiple zones
Attachment:
signature.asc
Description: Digital signature