@lebrun78 It’s impossible to make that work. You can’t mount a network disk locally and then export it again.

You might be interested in attaching a full hard drive to the VM and using that for storing the images.

@tom-elliott I haven’t been very active here lately, but I’m willing to help on PHP8 support.

Still setting up an environment at home, but once it’s ready I’ll take a look.

Just a guess but try

sudo ufw disable

Possible causes (top of my head, could be slightly off):

Antivirus causing havok (unlikely since some computers work)

Drivers causing havok (likely, since it’s limited to certain models)

unattend.xml causing havok (possible, depending on how it’s configured)

http://wixtoolset.org/

Maybe?

@peirkern Both the “clock skew” and certificate failures would indicate a problem with your clock/datetime on the docker image, though the echo’d output seems to indicate it’s fine (or close enough anyway).

Still, can’t hurt to doublecheck?

The WebGUI looks in /images

If your image is in /images/dev then FTP failed to move it to /images

So check the Wiki to troubleshoot FTP problems

@grungeman Based on what Sebastian said, it sounds like partition is being resized when it shouldn’t because its label is not the one it should be. This occurs on capture, hence why you need to make alterations to the label and then recapture.

One question a side from the main subject, is it normal that i create a new fog image choosing Partimage, but when the capture is done and i view the image it now say Partclone Gzip?

Yes, PartImage is no longer used for capture, it defaults to Partclone Gzip. It is there for legacy purposes (to deploy old partimage images)

@Tony-Ayre I think the keypoint is to try and avoid hammering the FOG server with a snapin download over so many clients, when it might be needed for other things.

If even just one client is downloading a snapin that takes a while, that means imaging will slow to a crawl, this is often undesirable or even unacceptable, especially since there’s no real oversight on how long it might take.

Sure, regular network traffic could also cause this, but if your network is as good as you say it is, then the bottleneck will be the FOG server itself (most likely the hard drive/SSD) which can only throw around so much bandwidth before it caps out.

Snapins downloading slowly (as a ton of them would be happening at the same time most likely) is no problem if nothing else needs to be done, I suppose, but that’s a rather specific use case, imo.

@peirkern Ok, looks you’re doing this on Windows docker, which means it is using WSL2 as a backend.

https://github.com/libffi/libffi/issues/552

It seems that it doesn’t behave correctly in that environment currently (that specific package that is).

You might run into other problems as well if you’re unlucky.

You can try disabling WSL2 in docker settings and see if that helps.

@SteveB689 It’s usually a credentials issue, typically under the Storage Node configuration page.

For your second one, I recommend running chkdsk /f . Your MFT seems to have some issues there.

Exit code 1 more or less means partclone exited earlier than expected, the suggestion is somewhat misleading. This could be caused by any number of things.

Are you using resizable image type?

@fredlwal I’m guessing git is complaining?

Try doing

git config --global http.sslVerify false

Then try cloning the repository again.

@phil_guy Long shot, but there isn’t any other DHCP server on your network, right…?

I don’t know what that link is, but it doesn’t seem to be a dhcp config file.

@m144 I personally use Defprof to keep most of the customizations for the default profile.

@fredlwal Please run

apt-get install software-properties-common

And try again.

If it still doesn’t work, please post the error-log in the your git folder/bin/error_logs/ here

Judging from the error, the snapin stopped because of an issue with the hash. I’m not sure what went wrong precisely, though.

What revision are you on? What OS is FOG running on? Are you trying to do this in a VM?

defprof is an excellent alternative for setting up the default profile.

I gave up on unattend files for Windows 10, personally, more headaches than its worth, but then my use cases tend to be simple enough.

Create a dummy image and host, export as csv and use those as templates.

FOG 1.2 has almost no support at all for Windows 10. You’ll need to upgrade to trunk to do it.

And unfortunately if you want to upgrade to trunk you’d need to install a newer version of Ubuntu (or other supported linux distribution) for proper functionality.