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

@RocksAndRolls So NFS is mounted on the host and used as the place to put the files into a storage point separate of the deployable image point.

After the capture completes, FTP (to the server from the server) is used to move the captured image to the actual image path.

For example you have an existing image called: Windows 10, with a path of /images/Windows10

You create a new “base” image for this and are in the process of capturing it anew. But at the same time another 2 machines are configured to be deployed in the mean time:

You are capturing the new Windows10 in /images/dev/<mac_of_host_capturing> and the 2 other machines that are trying to be deployed can still run at the same time.

The FTP you see called is to move the /images/dev/<mac_of_host_capturing> to /images/Windows10 once it completes.

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

@Tom-Elliott said in Fog 1.5.10 Install error libcurl4 Failed during install:

@jaumeramos Would you be willing to test:

diff --git a/lib/common/functions.sh b/lib/common/functions.sh index b20b0e482..05f40d08c 100755 --- a/lib/common/functions.sh +++ b/lib/common/functions.sh @@ -725,6 +725,9 @@ installPackages() { if [[ $OSVersion -gt 17 ]]; then packages="${packages// libcurl3 / libcurl4 }">>$error_log 2>&1 fi + if [[ $OSVersion -ge 22 ]]; then + packages="${packages// libcurl4 / libcurl4t64 }">>$error_log 2>&1 + fi if [[ $linuxReleaseName_lower == +(*ubuntu*) && $OSVersion -ge 18 ]]; then # Fix missing universe section for Ubuntu 18.04 LIVE LANG='en_US.UTF-8' LC_ALL='en_US.UTF-8' add-apt-repository -y universe >>$error_log 2>&1

Changing the functions to this code?

I’m hoping to catch as 17-21 worked fine with lubcurl4, but 22 needs libcurl4t64

It’s ugly, I have pushed if you just want to pull from dev-branch

Hi,
The dev-branch worked well for me, thanks!

Ubuntu MATE 24.04
6.8.0-31-generic
All packages fully updated before running the FOG installer (for better or worse, haha)

Thanks again for all the work on this project, it has been great to see it continue on over the years,
Dave

@Tom-Elliott thanks for all !

@J-Redshaw I suspect yours is likely related to Bitlocker encrypting the free space of your drive.

https://forums.fogproject.org/post/134625

@TaTa Glad that worked for you! There hasn’t been any update to the github thread since 1/31, but I was able to compile binaries today using the original buildipxe.sh script without the additional line without error.

@Thierry-carlotti said in iPxe boot fails : Coud not boot :Permission denied (https://ipxe.org/0216eb8f):

iPxe boot fails : Coud not boot :Permission denied (https://ipxe.org/0216eb8f)

This really sounds like secure boot is enabled keeping ipxe from loading/running.

@45lightrain Lets cover a few things that I’m aware of that might help you get to the bottom of the issue.

When you have a ProxyDHCP server and normal dhcp server on your network you will get two dhcp OFFERS. Well I guess it would be the same if you had two dhcp server you would see two offers, but that is a bit off point. You can tell if an OFFER packet is a proxy dhcp packet because dhcp option 60 will be set to PXEClient in the ProxyDHCP OFFER. That is a signal to the pxe booting client to come back and ask about pxe booting from the ProxyDHCP server. The pxe booting client will ignore the pxe boot information from the main dhcp server. A properly formed dhcp packet will have both the fields in the header {next-server} and {boot-file} filled out for the bootp booting protocol part of the protocol AND should have dhcp option 66 and 67 set for the dhcp booting protocol. Both must be filled out because its up to the pxe booting client to pick either the dhcp or bootp protocol. Your ltsp files are correct. The last one you posted has the dhcp-range… commented out, that turns off the proxydhcp feature in dnsmasq.

SO if you have a pihole server that runs dnsmasq, why are you running an external dnsmasq server. Does your pihole server have pxe boot options? I know pfsense has built in pxe boot fields you can fill out that supports dynamic (bios/uefi) boot loaders.

When trying to debug this wireshark/tcpdump is your friend that tells you what is flying down the wire. Just remember that dhcp is based on broadcast messages so you can “hear” them from any network port, and proxyDHCP like other unicast messages must be captured at the source, destination, or via a mirrored port.