I tried to change that and it did seem to limit the number of computers that can image at once. But it did still allowed 10 computers (I believe that was the amount) to be inprogress as snapins vs checked in or queued.

Network similarities are as follows Same network same switch same router differences are as follows motherboard Bios network adapter CPU (everything) its a uefi bios the network adapter I have 4 different PC models scattered about the place and get different results on them all some boot and mount the nfs others time out

@Wayne-Workman Thanks for the info. I did modify the .fogsettings file at first, but I was receiving errors for “invalid response” whenever I attempted to install. I just copied the .fogsettings from a working installation.

@Sebastian-Roth Hmm, I may have been misremembering, though their CONFIG_NR_CPUS is going to be much higher than 8 at the very least. (at least 512 afaik) The only difference I can find is that CONFIG_MAXSMP enables CPUMASK_OFFSTACK , which it requires to function correctly I believe (or any high CONFIG_NR_CPUS would at least)

@vmesuria Make sure you have CHANGE HOSTNAME EARLY enabled in FOG configuration -> FOG settings -> General settings in the FOG Web UI. Aß well you need to have the image OS ID set to an of the Windows IDs and Windows needs to be on a NTFS formated partition! If those three things apply it should do the early host rename for you.

I’m seeing the not registered static text here: /var/www/html/fog/lib/hooks/bootitem.hook.php /var/www/html/fog/lib/fog/bootmenu.class.php I would look in the bootitem.hook.php first. as well as in the language files in /var/www/html/fog/management/languages/

@xburnerx00 The short answer is it should just work if you have the dhcp boot options set. With that said, let me explain why this usb boot disk exists in the first place. We have historically seen the pxe booting process hang (stop/freeze/abend what ever you want to call it) in 4 spots that causes the FOG admin troubles. Either the computer doesn’t have a pxe boot option or for what ever reason iPXE isn’t being sent to the target computer. iPXE is delivered to the target computer but iPXE will not startup iPXE will start up but will not start up the FOS Linux kernel (bzImage). We almost always see this in uefi mode due to buggy uefi firmware on the target computer. In uefi mode the imaging tech is using a network adapter not supported by the computer manufacturer so pxe booting isn’t an option. So what the FOS Linux usb boot drive does is boot into Grub and then calls FOS Linux directly from the usb flash drive. This bypasses pxe booting and iPXE eliminating the above conditions. In this setup the Grub menu is a weak analogy to the more capable dynamic iPXE menus. We did include iPXE boot loaders on the flash drive to boot iPXE directly from the usb boot stick instead of by PXE. By doing that we can eliminate issues 1 and 4 from above. But any issues with iPXE in 2 and 3 would still exist.

@montesd Ok for that old version of FOG, you need to be on FOS Linux version 4.12.x to have the driver for the I219-LM or i219-V network cards. You can manually download the kernels from here: https://fogproject.org/kernels/ You will want to download Kernel.TomElliott.4.12.3.64 and save it as bzImage and Kernel.TomElliott.4.12.3.32 and save it as bzImage32 Watch your case because it is important. These files go into /var/www/heml/fog/service/ipxe directory. Rename the existing files in case you have to back up. Also you can try the latest kernels with Kernel.TomElliott.4.19.64.64 and Kernel.TomElliott.4.19.64.21.32 but there is no grantee that they will work with the older inits (YMMV). These would latest kernels would supported the newest hardware with the risk of incompatibility with the inits (FOS Linux virtual hard drive).

So following the link in list item #1, I ran into some issues. I created the fog.patch.man.reg file as directed, copying the quoted text into the file and chmod’ing it to 755. Your step 4 mentions editing fog.postinit, which is a file I don’t have. I wondered if you were missing a step that indicated to run the patch script, so I ran it with # ./fog.patch.man.reg and got the following output: ./fog.patch.man.reg: line 12: /usr/share/fog/lib/funcs.sh: No such file or directory Testing path for our fixed file at fog.reg.man.fix ./fog.patch.man.reg: line 15: debugPause: command not found Failed to find file [fog.reg.man.fix] sorry. Copy Failed ./fog.patch.man.reg: line 26: debugPause: command not found I am thinking that my issue is possibly advice in this forum thread, which suggests that it’s safe to delete the contents of /images/dev/. The thread is from 2016, so perhaps dev gained more purpose than a temporary dumping ground for in-progress captures? I arrived at that thread some time ago, for the same reason as the OP - I was running out of disk space and found out it was because of occasionally-failing captures. Deleted the contents of the folder and everything was good again. Following the link to list item #2, “Using scripts” was a non-starter. I have /opt/fog, but don’t have utils within that directory. Instead, I have log, service, and snapins. I ran find -iname *image* and didn’t find FOGMountBootImage.sh in the results. I followed the instructions in the “By Hand” section for Version 1.0.0 and up. I had trouble running mount -o loop init{,_32} initmountdir as CentOS didn’t like that command, so I made the assumption that it was trying to mount two directories within initmountdir (init & init_32). I ran that command as such: mount -o loop init initmountdir/init mount -o loop init_32 initmountdir/init_32 I then navigated to initmountdir/init{,_32}/bin and changed each fog.man.reg to the file I had created. It sort of worked after I packed everything up, in that things did change, but the registration didn’t act as expected. I entered a hostname as requested, left image ID blank and hit Enter, then it went to a blank line. I waited, but eventually hit Enter again, which then asked if I wanted to associate with groups. After that, when I hit Enter, it dropped to a new blank line, but didn’t continue the form. I possibly have a malformed file (I had a few errors along the way, fixed based on my knowledge of what was wrong). If you’d like, I can attach it. Any thoughts on some of the other issues above? Also, I was wondering, how would I create a new menu entry, so that my tests show up as a separate item from the primary full registration?

