Dell XPS 8700 PXE boot error
-
You should see more than just those few lines.
Can you test for me with a different machine an let me know if it sees the fog menu?
What provides your DHCP/Where did you make the changes to provide your pxeboot file information?
WARNING TO USERS: My comments are written completely devoid of emotion, do not mistake my concise to the point manner as a personal insult or attack.
-
@Jaymes-Driver
Windows server 2012 R2 is providing me with DHCP. Scope option 67 is providing me the bootfile name. Is that what you mean by " where did you make the changes to provide your pxeboot file information?"I see all a lot more lines below is everything i see.
#!ipxe
set fog-ip ip.of.fog.server
set fog-webroot fog
set boot-url http://${fog-ip}/${fog-webroot}
cpuid --ext 29 && set arch x86_64 || set arch i386
goto get_console
:console_set
colour --rgb 0x00567a 1 ||
colour --rgb 0x00567a 2 ||
colour --rgb 0x00567a 4 ||
cpair --foreground 7 --background 2 2 ||
goto MENU
:alt_console
cpair --background 0 1 ||
cpair --background 1 2 ||
goto MENU
:get_console
console --picture http://ip.of.fog.server/fog/service/ipxe/bg.png --left 100 --right 80 && goto console_set || goto alt_console
:MENU
menu
colour --rgb 0xff0000 0 ||
cpair --foreground 1 1 ||
cpair --foreground 0 3 ||
cpair --foreground 4 4 ||
item --gap Host is NOT registered!
item --gap – -------------------------------------
item fog.local Boot from hard disk
item fog.memtest Run Memtest86+
item fog.reginput Perform Full Host Registration and Inventory
item fog.reg Quick Registration and Inventory
item fog.deployimage Deploy Image
item fog.multijoin Join Multicast Session
item fog.sysinfo Client System Information (Compatibility)
choose --default fog.local --timeout 3000 target && goto ${target}
:fog.local
chain -ar ${boot-url}/service/ipxe/grub.exe --config-file=“rootnoverify (hd0);chainloader +1” || goto MENU
kernel bzImage32 loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=127000 web=ip.of.fog.server/fog/ consoleblank=0 rootfstype=ext4 loglevel=4
imgfetch init_32.xz
boot || goto MENU
:fog.memtest
kernel memdisk iso raw
initrd memtest.bin
boot || goto MENU
kernel bzImage32 loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=127000 web=ip.of.fog.server/fog/ consoleblank=0 rootfstype=ext4 loglevel=4
imgfetch init_32.xz
boot || goto MENU
:fog.reginput
kernel bzImage32 loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=127000 web=ip.of.fog.server/fog/ consoleblank=0 rootfstype=ext4 loglevel=4 mode=manreg
imgfetch init_32.xz
boot || goto MENU
:fog.reg
kernel bzImage32 loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=127000 web=ip.of.fog.server/fog/ consoleblank=0 rootfstype=ext4 loglevel=4 mode=autoreg
imgfetch init_32.xz
boot || goto MENU
:fog.deployimage
login
params
param mac0 ${net0/mac}
param arch ${arch}
param username ${username}
param password ${password}
param qihost 1
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
:fog.multijoin
login
params
param mac0 ${net0/mac}
param arch ${arch}
param username ${username}
param password ${password}
param sessionJoin 1
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
:fog.sysinfo
kernel bzImage32 loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=127000 web=ip.of.fog.server/fog/ consoleblank=0 rootfstype=ext4 loglevel=4 mode=sysinfo
imgfetch init_32.xz
boot || goto MENU
:bootme
chain -ar http://ip.of.fog.server/fog/service/ipxe/boot.php##params ||
goto MENU
autoboot -
I agree with Jaymes, there should be more data on the boot menu.
the full url probably should include a fake mac address, somehting like
http://<fog_server_ip>/fog/service/ipxe/boot.php?mac=00:00:00:00:00:00After calling that url, and getting the short menu, please inspect the end of the apache error log. You should be able to view it from the fog web gui at FOG Configuration->Log Viewer Then select apache error log (error_log). Lets see if php has thrown an error there. That log will help the devs understand what happened. -
@george1421 Well my previous post is a bit foolish now that you posted the complete context.
Will you please provide a screen shot of the boot screen with the pxe error code. PXE-M0F, means that the PXE kernel basically gave up cause there was nothing to do.
-
@cfsalyer Yes, that was precisely what I was asking. and thank you for providing the full file. It appears that the menu file is being displayed… so its a matter of determining why the client is not completing it’s tasks.
Can you please provide a screen shot like George has asked?
Usually the pictures can provide us with a bit more information so that we can determine the cause of the issue.
I appreciate you taking the time to provide the information we have requested, it greatly helps in finding the resolution.
-
-
@cfsalyer Do you have dnsmasq running on your network? OR do you have/had another imaging solution on your network?
The error might indicate you have a response from 2 dhcp servers or a dhcp server and a dhcpproxy server. We may need to grab a pcap of the dhcp boot process to know for sure if you don’t know.
-
Why are we hiding the IP Address?
I can understand the MAC (though ultimately this doesn’t matter either).
See the IP information and dhcp server, unless you’re issuing DHCP from the public ip ranges, should not matter and will help us help you in figuring out what is happening.
Is the Client IP and DHCP IP address in the same range as your FOG Server subnet?
-
@george1421 I do have a WDS/MDT server on the same test network. However I have the services disabled. Is their more I need to do? Can you even have both on the same network?
-
@cfsalyer I might suspect that you have a dhcpproxy service running still on your WDS server. We can point to the exact device if you are willing to setup tcpdump on your fog server (assuming your fog server and dhcp server and target server are on the same subnet).
-
@Tom-Elliott
Sorry for making that difficult, but yes the client IP, DHCP, and FOG server are on the same subnet -
@cfsalyer So then if you can’t find the service running on WDS.
Please do the following
- Install the tcpdump program on your FOG server
- prep the target computer to pxe boot, but don’t start it just yet.
- Key this into your fog server:
sudo tcpdump -w output.pcap port 67 or port 68 or port 69 or port 4011 - PXE boot the target computer until the error is reached
- Press Ctrl-C on the tcpdump program
- Use WinSCP to copy it to your computer
- Inspect with wireshark or post it here for review.
The filter command we use will ONLY look for dhcp, tftp, and dhcpProxy data packets.
What I would look for is you will see a dhcp discover packet from the target computer, then a response from one or more dhcp servers. (you should only have one from your main dhcp server on a normal network). But that pcap will tell us the truth of what is flying down the wire.
-
@george1421 Ok I just got much further removing option 60 from my DHCP server. I now get partclone and everything seems to be working now.
-
@cfsalyer Hey, that’s good news!
Please let us know if you have other issues.
I am glad to hear that removing option 60 solved your issues. Was option 60 something that was required by WDS?
Sometimes using an IP Helper address at the switch can help to resolve these issues too, but it appears like your clients are now getting the proper boot file.
-
@Jaymes-Driver Yeah I’m going to segment the network and go a different route when i go into production. I just had to prove FOG server would work for our environment. And yes option 60 is being used for WDS. Thank you for all your help and @george1421 . I never noticed the port 4011 error until i captured the picture and then that lead me to checking server scope options.
-
@cfsalyer You have to consider the error is only one part of the problem. Having the context of the error (what’s around it) will help us understand the error better and maybe what caused it.
I’m glad you have it worked out. If you have any additional issues transitioning from WDS to FOG post back in a new thread.
FWIW: In my environment we use MDT to create our golden/master/reference image and FOG to capture and deploy it across our campus of 12 different models of devices. You can’t beat FOG for time to deploy with almost any other platform.
-
@george1421 said in Dell XPS 8700 PXE boot error:
FWIW: In my environment we use MDT to create our golden/master/reference image and FOG to capture and deploy it across our campus of 12 different models of devices. You can’t beat FOG for time to deploy with almost any other platform.
Boy do I second that notion! FOG beats the pants off of WDS in my corporation. I also particularly enjoy the fact that after I deploy my image… it works. I don’t have to spend any time troubleshooting why something wasn’t “installed” on my image due to the windows imaging process <.<
Sure sometimes I have an issue, but I just push the image again and do my happy dance (3 minutes later the image is done and I spent very little time troubleshooting it).
They keep trying to shove SCCM down my throat. I will use the SCCM, I just won’t use it for imaging. (If it’s not broke don’t fix it!!!)
-
@Jaymes-Driver Well Yeah FOG is going to be my go to for OS X and Ubuntu builds. But I will have to stick with MDT and WDS deployment seeing we have a ton of different configuration I push out.
