PXE boot issue
-
This post is deleted! -
@cnbgeren said in PXE boot issue:
My DNS IP address looks to be different then what is shown in the boot file. Could that cause the error?
-
@cnbgeren not sure I understand. Is the IP address of your fog server 192.168.1.4?
If you are unsure you can use the “ip addr show” command.
-
I’m not sure if this is what your looking for. Thanks again for helping a newbie out
#!ipxe
cpuid --ext 29 && set arch x86_64 || set arch i386
colour --rgb 0xff6600 2
cpair --foreground 7 --background 2 2
console --picture http://192.168.1.4/fog/service/ipxe/bg.png --left 100 --right 80
:MENU
menu
colour --rgb 0xff0000 0
cpair --foreground 0 3
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.sysinfo Client System Information (Compatibility)
choose --default fog.local --timeout 3000 target && goto ${target}
:fog.local
exit || goto MENU
:fog.memtest
kernel memdisk iso raw
initrd memtest.bin
boot || goto MENU
:fog.reginput
kernel bzImage32 root=/dev/ram0 rw ramdisk_size=127000 ip=dhcp dns=192.168.1.5 keymap= web=192.168.1.4/fog/ consoleblank=0 loglevel=4 mode=manreg
imgfetch init_32.xz
boot || goto MENU
:fog.reg
kernel bzImage32 root=/dev/ram0 rw ramdisk_size=127000 ip=dhcp dns=192.168.1.5 keymap= web=192.168.1.4/fog/ consoleblank=0 loglevel=4 mode=autoreg
imgfetch init_32.xz
boot || goto MENU
:fog.sysinfo
kernel bzImage32 root=/dev/ram0 rw ramdisk_size=127000 ip=dhcp dns=192.168.1.5 keymap= web=192.168.1.4/fog/ consoleblank=0 loglevel=4 mode=sysinfo
imgfetch init_32.xz
boot || goto MENU
autoboot -
@cnbgeren But what is the server’s IP address?
ip addr show -
I just troubleshot this error. This is because of the DHCP service not having option 66 and option 67 configured. See this image.
The inside highlighted value for option 66 should be the static IP address that you are setting your FOG server on.
Option 67 should be (most commonly) undionly.kpxe
You can also make sure that the DHCP service is started on your server, and that TFTP is enabled on your windows machine(s).
I recommend following this guide, as it helped me tons. https://wiki.fogproject.org/wiki/index.php?title=FOG_on_an_Isolated_Network
-
@cnbgeren We have seen this happening with weird DHCP setups. Please make sure you have only one DHCP server answering within your subnet! As well you might want to try out FOG trunk as we are pretty close to a new release and many things have changed since version 1.2.0! See here on how to install trunk: https://wiki.fogproject.org/wiki/index.php?title=Upgrade_to_trunk
-
192.168.1.4
-
The dns you see in the output of the file has nothing to do with the issue you’re seeing.
-
@cnbgeren Please update to the latest. I suspect you’re seeing the old tftp/no-tftp issue. At least as far as I can tell.
-
I just installed this version of fog software this weekend. would I still need to update?
-
@cnbgeren said in PXE boot issue:
I just installed this version of fog software this weekend. would I still need to update?
If you are indeed on FOG 1.2.0 stable, that official release is over 2 years old. Most of us have been on the 1.2.0 (trunk) release for about 18 months. And now with FOG 1.3.0-rc5 out the developers are pushing hard to hit the 1.3.0 stable state.
The development cycle of FOG 1.3.0 had be extended because of the new NVMe disks, ensuring solid support for Win10, gpt disks, and many (many) performance enhancements. Should you upgrade, YES. Just be aware there has been a few reports of having capture issues with the latest installer, this happens because the ftp linux user account gets out of sync with what the database states. No worries it can be easily fixed, I just wanted you to be aware that on the outside chance you might have an upgrade trouble. Again no worries, upgrade issues can be resolved pretty quickly.
-
@cnbgeren said in PXE boot issue:
I’m not sure if this is what your looking for. Thanks again for helping a newbie out
OK, you boot.php output looks good. So that part is fine. I feel we need to focus on the tftp issue that Tom mentioned.
-
ok will do thanks for your input. Do you have instructions on how to upgrade?
-
@cnbgeren This should get you going: https://wiki.fogproject.org/wiki/index.php/Upgrade_to_trunk
-
My PXE boot issue seems to be resolved with the install of the latest version of FOG . I do have a couple of questions during one of my PXE boot test the laptop required me to input the FOG server address but it did work. not sure why that would happen. With the new FOG GUI version I’m not seeing the option to upload image to the server, so is the GUI different than FOG 1.2.0 version? also do I need to syprep each image?
-
@cnbgeren said in PXE boot issue:
I do have a couple of questions during one of my PXE boot test the laptop required me to input the FOG server address but it did work. not sure why that would happen. With the new FOG GUI version I’m not seeing the option to upload image to the server, so is the GUI different than FOG 1.2.0 version? also do I need to syprep each image?
Well lets take this rapid fire questions in order.
-
During one of my PXE boot test the laptop required me to input the FOG server address but it did work. not sure why that would happen.
A: This typically happens when the dhcp server doesn’t supply the dhcp option 66 {next-server} OR you are using or have running a dhcp-proxy (or dnsmasq) setup on your network OR you have two dhcp servers responding to dhcp requests -
With the new FOG GUI version I’m not seeing the option to upload image to the server, so is the GUI different than FOG 1.2.0 version?
Why yes the gui is a bit different. The upload/download functions are there, the developers changed their names because upload/download is point of view dependent. The names have been changed to capture and deploy respectively. If you go into the target host record, you should see menus along the left of the host definition, look for basic tasks the capture and deploy are under there. -
Do I need to syprep each image?
There are those that say no you don’t, and technically if you capture an image for a specific model and redeploy that image to the same model then, no its not required (but if you follow Microsoft’s recommendation yes do sysprep always). If you have a single captured image you will deploy to any number of computers and models then yes, you must sysprep to generalize the image. In my case I always require the images to be sysprepped even if they are going to be deployed to the same hardware or not.
-