@WhyAydan memdisk is a bios only boot loader. Its possible to pxe boot lite touch image but you need the wim files. Looks like I need to take a few minutes and update the documentations. Give me a few hours to get this written. But its possible to do to allow both uefi and bios to load the lite touch image.

@tcso Surely run this by your network admins but if you use my configuration there is low risk to your network infrastructure. https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server?_=1690230679683

dnsmasq is a swiss army knife of services and if misconfigured will cause problems in your network. But using it in a proxydhcp configuration it will only provide pxe boot information only for your network. When the fog server is powered off then no pxe boot information, which you can’t pxe boot without fog anyway. So no harm no foul here. FWIW, proxydhcp is what windows wds uses to configure the target computers for pxe booting. A ProxyDHCP announcement will override anything configured in dhcp options 66 and 67.

@Jump_Ace Issues related to not getting FOS Linux (bzImage and init.xz) sent completely to the target computer is related to iPXE and or the target computer not FOG itself per se.

1. First make sure the firmware is up to date on the target computer.
2. Secondly build the latest version of iPXE and see if that fixes the networking issues with your target computer. https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe
3. If you are using the boot image ipxe.efi see if snponly.efi works any differently.

@wildcat2083 You need to ensure that there isn’t a dhcp server already running on your fog server.

ensure that dnsmasq is not
systemctl stop dnsmasq

now check to see if something is bound to the dhcp port
netstat -an | grep :67

If you see a response like 0.0.0.0:67 then there is still a dhcp server on the fog server.

You can also run this command to see if the isc-dhcp server is in memory. ps aux | grep dhcp If it returns isc-dhcp and a process ID then its still running.

My bet if you look at the log file in /var/log/syslog (or /var/log/messages) it will say that dnsmasq can’t bind to the port :67

@brakcounty On the server can you serve tftp on two interfaces. The tftp server is interface agnostic. The problem you will have is the FOG code running on the FOG server only knows about 1 network interface. So event if you pxe boot into the FOG iPXE on either interface, the ipxe menu will only point to the interface FOG considers the its imaging interface.

@tcso I think I can shed a little bit of info on you and you will be up to speed pretty quickly. That doesn’t mean it will solve your problem, you will just know why you have a problem.

Just be aware that if you want to boot a bios based computer you will need a bios based operating system. Bios and uefi are interfaces to the hardware. These are two different environment and are not directly related. So you can’t boot a bios based operating system on a uefi based computer the same way you can’t boot a uefi based os on a bios based hardware. This works the same for windows, linux, or embedded OS. Once the OS bootloader starts then the OS can be a bit more generic.

FOG as well as other network boot based imaging tools, use a bootloader that gets sent to the target computer over tftp protocol. The target computer knows what bootloader to request because of DHCP option 66 and 67. To boot a bios based computer with FOG dhcp needs to send in option 67 typically undionly.kpxe. If you want to pxe boot a uefi based computer, dhcp option 67 needs to be ipxe.efi or snponly.efi.

The problem with normal dhcp is that this dhcp option 67 is a static value. So you can only pxe boot bios or uefi based computers. Luckily both linux and windows dhcp server’s support something called target profiles. Using target profiles the dhcp server will detect the pxe booting target computer and send the proper pxe boot file name to the target computer. https://docs.fogproject.org/en/latest/kb/how-tos/bios-and-uefi-co-existence/#using-proxydhcp-dnsmasq look into the section that talks about windows 2012 servers and later on instructions to set this up.

If you have an unchangeable dhcp server and your target computers are on the same IP subnet as your FOG server you can install dnsmasq on your fog server to override dhcp options 66 and 67 with the proper values. If your target computers are on a different ip subnet and you have control of your network switches you can integrate dnsmasq pxe info to other subnets.

@engineerfranko I would start by updating iPXE. You didn’t mention the version of FOG you are using, but its still a good idea to update it if you have really new hardware.

https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe?_=1689971549331

@ERockZab Is secure boot enabled on the target computer? If yes turn it off and try again.

@spchristy said in HP 705 G4 - rEFInd Initializing....:

Last night I went the ./buildipxe.sh route assuming that it would install the most recent version (0.14.0.2).

OK you have a conflict here. The buildipxe rebuilds the iPXE boot loader (not a bad thing to do to stay current). But that has noting to do with refind. Refind is its own critter. Refind is only installed from the fog installer, and its never made current. Its only what version is release when new version of fog is created.

