@sgilbe I’m not seeing anything that jumps out at me as being wrong. It surely seems to fail at starting the kernel.

Are you sure you don’t have secure boot enabled on this system?

@Dietrich07 The link you posted is from an old install so there may be changes to the application in the last 7 years.

Looking at your ipxe menu parameters and comparing it against the wiki I see some differences.

kernel http://${fog-ip}/pmagic/bzImage64
initrd http://${fog-ip}/pmagic/initrd.img
initrd http://${fog-ip}/pmagic/files.cgz
initrd http://${fog-ip}/pmagic/fu.img
initrd http://${fog-ip}/pmagic/m64.img
imgargs bzImage64 boot=live ip=dhcp edd=on noapic load_ramdisk=1 prompt_ramdisk=0 rw vga=normal sleep=0 loglevel=0 keymap=us splash quiet - || read void
boot 

FWIW you are missing the imgargs and the kernel name is different. You DO need the imagargs line but I would also change the imgargs line to include the initrd file (what the kernel appears to be complaining about)

Lets see how well this parameter block works.

kernel http://${fog-ip}/pmagic/pmagic/bzImage
initrd http://${fog-ip}/pmagic/pmagic/initrd.img
imgfetch http://${fog-ip}/pmagic/pmagic/fu.img
imgfetch http://${fog-ip}/pmagic/pmagic/m.img
imgfetch http://${fog-ip}/pmagic/pmagic/files.cgz
imgargs bzImage64 initrd=initrd.img boot=live ip=dhcp edd=on noapic load_ramdisk=1 prompt_ramdisk=0 rw vga=normal sleep=0 loglevel=0 keymap=us splash quiet
boot

NOTE: imgfetch and initrd perform the same function, using it as I’ve done above makes the intent a bit easier to understand. The function is exactly the same though.

@r00s7a This is most likely an issue with your network infrastructure and not fog. The DHCP offers come from your primary dhcp server. If that DHCP server is not FOG Server then its not something you can solve on the fog server.

Where we have seen sometimes they pxe boot and sometimes not is if you have two dhcp servers on your network. Possibly in a primary / secondary configuration. Confirm that all dhcp servers have dhcp options 66 and 67 set because these settings are not replicated between windows dhcp servers.

@El-Fogito said in PXE Boot issue on second FOG-Server:

VLAN 10.20.88.0 and 10.20.82.0 (on which I configured port 66/67 from DHCP to server 10.20.10.38) finds NOTHING.

The first question is that is 10.20.88.0 fully routable to 10.20.10.38? i.e. can you ping 10.20.10.38 from the 10.20.88.0 subnet?

Do have any firewalls or screening routers that might stop udp port 67 and 68 from reaching 10.20.10.38? You can test this by using a computer on the remote subnet and trying to tftp one of the boot files from the fog server.

You are saying that you can change dhcp option 66 from 10.10.10.38 to 10.20.10.38 and the remote system can’t pxe boot. This eliminates dhcp server and possibly any router dhcp helper/relay settings from the problem.

If you have a witness computer (third computer on the remote subnet running wireshark) on the 10.20.88.0 you might setup a pcap to see what the remote pxe booting computers are being told what to load. This would ensure that the remote pxe booting computer was being told the proper values. If true then you can eliminate dhcp infrastructure issues and then deal with IP routing as the problem.

Is there any WAN links between 10.20.10.38 and 10.20.88.0/24 subnets? I have see WAN links that have a smaller MTU than the tftp block size cause a problem. I think the default block size for tftp is 1468 so if the link MTU is below that value it will case the tftp packet to fragment and then fail to download. From your error message it doesn’t sound like this is the issue, but its always good to ask.

@jleonv There are a couple of things here.

1. I would build a golden image outside of AD. You should be able to install almost all of the software as a standalone machine. As soon as you attach the golden image to AD, it will become tattooed with AD stuff. Its best to do that post deployment either by using fog or a unatted.xml script.
2. Build your golden image on a VM and use snapshots to back out changes if they mess up the golden image. You will thank me later.
3. Use the windows lite touch method of windows deployment and use an unattend.xml file to answer all of the common OOBE questions.
4. Use Microsoft MDT to build your golden image.

FOG is a block level imaging tool. It moves disk blocks from here to there very quickly. The down side is that FOG is not very dynamic when it comes to install time decisions.

MDT is a file level imaging tool. The advantage is install time changes can be made on the target computer, the down side is that it is slower to image than FOG.

@divyesh-hash Well that is strange there is no disk controller listed. Its not disabled in the bios?

I surely think we need to review that log file its either /var/log/syslog or /var/log/messages I can’t remember which. There has to be something in there that says an error about loading the disk subsystem.

@divyesh-hash OK lets go about this a bit different then.

At the fos linux command prompt key in ip a s and get the IP address of the target computer running FOS Linux

