@DPR-SIO Running the FOS Install script on a NAS probably will not work since the install script assumes your “NAS” is a linux computer.

Its possible to setup a NAS as a storage node as long as it has NFS and ftp capabilities. The NFS share directory and the FTP user directories need to point to the same location. In the storage node definition there is an FTP path field, that needs contain the actual path on the NAS where the files are located. The qnap and synology instructions do a good job of showing how things need to be configured. You need to make things configured in the correct location on the NAS, confirm that the ftp user can access both /images/dev and /images directory to move files.

@DPR-SIO First let me say that the FOG Project devs don’t support this configuration. They only support using FOG servers or FOG Storage nodes.

With that said you could have success using an external NAS device if the NAS can meet certain requirement. FOG uses NFS and then ftp to capture images. NFS is used to capture the image to /images/dev/<mac_address> folder and then uses FTP to move it from the read/write area to the read only area in /images. The error indicates that its failing on the FTP login and move commands.

Looking in the wiki and tutorial I see some article that might help.

https://wiki.fogproject.org/wiki/index.php?title=NAS_Storage_Node

https://forums.fogproject.org/topic/10973/add-a-nas-qnap-ts-231-as-a-storage-node-fog-v1-4

and the tutorial I wrote for synology nas (this one for you is more about the concepts and not the commands)

https://forums.fogproject.org/topic/9430/synology-nas-as-fog-storage-node

@Flyer You can do quite a lot with post install scripts to decode the hardware so if you need to make hardware specific changes in your script you can.

I have a few tutorials on this. In this example you can get the model number and system manufacturer of the computer the script is running on using dmidecode.
https://forums.fogproject.org/post/88293

Also here is a post install script for installing the proper windows drivers onto the target hardware: https://forums.fogproject.org/topic/8889/fog-post-install-script-for-win-driver-injection The point of this script isn’t to show you how to inject drivers, but the method to extract data to make your post install script more flexible.

This post here is just random snippets of code that look at IP address and how to get fog run time variables into your post install script. https://forums.fogproject.org/post/69725

While I agree that having a post install script per host might be a good idea, I think it would only be a very edge case and be more of a management nightmare if you had a campus with 1000s of hosts.

@Koffinny said in Issue booting PXE on clients:

It is a Tp-Link router

I have seen many soho routers not support pxe booting or have the options to set dhcp option 66 and 67. If your pxe booting computers and your FOG server is on the same subnet its probably the best solution (assuming your router doesn’t support pxe booting natively) to install DNSMASQ on the fog server to provide pxe booting info (only). DNSMASQ is kind of a swiss army knife of a tool, but supporting proxydhcp is one bit that we will use. It takes about 10 minutes to install and configure on your fog server and probably less time you’ve spent with yoru current router. Realize that dnsmasq will only give you the pxe boot information your main dhcp server will provide everything else. No changes are needed on your network unless you want to pxe boot across a router. Then there is one simple setting you need there.

I have a tutorial on how to install dnsmasq on your fog server here: https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server?_=1681250221198

@kamburta The basic steps are here: https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images

You will just need to get the right kernel parameters for booting ubuntu live. If you have a live boot CD you can get the parameters from either grub.cfg for the isolinux.cfg files. The steps for live boot are very close to the steps to boot the installer its just the kernel parameters that need to be adjusted.

@rhromyko This is probably related to the latest versions of Ubuntu and Debian, I’m a bit surprised that 22.04 has the issue though. I’m suspecting that FOS Linux doesn’t have the 1.47 version installed. Is the error happening during imaging or is it when you live boot Ubuntu?

As Tom mentioned the term “PXE OS” could be confusing the issue. Let us know exactly where in the process you are getting this error.

@tahitiju said in Multicast is very slow:

I try to deploy an image to some PCs but performance is very low (2MB/min) using multicast.
For the purpose of the test, FOG server (1Gb NIC), clients (1Gb NIC) and dhcp are connected together using a Linksys Switch ( 16 x 1Gb ports / unmanaged) .
Using unicast, performance seems normal (~1,5GB/min deploying 14 PCs).

A few things jump out at me with this. Multicasting can be very taxing on inexpensive network hardware. When you are getting 2MB/min how many systems are you multicasting to? Do you get the same performance when multcasting to 1 or 2 machines?

Multicast imaging moves at the speed of the slowest computer in the mcast group.