This is a work around, for a long term solution …ummm we must to think if this solution is for 1.5.X versions or get a final solution for 1.6.X and how can we do it XD Maybe the solution is create on fly the CSV file to export and import the data (I am thinking loud)

Thank you @Quazz ! Been tearing my hair out over this. Tried so many things, new FOG server, update to 1.5.7.4, updating to 5.1.16 kernel, using nvme_core.default_ps_max_latency_us=5500 kernel argument. None of which worked. Finally after using your new init file I am imaging at 5GB/min.

@tech04 You don’t need to worry about the FOG Project certificate. This is for verifying the signature of the fog-client software components (needed as we provide auto update in SYSTEM context). FOG Server CA is the one you need to exchange. Location should be Local Machine\Trusted Authorities. But I don’t have a Windows PC at hand at the moment. This is just from the top of my head.

Your dhcp server needs to send the boot file name ipxe.efi for uefi based systems and undionly.kpxe for bios based systems. If this is just a one off system you can manage dhcp option 67 by hand. If you want it to automatically adjust based on the target computer there are instructions here as long as your dhcp server is windows 2012 or newer or linux based: https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence#Using_Windows_Server_2012_.28R1_and_later.29_DHCP_Policy

@Sebastian-Roth First, sorry for the delay of the answer, it was a busy day and I hadn’t access to the network this weekend. We continued to search for the problem and finally, we found there was a problem with the copy of a file from /path/to/fogproject_git_repo/packages/tftp to /tftpboot. The file “default.ipxe” was missing. We saw that with a capture of the trafic and the analyze of the pcap. So finally, everything works ! To be sure to well understand, we made a new install from scratch and it’s work perfectly (Fog server & the SSL) ! In resume, here is the steps I made : Install of fog with the “-S” option to activate SSL Copy of the certificate and the private key on the machine Edit the Vhost file with the path of the private key and the certificate (with a restart of Apache2) Modify the CA by default in the directories /etc/apache2/ssl/CA/ and /opt/fog/snapins/ssl/CA/ with our own CA Execute the script buildipxe.sh from the directory /path/to/fogproject_git_repo/utils/FOGiPXE/ And finally, copy the new binaries from /path/to/fogproject_git_repo/packages/tftp to /tftpboot (The step I missed :) ) Now the server is secured and, incidentally, it’s working ! Thank you for the support !

@jhalbert Understand I’m NOT recommending you turn off spanning tree, only change its mode to one of the fast spanning tree protocols. The fast protocols use optimistic blocking (forward first then listen for BPDU) instead of pessimistic (block while listening for BPDU) that standard stp uses. Is there a way to do it without changing the network, yes but it will require a little work on your part (honestly you need to enable RSTP to fix it for all). You will need to unpack the init.xz file. Its located on the fog server in /var/www/html/fog/service/ipxe directory. The instructions for unpacking and packing the inits are here: https://wiki.fogproject.org/wiki/index.php/Modifying_the_Init_Image Follow the 1.0.0 and up instructions. Once they are unpacked in the unpacked directory you need to edit a file in ./etc/init.d called S40Network. Just before the udhcpc command add in a line that says sleep 27 Save the file and then repack the inits and move to the /var/www/html/fog/service/ipxe directory. What that will do is have FOS Linux pause for 27 seconds on every boot to let the network settle before trying to dhcp boot.

@Bill-Rice You are safe to run the install in /opt/fogproject as needed. I’d suggest Copy the current /opt/fog/.fogsettings file to /root/.fogsettings Delete the current /opt/fog Copy the original server’s /opt/fog to the new server into /opt/fog as well. Copy the /root/.fogsettings to /opt/fog/.fogsettings file. Rerun the install to be on the safe side.

@Quazz I don’t know that it’s a bug. Yes, i understand this is unexpected behaviour. But Remember the location plugin is a plugin. It’s not a default element of the core of fog. The Core elements attempt to ping all hosts each iteration. (So this is the expected behavior). That’s not to say we shouldn’t have this in bug reports and we’ll need to add things to the location plugin to distribute the PING Hosts to enable location specific pinging. This is not currently coded for or thought of so I imagine this will take a while to work out.

@AdamH From the sounds of things, the storage group item is not set on the image. The GUI tries to correct for this by applying the first storage group to the image, but if there is no actual value set, this message you see will still happen. I’d suggest updating the image even though it shows as though it is set. Thank you,