PXE connection Using Windows 2008 as DHCP Server

[techadmin]

Server

• FOG Version: Version 1.4.4 SVN Revision: 6077
• OS: Kubunti 14.04 KDELibs Version 4.13.3

Client

• Service Version:
• OS:

Description

First time setting up FOG and I can’t get it to work.
I have FOG running on a VM using Hyper-V.
I can see the web page dashboard and everything just fine.
The DHCP server is on a windows 2008r2.

I add this based on other web page readings

(Option Name)066 Boot Server Host Name (Vendor) Standard (Value) PXEClient (UEFI x64)
(Option Name)066 Boot Server Host Name (Vendor) Standard (Value) 192.168.83.94 (This is the Fog Server)
(Option Name)067 Boot File Name (Vendor) Standard (Value) undionly.kpxe
(Option Name)067 Boot File Name (Vendor) Standard (Value) ipxe.efi

I know TFTP works; when I go to a command prompt (tftp -I 192.168.83.94 get undionly.kpxe )
Transfer successful: 95338 bytes in 1 second(s), 95338 bytes/s

But yet when I boot a laptop (Dell Vostro 1500) to the network I get a CLIENT IP: 192.168.83.131 MASK 255.255.255.0 DHCP IP: 192.168.83.1
PXE-E55: ProxyDHCP services did not reply to request on port 4011
PXE-M0F: Exiting Broadcom PXE ROM.

What am I missing or doing wrong that it never makes it to the FOG server?

[Sebastian Roth]

@techadmin Please see if you’ve also set option 60 (DHCP Class Identifier). Remove that and you should be fine.

[techadmin]

I have 003 006 015 066 067 120 001 033 044

[george1421]

@techadmin So you are not specifically setting dhcp option 60 ? The client thinks it wants to do a dhcp proxy request (hence the port 4011).

If you can’t get it to boot and the dhcp server, fog server, and pxe booting client are on the same subnet then follow this post and upload the image to a google drive: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

Then either post the link in the forum or send either Sebastian or myself a direct IM and we will tell you what we see is wrong flying down the wire.

[techadmin]

Strange It is working now, next two question

Is the image that I am test copying from the Dell laptop image going to be the same as the CLonezilla image?
I have a few cloned images that would be nice if I could just copy them to the server with out having to rebuild the images on the test machine just to clone them to the FOG server…if so that would be a great time saver!!

Second is there a usb boot/file/option/way for a system that would boot up a device and find a USB network device?
I have some test equipment that only has USB ports and the device bios does show the option for network usb boot option but it does not seem to work very well or at all!

[george1421]

@techadmin said in PXE connection Using Windows 2008 as DHCP Server:

Strange It is working now, next two question

Is the image that I am test copying from the Dell laptop image going to be the same as the CLonezilla image?
I have a few cloned images that would be nice if I could just copy them to the server with out having to rebuild the images on the test machine just to clone them to the FOG server…if so that would be a great time saver!!

At the heart of it both clonezilla and FOG uses partclone to capture the disk images. FOG then uses a compression program to better optimize the image size on the fog server. So technically its possible to convert a clonezilla image to a FOG image, I can tell you that you will be better off by just using clonezilla to dump the image to fast hardware and then recapture it with FOG. That way you are assured to get all of the bits in the right spots and compressed properly. You will spend far less time this way than migrating, compressing, hand creating the image definitions and then testing than just let it happen using the respective tools.

Second is there a usb boot/file/option/way for a system that would boot up a device and find a USB network device?
I have some test equipment that only has USB ports and the device bios does show the option for network usb boot option but it does not seem to work very well or at all!

Well in this case there are a few options to usb boot or kickstart the process where the firmware doesn’t support the usb network adapter. The only caveat is that the Fog OS [FOS for short that captures and deploys images on the target computers] has to support the usb network adapter or you are done before you start. Before we go down this path tell use a bit more about your hardware, who makes the hardware and who/what model of usb network adapter are you trying to use.

I can tell you that you will have better luck pxe booting a UEFI based system if you use the network adapters that are supported by the hardware.

[Tom Elliott]

@george1421 technically newer versions of fog can handle the image files without compression too. It does mean renaming for partition of course. I’m just saying technically it is possible.

[techadmin]

@george1421
Well as far as the boot device goes we develop specialized hardware; this new item uses a COM Express on the board with a 250gig solid state chip a the drive. We use a USB DVD drive to load everything from windows to red hat with no problems. Once the OS is up and running the network is fine but booting to the USB network device leave a lot to be desired. I have two or three different USB network device options in the parts box.

But I would really like instructions on the recapture and compression; it looks like the first test capture across the network is a bit slow and my time to babysit this process is limited with the amount meetings I have this week…if you have the time

[george1421]

@techadmin said in PXE connection Using Windows 2008 as DHCP Server:

COM Express

OK, just so I understand. You have custom hardware that you need to install an image on. Your hardware doesn’t either have a network adapter that supports pxe, or there is no ethernet adapter in the device so you use an external usb ethernet adapter. It sounds like your custom hardware runs or can run rhel (that is good) and the network adapter IS seen in by rhel.

Since rhel works, then FOG/FOS will most likely work on your custom hardware. We have a couple of paths we can test to see what is the best path for you.

