Frans Pop wrote: > I agree about merging clock-setup and tzsetup. The logic is getting > intertwined now.
So far I haven't needed to do that. I've done the basic reorg and work to make rdate be used, but left a lot of TODO items: * detect large differences between rdate and the system clock, and prompt before setting the clock * pass rdate time adjustment info to tzsetup, so it can use it to make guesses about timezones (vorlon) * pass rdate time adjustment info to finish-install script, so it can use it to make guesses (how?) to fine-tune its default answer to the UTC question * run hwclock at end (And testing.) I'll wait for more comments before committing. > > I propose moving the question to the > > finish-install hook that actually modifies the config files for non-UTC > > systems. Most of the time users won't see the question at all, and > > putting it here, users with dual-boot systems will have just dealt with > > that in bootloader configuration, so it's natural that another question > > about multi-OS stuff comes here. > > Let me see if I understand: > - early in install: > - run rdate without changing the system clock > - compare rdate output and current system clock to > - check sanity of hardware clock > - determine if hardware clock is on UTC or not You could do the above to guess at whether the hardware clock is on UTC at this point, as an adjunct to the later use of os-prober. I don't know if I'll actually implement that. I don't know exactly how to implement the sanity check either; it would be nice to avoid running rdate twice. > - use country and previous to > - check if clock is sane (if country has single timezone; for > countries with more TZs it should still fit in the range) > - determine default timezone (countres with more TZs) Could be implemented, yes. > - set system time (using UTC) > - late in the install: > - using os-prober info, determine if system should be on UTC or local > - ask user if unsure > - set hardware clock if needed (ask user if unsure) > The only question may be: how does having installed using UTC and possible > switching to localtime affect the reboot. There's no switch to localtime. Recall that the only clock that might be in localtime is the hardware clock. The system clock is *always* in UTC internally. The system is installed using the correct time. The correct time is then written to the hardware clock, offset to localtime as needed. When the installed system is booted, the time is read from the hardware clock, offset from localtime to UTC as needed, and the system clock is, once again, set to the correct time. > This is different from what we do now as we now basically use the system > clock for the install, and thus create files using local time if that is > what the clock is set to. > I think this could create problems for users who are in a negative TZ (or > maybe positive, not sure and too lazy to think it out ATM). Currently systems are installed using whatever time is in the hardware clock. That time is assumed to be in UTC. When the installed system is booted, if the hardware clock is now known to be in localtime, it'll be offset to UTC when the system clock is set. Yes, I think this could make the system clock run back to an earlier time than the install happened in. It won't lead to unnecessary fscking, of course, but could have some strange effects. Since we haven't heard of any AFAIK, they're probably small. > Maybe the "late in the install" bits should instead be done immediately > after partitioning to solve this? The time at which the hardware clock is set will not affect system clock or the timestamps written to disk in any way. It could be done at any point. > > Looking at the menu layout, that leaves user-setup as the only normally > > interactive thing between partman formatting the disks and apt-setup > > running at the end of base-installer. user-setup has no dependencies, > > so it can be moved out of that location. I suggest moving it to run > > just before apt-setup. > > Seems OK. I wonder if we should then just commit the user settings in the > postinst instead of during finish-install. I'd prefer not to lose the flexability of being able to move user-setup around, even before partman if desired. -- see shy jo
signature.asc
Description: Digital signature