Now give root a password with the following command passwd make it something simple (like hello) because the password will reset on next reboot.

Now that you have both the IP address and root’s password using putty or ssh. Now you can copy and paste text from the screen.

now key in lspci -knn and copy the entire output and paste it here. There will be a lot of text but it will give us an idea what hardware is installed and the kernel driver responsible for it.

Also let check the log file to see if any firmware required notices are published

grep -i firm /var/log/syslog

@gaemover9 said in Deploy and capture images remotely?:

how would it be mobile if you still need to access the DHCP server to set option 66/67

Actually what I was thinking but did not communicate the intent, is to have dnsmasq configured in a proxy dhcp mode, where it would only provide pxe boot info and the main dhcp server would remain untouched. The advantage here is that no fog server == no pxe boot info.

The other thing I didn’t mention when we are talking about a mobile fog server is that FOG doesn’t like to have its IP address changed after FOG is installed. One of the mods created a script where it reconfigures FOG based on the current IP address of the FOG server. That way you can drop in a mobile deployment server, it picks up a dhcp address and then the script runs to reconfigure fog and dnsmasq to use the newly acquired dhcp address. Its not a flawless configuration but it does work.

@frobishant32 There is a couple of things going on here.

Your dnsmasq configuration is only setup for bios based computers. Look at this tutorial here to see how to configure dnsmasq for proxy dhcp. Understand this is not what you need, but look at the section with the pxe-service entries for the uefi settings : https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server?_=1699482367667

The second issue you have is that when iPXE boots it once again does a dhcp query to find the IP address of the “what it assumes” is the fog server. So what ever dhcp has for options 66 and 67 will be used to find the fog server. This next part is a little complicated but let me explain. When iPXE boots it runs an internal script that the fog developers embedded in the FOG version of iPXE. The script is pretty much here: https://github.com/FOGProject/fogproject/blob/master/src/ipxe/src/ipxescript

#!ipxe
isset ${net0/mac} && ifopen net0 && dhcp net0 || goto dhcpnet1
echo Received DHCP answer on interface net0 && goto proxycheck

:dhcpnet1
isset ${net1/mac} && ifopen net1 && dhcp net1 || goto dhcpnet2
echo Received DHCP answer on interface net1 && goto proxycheck

:dhcpnet2
isset ${net2/mac} && ifopen net2 && dhcp net2 || goto dhcpall
echo Received DHCP answer on interface net2 && goto proxycheck

:dhcpall
dhcp && goto proxycheck || goto dhcperror

:dhcperror
prompt --key s --timeout 10000 DHCP failed, hit 's' for the iPXE shell; reboot in 10 seconds && shell || reboot

:proxycheck
isset ${proxydhcp/next-server} && set next-server ${proxydhcp/next-server} || goto nextservercheck

:nextservercheck
isset ${next-server} && goto netboot || goto setserv

:setserv
echo -n Please enter tftp server: && read next-server && goto netboot || goto setserv

:chainloadfailed
prompt --key s --timeout 10000 Chainloading failed, hit 's' for the iPXE shell; reboot in 10 seconds && shell || reboot

:netboot
chain tftp://${next-server}/default.ipxe || goto chainloadfailed

As I said this script looks to what dhcp settings are and then uses that to chain to load default.ipxe.

So you will need to adjust this script and rebuild ipxe if you want to change the behavior of ipxe as it boots from fog. Maybe something like this edit

#!ipxe
isset ${net0/mac} && ifopen net0 && dhcp net0 || goto dhcpnet1
echo Received DHCP answer on interface net0 && goto proxycheck

:dhcpnet1
isset ${net1/mac} && ifopen net1 && dhcp net1 || goto dhcpnet2
echo Received DHCP answer on interface net1 && goto proxycheck

:dhcpnet2
isset ${net2/mac} && ifopen net2 && dhcp net2 || goto dhcpall
echo Received DHCP answer on interface net2 && goto proxycheck

:dhcpall
dhcp && goto proxycheck || goto dhcperror

:dhcperror
prompt --key s --timeout 10000 DHCP failed, hit 's' for the iPXE shell; reboot in 10 seconds && shell || reboot

:proxycheck
isset ${proxydhcp/next-server} && set next-server ${proxydhcp/next-server} || goto nextservercheck

:nextservercheck
isset ${next-server} && goto netboot || goto setserv

:setserv
echo -n Please enter tftp server: && read next-server && goto netboot || goto setserv

:chainloadfailed
prompt --key s --timeout 10000 Chainloading failed, hit 's' for the iPXE shell; reboot in 10 seconds && shell || reboot

:netboot
chain tftp://192.168.21.82/default.ipxe || goto chainloadfailed

That chain update will then ignore what dhcp is telling ipxe and it will load always from the 21.82 address.

Here is a tutorial on rebuilding ipxe. https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe

I’m pretty sure you can get to what you need with the above info. I would try the dnsmasq settings first before going down the ipxe edit route.

