@Sebastian-Roth if I had to guess it’s lvm setup.

This old topic is solved !
I was setup a new FOG stable server on a debian (on a new disk) and snapins works flawlessly.

Solved ! 😉

@slipke Well if you wanted to do it in the auto reg it will be a bit harder than manual registration, but here is the curl call in the fog.auto.reg program. https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog.auto.reg#L73

Before that curl call you will need to collect the serial number of the machine. The trick is the serial number is saved in the smbios in different locations for different manufacturers.

If you look at this post it shows you how to get the serial number for the two chassis types I had to interact with: https://forums.fogproject.org/topic/6304/fog-2-0-request-advanced-host-naming/2 It also shows how to create a complex computer name based on several factors on the fly. So you will need to compute/collect the serial number and pass it along with the other arguments to the php file mentioned in the curl call. And then in the php code read that variable and place it in the hostname variable instead of the mac address.

If you wanted to do this using the manual registration fog.man.reg where it asks for the user to input the host name into $host just use the dmidecode value to copy the serialno value into the host variable. https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog.man.reg#L161

@aborn

Good day.

Did you get any resolution for this problem?

I have Fog 1.5.7 on CentOS 7 with the specified partition sizes. All other settings as default, firewall and SELinux are disabled. My image name is W10E.

I get the same results as you did, also with the image files appearing in the /images/dev folder, then in /images/W10E and then disappearing again.

I sort of got around it by copying the /W10E folder to /W10E (copy), wait for /W10E to disappear and then rename the copy as /W10E. And I can deploy this image, absolutely no problem.

Many thanks
rarcher2

Would just like to add to this - I recently ran into this same issue again. Racked my brain trying to figure out what I did wrong or what setting could have possibly changed. Here’s what I found out.

I was using the above PC again after cleaning and prepping to capture another image. This PC was already registered in FOG. I deleted the host and attempted to PXE boot again and everything went smooth as butter. Looks like there’s an issue booting if the device is already registered. I’m not sure what the issue is, but deleting the host and re-registering solved it.

I have the same problem here, i have an Ubuntu client with multiple disks and partitions, and when I try to capture the image i have the same errors, I tried a lot of options without success.

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

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

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

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

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

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

Creating an image from scratch was the solution to my problem. So further trouble shooting/hacking is not necessary 🙂

Thanks for the help!

@Sebastian-Roth I believe there is a configuration where you can (ICH9 chipset + virtio-net network adapter)

@merrittw

What tools are you using to manage your linux infrastructure.

I know Ubuntu is the bane of FOG devs but we use it in our environment because i can push updates regularly to all our hosts with Landscape.

@Sebastian-Roth https://github.com/FOGProject/fogproject/commit/d3a70dd417eb1d08b48a637e26ec8776f4409d29

652b6f04-876c-4c27-89b0-d3bc6b01513e-image.png

I commented out the “style” info you put, and moved it to push info out to the left instead of the right so that the form field is still accessible when reading the information.

@Lugga said in Installed Snapins shown as not installed:

BUT: In the FOG Webinterface it is shown as not installed.

As Tom said, FOG only tracks the return code but not the status of a software installation. Do you mean the return code? What happens if you run your silent office installer from the command line and check the return code? Be aware that fog-client runs as a service and uses the SYSTEM account therefore. So testing things with a user account might give you a different return code. If you want to try it as SYSTEM you need to look into using PsExec. Search the forums for that.

Hey George,

No worries on the delays. Work’s been busy for me too, but today is slow finally.

I realize I messed up how I explained things. I was creating a template host with the same exact name as the group. After not being able to get it working, I tried your example name of TemplHost01 for both a new group and new host. I set the details on the host, added it to the group, and still nothing.

So I just tried again today, and the functionality is working as expected. Curious … I wonder it just needed a little more time. I’ll play with it a bit more and see if everything seems to be good.

Yeah, it definitely seems to be working better now, including with groups/host-templates that I name. I’m not sure what was happening the other day.

One thing which seems like a bug: if I’m in a group and I navigate to Membership to then search for and add additional hosts, it only adds one at a time even if I click the checkbox for multiple.

@george1421 @Sebastian-Roth @Quazz

Thanks George, I tried to use your unattend file, but it kept bluescreening on the host once imaged, so I tried creating a new one today and it worked fine. I probably didn’t change enough things in it, and missed something important, but I got around it now.

I greatly appreciate all the help you kind folks have provided. It is very much appreciated. I couldn’t have gotten to this point without it,

Dave