@EduardoTSeoane Definitely give 1.5.6 a try. The changes should make a difference in your case.

@EduardoTSeoane Ok, good to know you have PHP 7.2! Increasing the timeout is not too bad of an idea. There were changes since 1.5.5 that might be of help to you. So you might consider updating to 1.5.6 to see if that helps. Those are the changes that should help speed wise:

• https://github.com/FOGProject/fogproject/commit/859fca523636c407187190f3b34b2ced55b98c28
• https://github.com/FOGProject/fogproject/commit/87338676f5aa87687aad243ab47e80798151dd6c
• https://github.com/FOGProject/fogproject/commit/67b4e64ed6ed6190291fb9fbb9599d5c12af1792
• https://github.com/FOGProject/fogproject/commit/0e54cfe594de9da9becea3a88b556ae02697d671 (the most important one I reckon!)
• https://github.com/FOGProject/fogproject/commit/6ccf933d3358ef9e1847a35cc943ad26a03b8dd1
• https://github.com/FOGProject/fogproject/commit/c01e710d0eda05dda3a20767948e9e0534ef89dd
• https://github.com/FOGProject/fogproject/commit/3b4ff68ecd4944920366b18993f23f2da8f13075

You’ve probably one of the biggest FOG installations and I have to admit that we (as in the FOG devs) didn’t write the code with such huge environments in mind. So we need to work together to try and make this work more smoothly with lots and lots of nodes and clients.

So please try updating to 1.5.6 and we’ll take it from there.

@michaeloberg Did you ever solve this?

@EduardoTSeoane Which version of PHP do you have? rpm -qa | grep php or dpkg -l | grep php

@BSZAdmin Please run ls -alR /datastore and post output here.

@george1421 said in Failed to Set Disk GUID (sgdisk -U) (restoreUUIDinformation):

so there must be something unique about what the OP is deploying

Exactly and therefore there is not much value in extending the space as we never know what people do. As Tom mentioned this could be caused by a postinit script that might try to mound an external destination but fails and instead fills up the virtual root filesystem. It’s just a guess but unless we can replicate the issue we can’t say what’s causing the errors in the first place.

Why not with the next release just update this value in the web ui to 256MB and then up the init fs size to 200MB?

Sure that would be what we’d do in case we increase the inits. But as I said before we quite often have people who only need to update the inits and they will run into the kernel panic (which is not a horror scenario but still ugly if it hits you without prior notice) if we forget to tell them about it. But well, the whole discussion is a bit over the top. I should just go ahead and update the size value in the DB as soon as possible. The earlier we have that out there the less we can get in trouble with this.

Maybe the proper course of action if we want to keep the 100MB fs disk is to have the OP generate this error again in debug mode, when the “no disk space issue” is hit, crtl-c out and then run some cli commands to find out where the disk space is consumed. There has to be something doing this in the OPs environment.

RIght, @austinjt01 can you please do as George described?

@LindsayS said in AD Join:

it would auto-encrypt the password

Have you used the old legacy client before? With the new fog-client we don’t do the password encryption anymore.

@george1421 said in Failed to Set Disk GUID (sgdisk -U) (restoreUUIDinformation):

Didn’t we update this initfs to 256MB with this change to the build root config file? If I remember correctly the fog default was 100MB.

Absolutely right but I have that feeling that this might cause us some trouble in the future when we tell people to manually update the inits to get some new fix and they’ll end in a kernel panic. Sure this is something we can fix quickly by telling them to update the size setting in the web UI but it’s kind of anoying. On the other hand we probably will need to push up the size at some point anyway - that or I need to work through the whole config and see what we can get rid of (e.g. toss out partimage support at some point in time) to free some space.

I’ll have to boot my last initrd file to see the free space, but 4MB sounds small.

4.7 MB is free with the old 100 MB sized initrd. I think that’s enough at the moment.

@Fernando-Gietz Seems like a nice workaround. Please give @EduardoTSeoane’s suggestion a try for now. I can imagine this is something we should be able to fix within the fog-client but neither have I got a sysprep setup ready nor the time to dig into the depth of windows service dependencies and timing. Sorry!

Probably related: https://forums.fogproject.org/topic/13224/issue-joining-domain-activating-windows-after-deployment

@tgidwani Ok, lets try to focus on the following warning in the logs: ftp_put(/images/dev/ac1f6bb0690e): failed to open stream: No such file or directory

What FOG does is it boots the FOS (FOG operating system) on the clients and mounts /images/dev directory (NFS export) to write the new captured image into /images/dev/<MAC-ADDRESS> - in your case the client MAC should be AC:1F:6B:B0:69:0E - please double check just to make sure there is no culprit in this. Now after the image capture is finished FOS calls back to the FOG server and tells it to move that newly captured image from /images/dev/<MAC-ADDRESS> to /images/<IMAGE-NAME> and this is exactly the point where things seem to fail for you.

Thinks to check:

• When capturing an image, do you see files being written to /images/dev/ac1f6bb0690e -> if not we need to figure out why!!
• When the capture is finished, do you still have those files in place? They should still be there if rename/move failed. -> Then try to rename/move those manually via FTP to hopefully see why it fails. Connect via FTP as below and run: rename /images/dev/ac1f6bb0690e /images/Imagename

@EduardoTSeoane Sorry for the late reply. This is fixed in dev-branch already. Thanks @Fernando-Gietz

@Olduser The FOG version you use is very old and I’d suggest you update to the latest official version first.

@quinniedid said in Issues with Gparted PXE Booting:

It has not been resolved.

Sorry, I got that completely wrong. Shouldn’t try to answer in a rush.

@quinniedid Do you mind sharing how you got this working? Others might find it helpful too.

@quinniedid said in FOG 1.5.6.2 Issues with Resizable image:

Sometimes the resize works and other times it doesn’t

Do you mean the same image sometimes resizes and sometimes not? We’d need the exact same information from your image (best to open a new topic) to look into this.

@Tom-Elliott said in Failed to Set Disk GUID (sgdisk -U) (restoreUUIDinformation):

There’s possibly something else causing the no space left (meaning it’s filling the initfs rather than the disk itself.)

I am farily sure this was the case here. I just booted a client into FOS and see that we still have 4.7 MB of free space. Doesn’t sound like much but that’s heaps for a couple of text files we generate.

I was just wondering if adding more space will cause us more trouble than it helps. More often than not I forget to tell people to update FOG settings when using the new init. Sure we can update that value in the next release but I am wondering if it’s worth it. On the other hand updating it a fair bit now will prevent us from issues that might come at some point when we keep adding to the inits little by little.

@Jonathan-Cool Possibly related?!? https://forums.fogproject.org/topic/12204/fog-powershell-not-copying-to-win32-grouppolicy-adm

@george1421 @Tom-Elliott I am still wondering if the “No space left on device” was caused by another error and it’s not actually the rootfs being too small. I need to double check when booted into FOS later on but I think we don’t actually have a space issue. Should we still increase root fs size?

@Fernando-Gietz Not sure what we can do about this. I think I am not able to properly replicate the issue. Though I don’t sysprep and therefore have a different situation.

@VijayBomble Any news on this?