Just to test, see if it works, change your UEFI exit mode from refind to EXIT. EXIT is a built in function of iPXE. Where refind.efi gets called (chained) from iPXE then iPXE leaves memory.

@spchristy said in HP 705 G4 - rEFInd Initializing....:

My understanding is that v1.5.10 uses refind 0.11.0 ? I

Well it would be interesting to hear what version the developers released with FOG 1.5.10, I was thinking 0.11.4 was the released version. If you look at the sourceforge site they are already on version 0.14.0.2. I don’t know if that version fixed anything in relation to the HPs or not. I can say that version 0.11.4 was released in 2018 so it might not be aware of more modern hardware.

As for how you use fog, well done!!

@dvorak If this route doesn’t work I still have a trick up my sleeves.

Create a custom winpe image and boot that using iPXE. This/then would support both bios and uefi booting. The trick with a custom winpe image is that the executable need to be on/in the winpe image when it boots. I have instructions on this too, but lets see if we can get the dell delivered format to work.

@dvorak OK that iso image seems to be only a legacy/bios boot media. I would be interesting if you burned that to a CD, if it actually would boot. I also saw that cd.txt message and thought it was strange.

So when you run the dell downloaded tool It gives you the option to create an iso and .img file. You can look at the .img file using 7-zip. I would look to see in that .img file if there is a /EFI directory, if no then its bios only. You might be able to use memdisk to run the .img file too.

Were did you find the memdisk program, in /tftpboot? I don’t have a fog server in front of me at the moment so I can’t answer my own question.

@spchristy The refind code comes from another opensource project. You might want to try to see if a different refind kernel works differently.

https://sourceforge.net/projects/refind/files/

The last version of refind I knew was shipping with fog is 0.11.5, @developers please correct me if I’m wrong. You should try the latest and 0.11.0 was also known to be a solid version. With the issue with m.2 drives I might think the latest version would have better luck since it should be familiar with nvme drives.

The refind files are in /var/www/html/fog/service/ipxe directory on the FOG server.

---

On a slightly different topic of quick restore. There is an option in FOG configurations (I’ll have to look it up), to where it will only allow the defined image to be deployed to the target computer. With that set, you can use the deploy image menu from the FOG iPXE boot menu to quickly deploy the image to the target computer without having to schedule a job. You can do the redploy directly from the console of the target computer. If that helps streamline the restore process.

@dvorak OK I looked into this quickly. With the download from Dell you can create an iso image and a usb drive image (.img) file. You can probably use memdisk to boot this 32 bit image. Its small and DOS based (appears)

Something like

kernel memdisk
initrd diags.iso

Those files should go into /var/www/html/fog/service/ipxe directory. memdisk should already be on the fog server. Its either in the path above or in /tftpboot the iso needs to go in the same location as memdisk.

I have a tutorial on using FOG to pxe boot different operating systems: https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images

You can get an idea how to use memdisk in step 18 here: https://forums.fogproject.org/post/142041

@kjmchale I would add a step 5 of rerunning the fog 1.5.10.x installer once again after you upgrade ubuntu. The installer will fix any changes it detects between the two versions of ubuntu.

If it still fails we can debug more. Also remember that FOG web ui doesn’t like it when you change fog server’s IP address after FOG is installed. You can make adjustments to compensate but its just another step you need. to .

@Numa09 said in Stuck on "running post init scripts:

’ve check every thing and every where and can’t find config difereces between locations that work and the ones that doesn’t

If you want we can try to debug this.

