imgfetch stuck mid-download

[Geth]

Hi,

I'm a netboot rookie and I'm using iPXE version "aa4b0", in BIOS mode generally ipxe.pxe (more on that later).
First, I've wanted two things to work: Memtest86 and WinPE(10) with EFI and BIOS mode.
EFI mode is working OK, both stuff. (Memtest86 version is Memtest86 7.0.0 Beta 1 -- I cannot get it to use supplied mt86.cfg, but I think it's a Memtest86 bug).

Now the BIOS mode.
I want to use Memtest86 4.3.7 (NOT Memtest86+ 5.0.1).
If I just chainload it from iPXE, it fails with known error 460381.
Going the longer way (iPXE -> pxelinux 6.03 -> memtest) it's working:

set filename lpxelinux.0
set next-server 192.168.x.y # same server
set root-path http://<local http server address>/
chain ${root-path}${filename}

Done. Going for WinPE by the book (latest wimboot), so there are a couple of imgfetch calls.
Sometimes it works, but more often it gets stuck in the middle of a download (sometimes it happens in the middle of a font file, other times it's the .wim file). It's not frozen, it's just not advancing.
(I could try a timeout loop per file, but it's a working LAN environment, it should work hassle-free.)

I've switched back to undionly.kpxe. It boots 3 out of 3 times successfully, no hiccups.
Unfortunately, now the previously working memtest part fails:
Booting kernel failed: Invalid argument

The BIOS PC is equipped with a onboard rtl8168 (LAN ROM 2.59).

So, I would go with ipxe.pxe instead of undionly.kpxe, but than I don't know why imgfetch is not working ALL the time.

Any ideas? What other info would help?

[mcb30]

(2016-05-30 10:11)Geth Wrote:  Done. Going for WinPE by the book (latest wimboot), so there are a couple of imgfetch calls.

What is the exact iPXE script that you are using to load WinPE?

Quote:Sometimes it works, but more often it gets stuck in the middle of a download (sometimes it happens in the middle of a font file, other times it's the .wim file). It's not frozen, it's just not advancing.

What are the symptoms? Do you see TCP retransmissions showing up in a packet capture? Does "ifstat" report packets being received? On the server side, does "arp -n" show an entry for iPXE's IP address? Are you still able to ping iPXE from the server?

Michael

[Geth]

(2016-06-03 16:35)mcb30 Wrote:  What is the exact iPXE script that you are using to load WinPE?

The most recent one (I've read that font files are redundant long since):

Code:

imgfetch --name Boot.wim Boot.amd64.wim Boot.wim
imgfetch --name BCD BCD BCD
imgfetch --name Boot.sdi Boot.sdi Boot.sdi
chain wimboot gui

(2016-06-03 16:35)mcb30 Wrote:  What are the symptoms? Do you see TCP retransmissions showing up in a packet capture? Does "ifstat" report packets being received? On the server side, does "arp -n" show an entry for iPXE's IP address? Are you still able to ping iPXE from the server?

I haven't got any time to test all this (and therefore I don't expect any advancement), also I switched to undionly.kpxe and memtest.0, so I don't experience this anymore.

While I was still there, I've tried to put 5sec timeout on .wim fetch, and monitor ifstat before and after it failed (or not). I've realized that error packet counter growing steadily between trials. In the meantime I've pinged constantly from the server: the almost zero ping went up during the not-so-fast download (which may or may not timed out later) to an almost constant 1000ms.

After I've scratched that concept blaming my buggy BIOS/NIC/etc, and switched to undionly, checking ifstat before/after (successful) fetch: 0 error packets, but of course that was expected.
Anyway I'm using undionly.kpxe now, after a little slower init, it's fast and reliable.