@RocksAndRolls I’m not sure how much additional help I can provide here but where it failing is at the end of the imaging process, the target system logs into the ftp server on the FOG server using the fogproject user account. That fogproject user MUST be able to rename the captured file in /images/dev from the mac address and the move the directory from /images/dev/<mac_address> to /images/<image_name>.

If you have verified you can log into the fog server via ftp as the fogproject user using the password saved in the fog ui then it has to be a permission issue on the /images directory.

The image capture process is

FOS Engine -> connects to /images/dev NFS share and creates a directory that matches it’s mac address
FOS Engine -> Uploads the disk connect as the root user (on the FOS Engine)
FOS Engine -> Connects to the FOG server as fogproject user and issues a mv command to move the directory from /images/dev/<mac_address> to /images/<image_name>
FOS Engine -> Logs out of ftp and completes the cleanup before reboot.

@COE Typically if the permissions on the /images directory get messed up you can reinstall FOG and it will fix the permissions.

If you run the chmod 777 /images that will make the directory world writable but not the existing files / folders under that directory. If you use chmod -R 777 /images it will change everything under that directory to world writable.

But before you do that, the linux user fogproject should have read write access to /images. The password for that user is found in the hidden file /opt/fog/.fogsettings That is the user account fog uses to move files around while imaging.

@Small0145 said in Client registration error:

il y a environ 18 minutes

@kelocktnt look in “Pending Hosts” on the hosts page. It should be the

OMG !!!
i’ve been walking past it since the beginning without seeing it!!! too newbiees

Thank youu @)

@Tom-Elliott Success. I switched to single-user with init 1, and installing systemd-sysv worked fine.

As this is a machine upgraded from debian 11, maybe it wasn’t using systemd. Installation of 1.6 worked no problem Thanks,

@AUTH-IT-Center That is correct. That’s what that FOG Settings item is meant to do. If that is checked, on registration it should set that flag on future registrations, but it doesn’t on existing hosts that were registered before it was checked. If after this is checked and a new host registers and this isn’t working, I would believe there to be a bug.

Though a workaround exists, so while, it would be a bug, it may not be the biggest concern to get fixed immediately over say actual imaging issues.

@PatrickL You might want to review this post: https://forums.fogproject.org/topic/17648/massive-cpu-usage-from-a-service

That .sysvd is suspicious and very similar to the thread above.

@adam1972 The AD setting isn’t general. Basically it’s enforcing the reboot happens to change the hostname and/or complete joining the domain.

I think since there’s multiple points of hostname changing this isn’t working correctly (obviously) as the hostname shouldn’t need more than maybe 1 or 2 times to change it. Snapins running still is the end of the problem though? Not sure how to approach. Since hostname change is expecting to reboot maybe this is preventing the snapins from running. We could test that by disabling the hostname changing option altogether on this host?

@LLamaPie Everything has been clean now for about a week. I would consider this at least resolved on our end. Still no answer about when it became compromised exactly. Our hyper-paranoid theory is it may have been a “time bomb”. This could have been on the server for months before popping up. Our long-term solution is keeping endpoint protection in place. I have nothing else to add but if I discover anything I will let everyone know.

@45lightrain ok so lets start with some basics.

a 1GbE link (under theoretical conditions) is 1 Giga bits per second or 128MB/sec or 7.5GB/min raw data. Understand that there is ethernet overhead and you will never achieve 7.5GB/min.

So how is it possible to see speeds above 7.5GB/min on a 1GbE link? Simply data compression. So what you are seeing in the part clone screen is a composite speed including fog server speed sending the data to the network, network transfer time, the client receiving the image, expanding in it memory, and then writing it to disk.

If you are getting 5.5-6.1GB/min in partclone on a pure 1GbE network your fog environment is well designed and network well managed.

I wrote an article a few years ago that has some benchmark tools you can use to see where you can get additional speed out of your setup. https://forums.fogproject.org/topic/10459/can-you-make-fog-imaging-go-fast

So the executive summary is that if you want to go fast.

Install at least (1) 10GbE network link. (If you have many computers running the fog clients, run (2) 10GbE links in lag configuration. If you have many clients hitting your fog server while you are trying to image use a ssd disk or nvme drives on your fog server (I would look at spending here the last, typically its not the disk that is slow, unless you have just a single spindle hdd driving your fog server). Try to get the 10GbE network as close to the target computers as you can. If you are trying to image multiple target computers at the same time look into fog casting your image to the target computers. When capturing your image use the zstd compression tool over gzip. Set zstd at compression 11 to start. If your target computers have a lot of horsepower, 16GB of ram, and fast nvme disks you can get more data through your network by compressing the data more. This will put a heavier load on the target computer expanding the image and writing it to disk.

Think if your imaging as 3 factor triangle. You have server speed to get the image to the network adapter, the speed at which your network can move the image to the target computer, and finally the time it takes for the target computer to intake the image, expand it in memory and write to disk. In the imaging process the fog server typically has the least impact on imaging of the three.

@JJ-Fullmer Good to know, thank you so much 😎💯

@Tom-Elliott

No worries, all the help is appriciated!

199cd3f7-9311-4f08-80df-dd932845af2d-image.png

a6b999ce-4c5b-4462-9181-3746b2972f8a-image.png
a900cb0f-9abb-41fa-84b8-cef64c317cc6-image.png

6d685e25-ca2f-4c18-8a27-add58d1470e0-image.png

@45lightrain said in Issues with capturing an image with a raid0 array.:

Also is fog able to capture both the OS SSD data and raid array data on the NVMe drives?

FOG captures disks in block mode. It doesn’t care about partitions (mostly). Also make sure that md0 is the true device for these drives. When you are in the FOS linux shell you can / should create a mount point and then mount /dev/mdX partition to see if you can read the content. I have seen where sometimes md0 is created but the real raid array is /dev/md126.

Also FOG calls a script before imaging starts. Sometimes its needed to assemble the array in this postinit script. Or do other things to prep the system for imaging. So the postinit script (found in the /images directory on the fog server) is a the place to put that code.

Also when you start in debug mode (when debugging the imaging process) you can actually start the imaging process from the command line by keying in fog. The imaging will stop at each debugPause; command in the imaging code as a breakpoint. If you notice something wrong, you can hit ctrl-C to exit back to the command prompt. To restart the imaging process again just rekey in fog.

While it doesn’t exactly apply here I wrote an article 8 years ago about imaging using the intel rst adapter that may contain a nugget of help: https://forums.fogproject.org/topic/7882/capture-deploy-to-target-computers-using-intel-rapid-storage-onboard-raid

@theyikes Well the first thing I would do is look to see what the kernel name is in the casper directory. Ubuntu does change this kernel name from time to time. I do think the file name listed looks suspicious. I would expect something like vmlinuz without the extension. But look to see the kernel name and adjust accordingly.

@Tom-Elliott said in FOG Update errors:

./installfog.sh -y

Thanks Tom! I am up and running again!

Disregard I was not selecting deploy image.