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
signature.asc
Description: Digital signature