First a little background, FOG uses several technologies to providing imaging. The first technology is iPXE. iPXE is an extension of the PXE ROM that is built into most network adapters (in your case you don’t have a pxe rom compatible network adapter). In FOG’s case we use the built in pxe roms to download iPXE from the FOG server. Then we let iPXE take over for the rest of the image management process. When we get ready to capture or deploy images we instruct iPXE to download FOS (Fog Operating System that is used to capture and deploy images on target computers). FOS does all of the heavy work of imaging the target computer.

So the best choice if you don’t have a PXE compatible network is to see if we can load iPXE from a usb flash drive. Once iPXE is loaded it will contact the FOG server and normal imaging is possible. We have found that iPXE is not compatible with some network adapters. So for this case we can boot right into FOS, via a GRUB usb boot stick. You will loose some features by booting directly into FOS, but if you goal is to capture and deploy then we can go this path.

For the next steps I want you to build a FOS USB boot drive according to these instructions: https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image/4 To save you some time I’ll DM you a link to a boot image I created just recently. Having that image will take you to step 7 in the instructions. You can use rufus (in windows) or dd (in linux) to write the image to the flash drive. The only requirement is the usb flash drive must be 512MB in size or larger.

Once you have the usb flash drive (don’t forget to update the grub.conf file to point to your local fog server) I want you to test option 7 if your custom hardware is bios based, and option 8 if its uefi based. That should jumpstart you into iPXE. I want to know does that jumpstart option display the FOG iPXE menu. If yes then we can do a few other things. If no, then we need to understand what happened. We can then try to register the computer using FOS (option 2 or option 3). That route should work. Just a note before you attempt option 1 you MUST first schedule a capture or deploy task on the FOG server then call option 1.

I know I gave you a lot of information here. Lets first start by creating the usb boot drive from the link I will send you.

[techadmin]

Starting logging: ok
Populating /dev using udev: udevd[2795]: error creating epoll fd: function not implemented
done
Initializing random number generator… done
Starting eth0 interface and waiting for the link to come up
udhcp: starting, v1.26.2
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
Either DHCP failed or we were unable to access 192.168.83.94/for//index.php for connection
No DHCP response on interface etho, skipping it.
Failed to get an IP via DHCP! Tried on interfaces(s): eth0
Please chaeck your network setup and try again!

Ok my first action: I updated the update the grub.conf first line to point to the FOG server 192.168.83.94
Don’t know if I need to change anything else?
I see that it is showing for eth0 a MAC of : 00:00:00:00:00:00 | 30:64:19:48:91
Yet that is not the MAC that is built on our board and it is not the MAC of the USB network dongle, we only have these two items (so where is it getting that MAC from?)
Option 7 error: loading the kernel
error: invalid magic number
booting iPXE…
Press any key to continue…

Option 8 error: chain loading the kernel.
error: cannot load image.
booting ipxe-efi…
Press any key to continue…

[george1421]

@techadmin I see we have a lot of details here. Can you pick option 6 which should be debug. I’m hoping that debug will drop you to a linux command prompt after a few screens of commands. Once we are at the linux command prompt we can discover what linux knows about the hardware.

Since are dealing with a USB ethernet adapter we may need to add a kernel parameter to the grub file to tell its using a usb ethernet adapter. But try the debug menu option first and see if you can get to a linux command prompt. Once there key in the following commands.
ip addr show
ip link show
lspci -nn | grep net

[george1421]

@george1421 now don’t do this yet, I’d like to see if the debug menu gives us what we need. But if not the next steps are to add the kernel parameter has_usb_nic=1 to the kernel invocation line like this.

Original menu

menuentry "6. FOG Debug Kernel" {
 echo loading the kernel
 linux  $myimage loglevel=7 init=/sbin/init root=/dev/ram0 rw ramdisk_size=127000 keymap= boottype=usb consoleblank=0 rootfstype=ext4 isdebug=yes
 echo loading the virtual hard drive
 initrd $myinits
 echo booting kernel...
}

to this

menuentry "6. FOG Debug Kernel" {
 echo loading the kernel
 linux  $myimage loglevel=7 init=/sbin/init root=/dev/ram0 rw ramdisk_size=127000 keymap= boottype=usb consoleblank=0 rootfstype=ext4 isdebug=yes has_usb_nic=1
 echo loading the virtual hard drive
 initrd $myinits
 echo booting kernel...
}

Note the new kernel parameter has_usb_nic=1 after the isdebug=yes

[techadmin]

@george1421 any chance on an email address so I can send a few picture of the screen shots so I don’t have to type all of this out?

[george1421]

@techadmin You can post them here in the forums, or if you want to keep them private, upload them to a google drive and share the link with me via DM.

[techadmin]

@george1421 Ok I don’t see a area to up load them?

[george1421]

@techadmin When you are in the editor, you should be able to just drag the picture into the compose box. and it will upload it.

[techadmin]

@george1421 

[george1421]

@techadmin Excellent.

Lets identify what device is 00:30:64:19:48:91 Do you know what device that mac address is associated with? ( do know the answer, I just need to confirm it )

[techadmin]

@george1421 No idea it does not match anything we have on the board or the USB dongle

[george1421]

@techadmin Interesting, the mystery deepens. I can see in the output of the lspci command that there is an Intel l219-lm onboard that embedded controller.