Posts made by george1421

@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?

@Tauric said in TFTP Timeout:

(and took less than 10 minutes lol)

Well I was taking into account for slow speeds between keyboard and chair…
Glad you have it worked out. DNSMASQ should work flawlessly in your environment.

@luisgmarinr I guess the not so obvious question would be, where did you get the win10.pxe boot loader? That is not one from FOG install.

The obvious question would be is 10.0.2.4 the IP address of your fog server?

@lmcfog OK lets start debugging this with this:

1. Schedule a capture task on the source computer, but before you hit the schedule task button tick the debug checkbox. Now schedule the capture task.
2. PXE boot the target computer, after several screens of text you need to clear with the enter key you will be dropped to the FOS Linux command line.
   (side bar: If you want a bit easier time debugging in the FOS console do this.
   a. key in ip a s and get the IP address of the network interface. It should be something valid for your dhcp address range.
   b. Give root a password, it can be any password since it will be reset when the FOS session reboots. Make it simple like hello. Use passwd root to assign the password.
   c. Now you can connect to the FOS linux session from your desktop linux computer (use ssh) or from a windows computer using putty. Connect to the IP address you found in step a. Login with user root and the password you assigned in step b.
   /sidebar)
3. Key in the following commands and post the results here.
   df -h
lsblk
cat /proc/cmdline

Also in the fog webui, in the host definition for this target computer post a snapshot of how you have this specific hardware settings configured.
Lets see how that hardware is configured.

@lmcfog Linux is a little different than windows. /dev/sda is the first physical hard drive on the computer, if you had a second physical drive that would be listed as /dev/sdb

Now the partitions are listed after the device, so /dev/sda2 is the 2nd partition on the first disk. If its only capturing /dev/sda2 then you might have the system configured to only capture a single partition, where you would normally have the configuration to capture all partitions on a single disk. Or pick in the host configuration multiple disks multiple partitions for capture if you want to clone all physical hard drives on the target computer.

Is there a specific problem or was this just a general question.

@Tauric The question about editing the pcap, I’ve seen some people mask info in the pcap thinking about privacy, but that just adds confusion, like the unprintable characters. I thought the unprintable characters were the results of hand editing the pcap file.

The advantage of going the dnsmasq route on the fog server is if the fog server isn’t running you have nothing issues pxe boot into. If you go the dnsmasq route remote the pxe boot information in your router so it doesn’t confuse things when the fog server is offline

@Tauric ok I see a whole lot of issues here. Let me ask you did you mask out any data in the pcap?

In the ethernet header (bootp protocol) the boot-file field is blank (should be ipxe.efi). The next server points to 192.168.0.254 not 0.33) Looking at the dhcp part, dhcp option 66 (should be boot server IP) is an unpritable character. DHCP option 67 is ipxe.efi but its not terminated with an end of string character 0x00, it ends the string with 0xFF. For background both bootp and dhcp options need to be set because its up to the pxe rom writer to pick if they want to boot using bootp (older protocol) or dhcp. The issue here is with your dhcp server giving your target computers bad info.

Since you are using a SOHO router, we see them not exactly place nice with pxe booting.

My recommendation is if you can’t fix your dhcp server easily then forgo using it and install dnsmasq on your fog server. It will take about 10 minutes as well as support dynamic pxe booting (bios/uefi). DNSMASQ in this configuration will not issue IP address, but only pxe boot into. https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server?_=1698421239631

@Tauric On the windows box, make sure you disable the firewall since tftp uses 2 network ports like ftp does, if you are trying to make a comparative test.

Since you seem confident with tcpdump. Lets follow this tutorial to get a pcap from the FOG server. This will show us the dhcp process as well as the tftp process at the end. It should give us a good picture of what is going on. Capture the pcap and upload it to a file share site and I will take a look at it. https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue?_=1698421239623 I’ll need the complete pcap since the screen shots don’t show the complete details and there are a many exceptions to list.