@gaemover9 Yes and yes. In my case to avoid burning out the SD card, I put a usb3 to sata adapter with the PI and then used a small SSD drive to hold the images. So it was raspbian, create the ./images directory, mount the flash drive over /images, then install FOG. An older laptop would give better utility, but a RPI will work for < 10 workstation site.

Once FOG was installed then you would install dnsmasq to provide pxe boot information for the remote site. This way when the fog server is powered off, no pxe boot info is sent to the site. You might do this with a mobile FOG deployment server that would be shipped from site to site so you don’t need to configure dhcp with pxe boot info. Many SoHo routers get this process wrong.

@lukebarone Do you have time to try to debug this? If yes. Schedule another capture/deploy (doesn’t matter), but before you hit the schedule task button, tick the debug checkbox. Now pxe boot the target computer. After several screens of text you will be dropped to the FOS linux command prompt.

At the FOS linux command prompt, key in

lspci -nn | grep -i sata
lspci -nn | grep -i raid

Lets see what that returns. My bet is that dell still has the settings in there for raid-on it might have just renamed them.

@gaemover9 said in Deploy and capture images remotely?:

Some of these locations don’t have a server or a router we have access to do deploy option 66/67. IT appears we have to PXE boot which wont work across an internet…

Fog may not be the right tool for you then. When fog was created it used internal only protocols that are not secure enough to run across the internet natively.

You can pxe boot into fog over a vpn connection but typically the image transfer of your golden image would flood out the vpn connection. Consider that your golden image is probably 25GB in size and trying to move that over a remote connection may take a while.

Now some of these location that don’t have servers or a router. How many computers that would need to be imaged are at this location? A fog mobile deployment server could be a circa 2018 dual core laptop. A fog server doesn’t require a high performance server. I’ve used a raspberry pi 4 as a mobile deployment server for a < 5 target computer environment. At today’s prices for a RPI its cheaper to use an old laptop, but a RPI will work.

@luisgmarinr What you are telling me and what I see on the screen is not the same. Some of my confusion is that I don’t use virtual box so it may be something unique to VB.

You tell me the FOG server is at 10.0.2.15, but from your initial screen shot that is the IP address being given to the pxe booting computer.

The firmware is being told the next server (pxe boot server) is at 10.0.2.4. The next server field should point to the fog server IP address. Its also being told to boot win.pxe and that is not a FOG boot loader.

So lets start to debug this by identifying what device is 10.0.2.4.

Also what device is the dhcp server for your network? That device appears to be giving out bad information.

@Manny-Both-Hanz To explain what is going on here is that the fog iPXE menu is created by the boot loader ipxe.efi (uefi) or undionly.kpxe (bios).

Any time you make a menu selection the ipxe boot loader loads FOS linux (you should see bzImage and init.xz being transferred to the target computer). What you are seeing here is that FOS linux is having an issue getting an IP address.

Where is is failing here is if your network switch is using standard spanning tree protocol and not one of the fast spanning tree protocols (port-fast, rstp, mstp, fast-STP). A quick test to see if its a spanning tree issue, is to put a cheap unmanaged switches between the building switch and the pxe booting computer. I talking cheap like those $20 5 port mono price switches. These switches typically don’t support spanning tree at all. See if that solves your issue.

If that doesn’t mask the problem then lets have you update the FOS Linux kernel. That is done from the Web UI under FOG Configuration -> Kernel update. Get the latest kernel 6.2.<something> that will give you support for the latest network and disk drivers.

@professorb24 Just to be clear you can boot from a usb stick into fog, but you can not transfer fog images to a usb stick for an off-line deployment. You should use clonezilla for that. FOG is only a network based deployment tool. Clonezilla and FOG use a similar data capture engine, but the file formats are not compatible.

We do have the ability to launch the FOS Linux engine (the OS that captures and deploys server based images) from a USB stick if that will help your situation, but a FOG server is still required in the deployment process.

@Towndrunk For imaging you need to disable secure boot feature in the firmware/bios. Once imaged you can reenable secure boot if needed.

@professorb24 The solution could be quick and easy or a bit harder but still possible based on why you need to boot via USB.

@lmcfog Ok you found an issue with linux, intel has not released the drivers for the raid controller to linux even after this many years. Switching to ahci mode is the solution. The risk is if you setup an intel raid using the built in controller linux (not specifically related to FOG) can’t see the disks behind the raid controller. There is no harm in performance or operational if you only have one drive and don’t need a raid configuration.

@lmcfog Ok so tell me a bit more about this hardware. It has a spinning HDD that is being detected. But is that a sata attached SSD or is it a NVMe drive?

Also what version of FOG are you using, as well as the FOS linux from the debug mode on the target computer uname -a

Is this a bios or uefi system?

@lmcfog So just to be clear this is the SOURCE computer and not the destination or cloned computer?