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
(Dropping CC to d-boot as it'll end up on the list anyway :-)
On Monday 23 July 2007 01:47, Joey Hess wrote:
> Rather than have two or three clock-related things on the menu, I
> propose we have one clock-setup menu item, that runs after netcfg. This
> would include both calling tzsetup, as well a
Now I'm considering moving a lot of stuff around. CCing boot since this
is expanding beyond just one package.
Rather than have two or three clock-related things on the menu, I
propose we have one clock-setup menu item, that runs after netcfg. This
would include both calling tzsetup, as well as usi
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
On Saturday 21 July 2007 23:15, Joey Hess wrote:
> * clock obviously not set correctly
>
> This can be identified in various ways, but if the clock is clearly not
> set right (ie, 1970, or < d-i image build date) then it should be ok
> for d-i to run rdate and hwclock to set it.
If we can get a da
Leaving aside issues of UTC detection, timezone detection, etc by using
rdate, here are some thoughts on when d-i should set the date.
Some different scenarios:
* clock obviously not set correctly
This can be identified in various ways, but if the clock is clearly not
set right (ie, 1970, or < d
6 matches
Mail list logo