1. Manually register this computer with FOG server if it is not already.
2. Schedule a capture/deploy doesn’t matter, but before you press the schedule task button tick the debug checkbox.
3. Now pxe boot the target computer from the failing location.
4. After several screens of text that you must clear with the enter key you will be dropped to the FOS Linux command prompt on the target computer.
5. Now we are going to see if you can first ping the fog server’s IP address. (This should succeed because you were able to pxe boot into FOS Linux.
6. Next lets create a directory so we can see if we can mount the fog server via NFS.
   mkdir /test
7. Now lets see if we can connect to the fog server via NFS (this command might/should show you the true error here.
   mount -o nolock,proto=tcp,intr,noatime "<fog_server_ip>:/images" /test Replace “<fog_server_ip>” with the IP address of the fog server. Don’t leave the greater than and less than symbols behind.

Lets see if you can mount that directory.
Also post the output of these commands after you try the mount.

uname -a
ip a s
df -h

On the fog server make sure you are not running any kind of firewall to block nfs traffic.

@Enigma said in Isolated Network Setup (Stuck in Start PXE over IPv4):

Hello I’ve DM the traffic cap

Ok that is looking much better I now see the DORA process (Discover, Offer, Request, Ack). BUT there is something missing. When I look at the ethernet header I see the next server being 192.168.107.2 (hopefully is your fog server). The boot file is undionly.kpxe (this is good), but what is missing is the dhcp options 66 and 67. So that is telling me you are missing something in the config file. You are so close to having this work.

Could you post your complete dhcpd.conf config file?

@Trep76470 A windows dhcp server should work just fine. Is it OK to guess that your fog server is at ip address 192.168.21.220?

The error message you first posted usually indicate a bios computer booting, but I don’t know leovo computers pxe boot process. Typically uefi computers would mention NBF.

Are the pxe booting computers, dhcp server, and FOG server on the same IP subnet? If yes then we can use tcpdump running on the FOG server to capture what is actually flowing down the wire.

Some things to check on your dhcp server.

1. Make sure it is responding to both dhcp and bootp requests. Both bits of information need to be in the dhcp OFFER packet.
2. If you have redundant dhcp servers, make sure you configure dhcp options 66 and 67 on both servers. Microsoft’s HA for dhcp does not copy over these settings.

If you can not find the solution then I have a tutorial here: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

Look at the results with wireshark, specifically the OFFER packet. Look to see what dhcp servers are responding to the offer packet. Then in the offer packet look at the ethernet header. You are interested in the next-server and boot-file fields. They need to be populated and match the dhcp options 66 and 67 under the dhcp options section. If you can not understand what you see in the pcap file, then upload it to a file share site and then either post the link here or DM me using fog chat the url and I will look at it.

@Trep76470

What device is your dhcp server? Is it your fog server or something else? Please tell me what is your dhcp server.

What values did you key into your dhcp server for dhcp options 66 and 67? DHCP option 66 must be the IP address of your FOG server, with dhcp option 67 unidonly.kpxe (since the error messages indicate you have a bios based computer). If you were trying to pxe boot a uefi based computer dhcp option 67 should be ipxe.efi.

Your error indicates you have a problem with your infrastructure not FOG (only based on the error message).

Final comment, the fog agent is not used for pxe booting, its only used for post image deployment actions.

@alexamore90

Our work consists in installing as many PCs as possible with Win 10 in the fastest possible way, in order to be able to fulfill as many orders as possible.

What does this mean? How many computers do you need to image per hour to make your rate. Fast as possible is not really a measurement in time.

If I had to isolate your clarification I would say you have a unit of measure conflict. So lets start with some theoretical maximums.

1GbE == 1Gb/s == 125MB/s == 7,5GB/min The number that is displayed during the partclone part of imaging is typically in GB per minute (on a well designed 1GbE network)
Note that 1Gb/s does not equal 1GB/s, its a little confusing but Gigabit is not the same as a GigaByte.

On a well designed network with a single unicast image, using a current (<5 year old) target computer I would expect you to see in the 6-6,5GB/min throughput. At this rate a 25GB target computer image should take about 4 minutes to deploy to a target computer (single unicast image).

At 6GB/min (or 100MB/s) you are almost at the theoretical maximum for a 1GbE link of 125MB/s). Meaning: you will saturate a 1GbE link if you try to image with more than 2 unicast images at the same time. Hint that 1GbE link to your fog server will get saturated first having the greatest impact on imaging speed.

the maximum speed is 16/17gbs (so he indicated to me while he was deploying)

I can understand this speed if this is 16GB/min. I’ve seen these speeds on a large VM Host server that has one or more 10GbE links to your core network using current target computers. If you want to go faster, use 10GbE networking.

You need to understand that the number displayed on the partclone screen is a composite number made of individual measurements. The number displayed in partclone includes the speed the FOG server can get the disk image from disk to the fog server’s network adapter, network transmission time, the amount of time it takes the target computer to receive the image and load it into memory, the target computer to expand the image in memory and then to write it to disk. Your target computer performance will have the largest impact on imaging time. If you have 2 computers that are exactly the same except one has a nvme drive for storage and one has a rotating disk drive for storage you will get two vastly different imaging rates because of the speed differences between the two storage medias.

If you want to image fast, have a fog server that has ssd or nvme storage, use a 10GbE core network with enterprise class switches, use multiple network links from your fog server to your network core in a lacp/lag configuration if you want to deploy multiple unicast images at one time, use current target computer hardware, consider looking into multicast imaging.