Booting wds without wimboot

[chmeyer]

Hello there,

I'm responsible for keeping some Clients running without beeing a "real" admin. Usually I'm just (re-)installing the clients via PXE (LAN-card with bootROM). Configuration and installing additional software to the clients is done by paid admins over the internet.
Some of the bootROMs in my machines seems to be broken so that I thought I could (re)install the clients with a iPXE-CD.

The local Windows Server (DC, DHCP, TFTP, ...) is 2008, PXE-boot is with WDS.
Booting the iPXE-CD works fine, dhcp and loading of wdsnbp.com works out of the box, too.
But: TFTP download of pxeboot.n12 seems to start several times and fails in the end.

I don't know what the problem of this failure is. I tried via commandline but failed, too.
Is there a way to work around the problem?
Your most recommended installation method for this case is the use of wimboot. This sadly is not possible in my case since I do not have write access to the Windows server.

But I think there should be a way lo load boot.sdi or boot.wim directly with iPXE so that iPXE can replace the broken or missing bootROMs of my network cards, but I didn't find a solution (without wimboot) so far.

Thanks for any ideas
Christian

[robinsmidsrod]

Most likely what you're seeing is a driver issue with the native iPXE driver on that particular hardware. If you build ipxe.iso with the DEBUG=realtek or DEBUG=intel or whatever NIC hardware you have in the problematic machine you might be able to get further. The ifstat command should tell you which driver you're actually using. Once you know that you can go through the checklist at http://ipxe.org/dev/driver and report back what works and what fails.

[chmeyer]

Thank you for your reply. I'm not so good in building software but I will try it when there ist time left.
In the meantime I figured out some more details with the downloaded ipxe.iso:

After many, many lines:
TFTP Download: boot\x86\n12
.
TFTP Download: boot\x86\n12
.
TFTP Download: boot\x86\n12
.
TFTP Download: boot\x86\n12

Failed to restart TFTP.
TFTP download failedCould not boot image: Error 0x7f8d101 (http://ipxe.org/7f8d8101)
No more network devices.

iPXE> ifstat
net0: xx:xx:xx:xx:xx:xx using 82547ei on PCI02:01.0 (open)
[Link:up, TX:102 TXE:0 RX:461 RXE:219]
[RXE: 118 x "Operation not supported (http://ipxe.org/3c086003)"]
[RXE: 83 x "Error 0x2a07e006 (http://ipxe.org/2a07e006)"]
[RXE: 18 x "The socket is not connected (http://ipxe.org/380a6001)"]
iPXE>

The same problem occured on a different machine, too. IIRC I there read something about intel driver.
Sorry, I feel badly lost in so many error messages.
Any hints for a workaround or how to provide more information?

Thank you
Christian

[robinsmidsrod]

From the error http://ipxe.org/err/7f8d8101 it seems like this is not an error that comes directly from iPXE, but from an external program that uses iPXE's PXE API. Most likely the Windows pxeboot.n12 binary.

Based on the output from ifstat you're using the intel driver (82547ei), so adding some additional debugging for that one might yield some more information.

Code:

make bin/ipxe.iso DEBUG=intel

should probably give you something to work with.

[chmeyer]

Okay, I don't belve that it is an intel networkcard problem since I saw an similar behaviour on a different machine (x64 instead of x86) with rtl8168 driver: Error 0x7f8d101 and 3c086003 with 2a07e006. Only the "socket is not connected error" is missing.

But one after another.
Let's have a look with the initial intel driver (82547ei) machine and ipxe "DEBUG=intel":
Some red lines appear:
1) after loading ipxe.krn and iPXE initialising devices:
INTEL 0xbddc4 MAC+PHY reset (ctrl003c0261)
INTEL 0xbddc4 has autoloaded MAC adress 00:xx:xx:xx:xx:xx (anonymized)
INTEL 0xbddc4 link status is 00000380

2) after Features: AoE HTTP iSCSI DNS TFTP SRP bzImage ELF MBOOT PXE PXEXT Menu
INTEL 0xbddc4 ring 03800 is at [1f64be00,1f64bf00)
INTEL 0xbddc4 ring 02800 is at [1f64bf00,1f64c000)
INTEL 0xbddc4 link status is 00000381

3) after net0: ... [Link status: Down ...] again:
INTEL 0xbddc4 link status is 00000381

(white) Waiting for link-up on net0...
(red) INTEL 0xbddc4 link status is 00000383

4) after pressing F12 and WDSNBP trying to download pxeboot.n12 no more red messages - just failing as decribed.

5) Restearting into commandline 'ifstat' has no red messages, calling 'dhcp' says:
INTEL 0xbddc4 ring 03800 is at [1f64bf00,1f64c000)
INTEL 0xbddc4 ring 02800 is at [1f64c000.1f64c100)
INTEL 0xbddc4 link status is 00000383
INTEL 0xbddc4 link status is 00000383

