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
