Extreme long (and random) delays during boot using fetch=http://...
Hi guys,
I'm not sure whether to report this to live-boot or wget, so I'm asking
in advance.
I just tried to pxeboot the new Kali release 2016-2 from just a few days
ago an ran into an annoying, extremely long (and somewhat random) delay
in the live-boot phase when using fetch=http://.../filesystem.squashfs.
kernel: 4.6.0-kali1-amd64
busybox: 1:1.22.0-19 (Kali versioning)
live-boot: 1:20160511
wget: 1.18-2+b1 (Kali versioning)
Turns out, when wget was run from /lib/live/boot/9990-mount-http.sh:44,
the process started, but apparently was just hanging around. There
wasn't even a TCP SYN going over the wire to the http server. After some
time, the kernel printed
[ 79.xxx] random: nonblocking pool is initialized
and wget went about its course and the boot continued as desired.
Then I packed strace into the initrd, prepended the wget call with it
and noticed a syscall to getrandom() which blocked, until the kernel msg
above appeared.
Since I never had this kind of trouble before (neither Kali 2016-1 nor
Debian), I expected the culprit to be wget itself. So I replaced the
call to `wget "${url}...` by `busybox wget "${url}...` and in the
following attempts to pxeboot/fetch kali, wget worked instantaneously.
My suggestion is:
1. Implement the workaround `wget` --> `busybox wget` in live-boot (do
you guys want this to be filed as a bug?)
2. maybe file a bug report against wget to not rely on PRNG when there
is no clear reason (i.e. SSL) to do so...
So...the obvious question is: has anyone here encountered a similar
problem with pxeboot/fetch'ing Debian Live images?
What's your take on this?
Thanks
Daniel
Reply to: