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

@Tom-Elliott We’ve also seen some strange interaction between green ethernet settings on some switches and these new (at the time) l219-v network adapters too. But I really don’t think that fits here since I can assume they use this switch model across their campus.

@plegrand said in intel I219-v big problem:

The only problem is this room with these network cards.

I find it suspicious why only these network cards have a problem. The problem doesn’t sound specific to FOG, but more on the dhcp layer. The next step I would say is to get a pcap from a witness computer on the same subnet and from the same switch to see what is “flying down the wire” so to speak. It would be interesting to get a pcap of a working and non-working computer in the same lab, off the same switch.

FWIW, dhcp snooping is dhcp specific to limit/restrict the impact of rogue dhcp servers. igmp snooping is related to mulicasting and publishers and subscribers.

@plegrand Is the dhcp server on the same subnet as the pxe booting computers?

Is the dhcp server running on the fog server?

Is there by chance a second dhcp server on this network?

Does this switch have dhcp snoopling enabled?

Running wireshark or using tcpdump on that network with the capture filter of port 67 or port 68 or us the display filter of bootp should show you the DORA process (Discover, Offer, Request, Ack/nak). The dhcp server might either not be responding in a timely manner or you have more than one dhcp server on your subnet. I haven’t seen this type of error before so there is something unique going on with this network.

@stevem1978 First thing I would check is to make sure secure boot is disabled.

The next thing is to make sure you have the dhcp scope enabled.

It kind of sounds like its not getting the dhcp pxe boot info from your dhcp server.
If all else fails load wireshark on a witness computer. Put that witness computer on the same subnet as the pxe booting computer. For wireshark configure a capture filter of port 67 or port 68 or use a display filter of bootp. Start wireshark then pxe boot the target computer until it fails, then stop wireshark.

You should see 4 packs (Discover, Offer, Request, Ack/nack). What will be interesting if you have more than one OFFER packet, you would typically only have one from the dhcp server. Look at the offer packet. Make sure in the dhcp header the fields next-server and boot-file to make sure they contain the expected values. Then look down in the dhcp options section at options 66 and 67. Make sure that both sets of fields have the proper values.