1,5GB/min is on the slow end of the scale. On a well managed 1GbE network, imaging to current hardware, I would expect about 6GB/min. If put your fog server on 10GbE network I would expect about 13GB/min. I’m only pointing it out that there might be something in your network infrastructure that is slowing things down.

A 1GbE network link will saturate with 3 simultaneous unicast deployments.

The FOG performance numbers displayed on the target computer are a composite number of how fast the fog server can pull the image off the disk, send it over the next, the client receiving the image, expanding it in memory and then writing it to disk. Any one component that is slow will impact the overall performance score.

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

@dvorak Its not e2fsck in your fog server host OS, its in the FOS Linux OS that gets copied to the target computer during pxe booting. That needs to be updated.

@Alan-Lim Lets run through this tutorial and compare it to your settings: https://forums.fogproject.org/topic/9430/synology-nas-as-fog-storage-node

@User_wds First let me say I have no experience with windows 11, but it should be similar in disk structure to windows 10.

So I would have to ask did you prepare the system for cloning?
Did you sysprep the image before capture?
Did you properly shut down the OS for cloning?
Is this the first computer you are cloning?

@DBCountMan Now that you know the root of the problem, you can/could bring everything back together by syncing the certificates and ipxe boot files from your primary FOG server to your secondary FOG server. The issue as you found is two different certificates on your campus.

@elchapulin Yes it does. (saying these instructions from memory) in the dhcp server there is a section under advanced for netbooting (its not called pxe booting). There was 4 or 5 fields. One for bios, that takes the value of: undionly.kpxe, one for 64 bit uefi: ipxe.efi, and one for 32 bit efi: i386/ipxe.efi and maybe one for ARM processors. There should be a field for next server or boot server IP. That will be the IP address of your fog server.

I seem to recall a section on tftp, that section is not used for net booting.

@cwentwo said in Lenovo E15 Gen3 PXE Boot:

it goes to the black screen and displays Start PXE over IPV4, then flashes some text and goes back to the boot options

Turn off secure boot.

@Roger-Saffle Using a web browser navigate to http:<fog_server_ip>/fog/service/ipxe/boot.php?mac=00:00:00:00:00:00 that is the text behind the ipxe menu. There must be something wrong with the menu or short name for the custom menu.

@boros Ok there are two things here.

On installing fog there are 3 phases. 1. Start the FOG installer from the linux CLI and answer the preinstall questions. 2. GO to the Web UI and execute the action there to create/update the database. 3. Return back to the fog server console CLI and complete the installation. If you miss/skip part 3 you won’t have the required services installed. The /tftpboot directory will be blank. There won’t be any FOS linux os (bzImage and init.xz) in /var/www/html/fog/service/ipxe directory. The quick fix for this is to simply rerun the installer and completing all three steps.

The second one you have to remember is that WDS uses a netboot service, which is akin to proxydhcp. ProxyDHCP overrides the dhcp settings provided by the dhcp server for netbooting (options 66 and 67). A quick check is to have a witness computer on the same subnet as the pxe booting computer. Run wireshark on that witness computer using the capture filter of port 67 or port 68 or use display filter of bootp. Look to see if you are getting multiple OFFER packets. If only one look into the one OFFER packet to see if dhcp option 60 is present. That signals a proxydhcp packet. If it exists that tells the client to contact the dhcp server after the dhcp exchange for pxe boot information on port 4011.

@boros

I want to transfer the “Gold” Images from the server in the other site. Can I just copy and paste the Images Folder from from the other Linux Machine?

The short answer is yes, but there is something you need to know.

FOG Images are made up of two components. The first is the raw data files that are kept in /images directory on your fog server. The second part is the metadata kept in the database. You need both to make the image functional. You can copy the files over by hand, but you will need to either recreate the metadata on the target system by hand (not a difficult task) or export the the image definitions from the source computer and import them on the destination computer

Now one other tidbit that is not supported by the developers, but it works. If on your master server you add the remote fog server as a storage node. The main fog server will be a master node and the remote server is a storage node (just in the context of this configuration), the master node will copy any image marked as exportable all storage nodes in its storage group. This will get the raw images over to the target system using the standard fog image replication. But the thing it doesn’t do is copy over the image definitions. You will need to do this using the export and import method, or by manually creating the image definitions by hand. Using this method you can have golden images pushed out by HQ and each site will still be able to create their own golden images too.

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

@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