Package: debian-installer
Severity: normal
Dear Debian Installer team,
First of all, I reside in a place where all access to internet is
through HTTP proxy, but we have a Debian mirror which is accessible
from inside without proxy.
I just tried one of the daily build netboot installer, and the
Processing commands for [EMAIL PROTECTED]:
reassign 448871 clock-setup 0.92
Bug#448871: Should give us the option of syncing time
Bug reassigned from package `debian-installer' to `clock-setup'.
severity 448871 important
Bug#448871: Should give us the option of syncing time
Severity set
reassign 448871 clock-setup 0.92
severity 448871 important
thanks
On Thursday 01 November 2007, Kumar Appaiah wrote:
I just tried one of the daily build netboot installer, and the only
problem I faced is that it just waited at the ntp syncing stage. I
don't know whether it times out, but I
Frans Pop [EMAIL PROTECTED] writes:
reassign 448871 clock-setup 0.92
severity 448871 important
thanks
On Thursday 01 November 2007, Kumar Appaiah wrote:
I just tried one of the daily build netboot installer, and the only
problem I faced is that it just waited at the ntp syncing stage. I
Frans Pop wrote:
This basically means that the current time-out is just too long for
practical use as is.
An alternative option could be to make it possible to cancel the action,
just like we do for looking for a DHCP server.
Yep, all network-facing progress bars in d-i need a cancel
block 448871 436497
thanks
The clock-setup progress bar cannot safely be made cancelable until this
bug in newt is fixed. To make the progress bar cancelable, clock-setup
would need to use PROGRESS INFO or PROGRESS_STEP periodically to poll
for a return code indicating cancel was hit. But both of
Using ntp to set the time should be a short operation. If it takes a
long time, the validity of the time that results is in question -- by
virtue of the process[*] being used.
Rick
[*] For those who care, it works roughly like this:
One or more polls are sent from the client to each of
Rick Thomas wrote:
Using ntp to set the time should be a short operation. If it takes a
long time, the validity of the time that results is in question -- by
virtue of the process[*] being used.
Unless it's slow becuase of something like the initial DNS lookup.
-jim
--
To
Rick Thomas wrote:
Using ntp to set the time should be a short operation. If it takes a long
time, the validity of the time that results is in question -- by virtue of
the process[*] being used.
Careful, you're confusing SNTP and NTP. You're also oversimplifying. NTP
is very good at
On Nov 1, 2007, at 3:06 PM, Jim Paris wrote:
Rick Thomas wrote:
Using ntp to set the time should be a short operation. If it takes a
long time, the validity of the time that results is in question -- by
virtue of the process[*] being used.
Unless it's slow becuase of something like the
Ahhh... So the installer time-setter uses rdate, not NTP? A wise
choice, now that I think about it. Much lighter weight protocol, and
the client is much *much* smaller.
Infact, rdate doesn't even use SNTP. It just asks the server for the
time of day (one second resolution) and puts it
Rick Thomas wrote:
Ahhh... So the installer time-setter uses rdate, not NTP? A wise choice,
now that I think about it. Much lighter weight protocol, and the client is
much *much* smaller.
Infact, rdate doesn't even use SNTP.
rdate, as used by the installer, uses SNTP.
The point
On Nov 1, 2007, at 7:02 PM, Joey Hess wrote:
rdate, as used by the installer, uses SNTP.
A... (again) This was added fairly recently. Interesting.
The point remains. The uncertainty in the time from the server is
proportional (or worse) to the network delay.
Not with SNTP it
13 matches
Mail list logo