[chmeyer]

Okay, I tried the testing procedure: http://ipxe.org/dev/driver

1. link detection (IMO seems okay):
iPXE> ifstat
net0: xx:xx:xx:xx:xx:xx using 82547ei on PCI02:01.0 (closed)
[Link: down, TX:0 TXE:0 RX:0 RXE:0]
[Link status: Dp#own (http://ipxe.org/38086101)]
iPXE> ifopen net0
INTEL 0xbddc4 ring 03800 is at [1f64bf00,1f64c000)
INTEL 0xbddc4 ring 02800 is at [1f64c000,1f64c100)
INTEL 0xbddc4 link status is 00000383
INTEL 0xbddc4 link status is 00000383
iPXE> ifstat (with cable connected):
net0: xx:xx:xx:xx:xx:xx using 82547ei on PCI02:01.0 (open)
[Link:up, TX:0 TXE:0 RX:42 RXE:27]
[RXE: 16 x "Operation not supported (http://ipxe.org/3c086003)"]
[RXE: 9 x "The socket is not connected (http://ipxe.org/380f6001"]
[RXE: 2 x "Error 0x440e6003 (http://ipxe.org/440e6003)"]
-> disconnect cable
iPXE> INTEL 0xbddc4 link status is 00000381
ifstat
net0: xx:xx:xx:xx:xx:xx using 82547ei on PCI02:01.0 (open)
[Link:down, TX:0 TXE:0 RX:85 RXE:62]
[Link status: Down (http://ipxe.org/38086101)]
[RXE: 24 x "Operation not supported (http://ipxe.org/3c086003)"]
[RXE: 36 x "The socket is not connected (http://ipxe.org/380f6001"]
[RXE: 2 x "Error 0x440e6003 (http://ipxe.org/440e6003)"]
-> reconnect cable
iPXE> INTEL 0xbddc4 link status is 00000383
ifstat
net0: xx:xx:xx:xx:xx:xx using 82547ei on PCI02:01.0 (open)
[Link:up, TX:0 TXE:0 RX:99 RXE:73]
[RXE: 26 x "Operation not supported (http://ipxe.org/3c086003)"]
[RXE: 45 x "The socket is not connected (http://ipxe.org/380f6001"]
[RXE: 2 x "Error 0x440e6003 (http://ipxe.org/440e6003)"]

2. basic DHCP (IMO seems okay):
dhcp net0
Configuring (net0 xx:xx:xx:xx:xx:xx)... ok
iPXE> route
net0: 172.16.0.114/255.255.0.0 gw 172.16.0.1

3. close and reopen:
ifclose
INTEL 0xbddc4 MAC reset (ctrl 003c0261)
iPXE> dhcp net0
INTEL 0xbddc4 ring 03800 is at [1f64bf00,1f64c000)
INTEL 0xbddc4 ring 02800 is at [1f64c000,1f64c100)
INTEL 0xbddc4 link status is 00000383
INTEL 0xbddc4 link status is 00000383
Configuring (net0 xx:xx:xx:xx:xx:xx)... ok
iPXE> route
net0: 172.16.0.114/255.255.0.0 gw 172.16.0.1

4. large file transfer correctness:
iPXE> imgfetch tftp://172.16.0.123/512mb
tftp://172.16.0.123/512mb... No space left on device (http://ipxe.org/34012006)
iPXE> imgfetch http://172.16.0.123/512mb
http://172.16.0.123/512mb... Connection reset

Ooops. Seems that the machine has not enough RAM. I will update it later but this is not the main problem since the different machine (x64 instead of x86) with rtl8168 driver which fails, too has 8GB RAM.
Is there a problem so far? I don't see any.

Christian

[robinsmidsrod]

You'll have to check the md5sum of the downloaded file to ensure it is indeed correct. But it seems like basic link detection and stuff works. I'm not sure what status=383 means in terms of what link speed was detected (not sure where to find the datasheet), but if you've got a fancy switch you could confirm what kind of link speed it shows. I'll await a test with more memory.

[chmeyer]

Since I had other problems with this computer I tried a different one (shows the same symptom - like all iPXE tested machines, too).

This one has an intel chipset, too - but it has problems in detecting an disconnected cable with link state as Down.

Anyway:
dhcp works (IP:172.16.0.66)
iPXE> imgfetch tfpt://172.16.0.123/512mb
tftp://172.16.0.123/512mb... 38%

Thats it. Now the download hangs. Sometimes with 61%, sometimes with 9% or 18%.
Seems that download gets stuck or really slow.
1% - 3% - ... 38% took a minute or so and now (it is at 39%) 20 or 30 minutes are gone.
The longest test reached 61% after two hours or so and on the next morning it still got stuck at 61%.

TFTP Server works fine even accessing the internet.
Pinging the tftp client is fine, too:
172.16.0.123$ ping 172.16.0.66
PING 172.16.0.66 (172.16.0.66) 56(84) bytes of data.
64 bytes from 172.16.0.66: icmp_seq=1 ttl=64 time=0.096 ms
64 bytes from 172.16.0.66: icmp_seq=2 ttl=64 time=0.074 ms
64 bytes from 172.16.0.66: icmp_seq=3 ttl=64 time=0.470 ms
64 bytes from 172.16.0.66: icmp_seq=4 ttl=64 time=0.106 ms
64 bytes from 172.16.0.66: icmp_seq=5 ttl=64 time=0.098 ms
64 bytes from 172.16.0.66: icmp_seq=6 ttl=64 time=0.101 ms
64 bytes from 172.16.0.66: icmp_seq=7 ttl=64 time=0.097 ms
64 bytes from 172.16.0.66: icmp_seq=8 ttl=64 time=0.100 ms
64 bytes from 172.16.0.66: icmp_seq=9 ttl=64 time=0.106 ms
64 bytes from 172.16.0.66: icmp_seq=10 ttl=64 time=0.480 ms
64 bytes from 172.16.0.66: icmp_seq=11 ttl=64 time=0.105 ms
64 bytes from 172.16.0.66: icmp_seq=12 ttl=64 time=0.107 ms
^C
--- 172.16.0.66 ping statistics ---
12 packets transmitted, 12 received, 0% packet loss, time 10998ms
rtt min/avg/max/mdev = 0.074/0.161/0.480/0.141 ms

172.16.0.123$ netstat -n | grep 0.66
udp 0 0 172.16.0.123:43796 172.16.0.66:50361 CONNECTED

I thought it could be an issue withe the switch (Level One, showing 1000fdx for the relevant ports - cable test: ok) and replaced it with a smaller TP-Link switch: same issue.

Christian

[robinsmidsrod]

We've seen this issue with the intel driver on some chipsets. I've got it on my own HP laptop. We're working on figuring out what the exact problem is. Have patience.

[chmeyer]

Okay, thank you so long. I'll be patient.
But I think this is an additional problem.

Since the intel chipset gets stuck I tried a different (and brand new) machine with a realtek card.
Dhcp and so on works fine.
Downloading of 512mb is smooth and fast (a bit more than half a minute, didn't test md5sum or sha1sum) and resuming an interrupted link works fine, too.

But same issue here:
net0: 172.16.0.45/255.255.0.0 gw 172.16.0.1
Next server:172.16.0.2
Filename: boot\x86\wdsnbp.com
tftp://172.16.0.2/boot\x86\wdsnbp.com... ok

Downloaded WDSNBP...

Press F12 for network service boot
Architecture: x64
WDSNBP started using DHCP Referral.
Contacting Server: 172.16.0.2 (Gateway: 0.0.0.0).
Contacting Server: 172.16.0.2.
TFTP Download: boot\x64\pxeboot.n12
.

<multiple times the same two lines, very often>

TFTP Download: boot\x64\pxeboot.n12
.
TFTP Download: boot\x64\pxeboot.n12

Failed to restart TFTP.
TFTP download failedCould not boot image: Error 0x7f8d101 (http://ipxe.org/7f8d8101)
No more network devices.

iPXE> route
net0: 172.16.0.45/255.255.0.0 gw 172.16.0.1


I'm wondering what this message means: (Gateway 0.0.0.0)
and weather this is okay.

Since this onboard networkcard is only a sigle one I couldn't test loopback functions for now. - Or should I try it with a different one?
Please advise what to do or test next.

[robinsmidsrod]

It seems like your issue when using the Realtek NIC is with your WDS setup and how it is confused when run via iPXE. There are many threads on this forum that deals with how to start WDS properly (search and you shall find), although the recommended approach is to use http://ipxe.org/wimboot as explained in this howto: http://ipxe.org/howto/winpe

[chmeyer]

You are right, it's the WDS problem.

Before asking I searched ipxe.org and the forum and found many threads about wimboot.
Now I re-searched and re-read the articles and wanted to re-try it.
The only thing that does not work for me is doing something with the Windows server since I have no permissions on it. Since wimboot must be copied to the server I can't do it.
So I'm at my starting point again. How to start WDS without the use of wimboot?

After some reading I found something about WDSLINUX ( http://www.syslinux.org/wiki/index.php/WDSLINUX ). Since I can set up "my own" Server (Debian on an old an obsolete machine) it looks promising to copy the WDS files to a Debian TFTP Server and try to start it with WDSLINUX.
I will try it - but since this looks not to be too comfortable or fast it will take some time.

Thank you so long,

Christian