Posts made by Derek Newbold

@rude26 if you have the FOG client installed on the image, then I think by default there should be a “FOG.log” on the C drive of the computer. That log should hopefully have a section in it about computer name and domain joining which generally has info in it about what is going on. Just bare in mind that it appends to the log, so it could have that section of info in the log multiple times, so make sure you are checking the latest info in the log. Sometimes I clear the log and then reboot and check the log again to make sure I’m looking at the latest info.

Did you set it as a “Single Disk - Resizable” image type? If so, were you creating a Windows 10/11 image?

We’ve had trouble with that lately and it turns out that Windows was putting a little partition after the main C partition on the disk. I think FOG tries to resize the last partition by default, so it ends up only resizing that small partition, thus it won’t end up fitting on any smaller disks.

To fix it we just removed that last little partition before capturing the image. I think it was just a recovery partition or something that we didn’t really care about.

Hope this helps!

UPDATE 2: I have come up with a better workaround now I think.

I installed MySQL Workbench on the FOG server as I’m not very familiar with editing SQL via CLI.

I can see that the ‘imageSize’ field of the image has been wiped out, and if I set it to something (e.g. copy the imageSize from another image, even if it’s the wrong size) I can then image another host successfully and it updates the imageSize to the correct size.

Now I’m just going to work out what value it puts in the imageSize field on a fresh image (like in my first workaround), and use that instead of a random imageSize value when this issues occurs.

If anyone knows a better solution aside from updating FOG, please let me know!

So I have come up with a workaround for now.

I duplicated the image folder on the server, then created a new FOG image using that folder.

I then set a host to image using the duplicate image and it imaged successfully, and during imaging it updated the image size in FOG to be to be 100 GiB like it should be.

We now have tried imaging a host that is having issues again with the duplicate image and it failed once again, and the image size on the duplicate image in FOG is now saying 0 GiB.

I’ll endeavor to try and update our FOG install when we find a suitable time to do so, but hoping in the meantime there might be a workaround to reset the image size issue? Is it just an SQL reference somewhere that we can update/remove?

Hi,

We are having random issues where our captured image stops deploying successfully and when this happens we notice the ‘Image Size ON CLIENT’ on the image in FOG has changed to saying it’s just 0 bytes. Any further deployments of this image just fail, so we are having to recapture our image to get it to work again.

We think it happens when an image fails to deploy to a client for whatever reason, then FOG is changing the image size to 0 bytes which in turn is causing the image to stop deploying.

We found in the recent FOG change logs some references to the image file size, so we are thinking it’s something that might be fixed in newer versions of FOG? Is there any more information about this?

Due to it being quite difficult to update our FOG install, we are wondering if there might be a quick fix we could apply to our current version of FOG to fix this particular issue?

If that is not an option, is there an easy way to just tell it to re-import/recheck the image files on the server, as the files still seem to be there?

Current FOG version: 1.5.4

Thankyou,

Derek

@Sebastian-Roth thankyou! I’ll open another topic if need be when I get a chance to look at upgrading FOG.

@Sebastian-Roth in that guide one of the first steps is to re-run the installer after changing the IP address of the OS and in the /opt/fog/.fogsettings file.

My problem is that once I change the IP address and network connection back to what we normally run FOG under, I lose my direct (unfiltered/firewalled) internet access, so I’m back to not being able to run the installer. Is there any way around that?

Sorry this post is probably going a bit off-topic now.

@Sebastian-Roth @sudburr @Boyan-Biandov

Thanks everyone! We’ve changed our image capture to a fixed disk size now and we already happened to have the <extendpartition> bit in the unattended.xml file. This arrangement is now working for us and the partition has been automatically extended on our test machine.

We don’t really need the ‘Single Disk-Resizable’ if we can get the partition to extend in another way. Our VM that we capture is set to 100GB and all our destination computers have SDD drives larger than that.

I will look into updating FOG when I get some time to focus on it properly. Unfortunately for us we have difficulty updating/installing FOG through our Departments internet filtering/firewall which we don’t have full access too. I could connect it up to a direct internet connection, but that could involve a different IP address being required. I was told FOG doesn’t really like the server having it’s IP address changed, so I wasn’t sure if I should attempt to do that or not.

@Boyan-Biandov I forgot to ask in my last post, what does your partition table look like in your image that you use your script on? I see you have it set to resize partition 2.

We have 3 partitions (although the FOG partition information files lists 4 hmm) and it’s the 3rd partition that needs resizing.

Would we need to change the script to 3 or does the numbering start at 0 so 2=3rd partition?

@Boyan-Biandov thankyou for that tip! I will try that if we fail to get FOG resizing it correctly.

Do you put that in the ‘C:\Windows\Setup\Scripts\SetupComplete.cmd’ script? Your code appears to be Powershell based, so I’m guessing you must run it in a seperate script? If so, how do you call that script to run?

Thinking about it, I’m not sure it will help us as Windows is erroring during the OOBE process (due to lack of C:\ disk space we suspect) which I think would be before it even runs the SetupComplete.cmd script where we could possibly resize the partition.

I guess what we could do is not use the ‘Single Disk-Resizable’ FOG image option, and use a fixed size one instead, then your script would probably work OK and we would have enough C:\ space still for the OOBE process to run?

@Sebastian-Roth thankyou for helping with this

d1.partitions

label: gpt
label-id: B62AFA65-B825-4E56-94C3-FD0F767DC41C
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 209715166

/dev/sda1 : start=        2048, size=     1083392, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=CFEE5F7A-A283-44D1-AE88-BF7C5E9DA222, name="Basic data partition", attrs="RequiredPartition GUID:63"
/dev/sda2 : start=     1085440, size=      202752, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=23B34044-D2F1-40D9-996D-88707020B564, name="EFI system partition", attrs="GUID:63"
/dev/sda3 : start=     1288192, size=       32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=FB7F6919-A4A8-45DD-B053-1826506A9607, name="Microsoft reserved partition", attrs="GUID:63"
/dev/sda4 : start=     1320960, size=   208392192, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=C326A6E9-C39C-4692-9BCF-96D9FDF34AC4, name="Basic data partition"

d1.minimum.partitions

label: gpt
label-id: B62AFA65-B825-4E56-94C3-FD0F767DC41C
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 209715166

/dev/sda1 : start=        2048, size=     1083392, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=CFEE5F7A-A283-44D1-AE88-BF7C5E9DA222, name="Basic data partition", attrs="RequiredPartition GUID:63"
/dev/sda2 : start=     1085440, size=      202752, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=23B34044-D2F1-40D9-996D-88707020B564, name="EFI system partition", attrs="GUID:63"
/dev/sda3 : start=     1288192, size=       32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=FB7F6919-A4A8-45DD-B053-1826506A9607, name="Microsoft reserved partition", attrs="GUID:63"
/dev/sda4 : start=     1320960, size=   143069068, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=C326A6E9-C39C-4692-9BCF-96D9FDF34AC4, name="Basic data partition"

d1.fixed_size_partitions

:2:3:1

I do not recall manually updating the init.xz files so they are probably still the ones delivered with 1.5.4

ls -al /var/www/html/fog/service/ipxe/init*
-rw-r--r-- 1 fog www-data 19254252 Jun 28  2018 /var/www/html/fog/service/ipxe/init_32.xz
-rw-r--r-- 1 fog www-data 19948692 Jun 28  2018 /var/www/html/fog/service/ipxe/init.xz

Hi,

We have built a new image based on Windows 10 v1909 and having trouble deploying it. When the computer boots up it errors during the OOBE process. We’ve not had this same issue with previous Windows 10 images, including v1903.

After some investigation we ended up shutting the computer down directly after the deploy image process and then plugged the imaged hard drive into another computer using a USB adapter. We found that it appears as though it is not resizing the C:\ partition to take up the remaining hard drive space. We are thinking this is probably causing our OOBE errors as the drive gets completely full.

As a test we extended the C:\ partition while it was plugged into the other computer, and now we have put it back into the original computer and let it bootup. It then went through the OOBE process and it worked fine with no errors.

We recorded the end of the imaging process and it seems like it says it resizes the NTFS volume (/dev/sda4) OK. I’m guessing that refers to the C:? Or is it actually referring to the unallocated space as there appears to be 3 actual partitions on the drive (Recovery, No-Name, and C:).

We made the image using a VM with a 100GB hard drive allocated. The destination SSD drives are 240GB so that shouldn’t be a problem. We’ve also tried running a ‘chkdsk /F’ before capturing, but maybe we didn’t do the chkdsk quite right as per this wiki page https://wiki.fogproject.org/wiki/index.php?title=Windows_Dirty_Bit but as we aren’t seeing any errors during the FOG capture/deploy processes I’m not sure if this would be our problem?

Any ideas? Should we be following that Windows Dirty Bit guide more closely?

FOG version: 1.5.4

Thankyou, Derek

Thankyou Fernando!

Hi,

I recently found out that Microsoft are planning to turn off non-secure/unsigned LDAP connections to their server OS’s.
https://msandbu.org/upcoming-change-microsoft-to-disable-use-of-unsigned-ldap-port-389/

So I’ve been looking into what services on our network might be using unsigned LDAP.

Just wondering if FOG/FOG Client uses LDAP at all (I’m not using any LDAP plugin or anything, just a standard install) and if so, would it/can it be configured to use a secure LDAP connection?

Thanks for any help you can give me!

Derek

@george1421 had a look at our Dell 5300 device and it doesn’t have the Thunderbolt port. Although we have resolved the issue another way, I may consider looking at getting the rest of the devices optioned with Thunderbolt ports.

Thanks!

Derek

@Sebastian-Roth thankyou for the suggestion to use the parameter for external NICs! It appears to have resolved our issue. Using the workaround of replugging in the USB adapter when it prompts you to has now allowed us to get the ‘Pass’ in the compatibility test, as well as successfully imaging the device.

Thanks again!

Derek

@george1421 thanks also for your advice and suggestions, I will look into that as well!

@Sebastian-Roth thanks for your reply and suggestions! We aren’t using a USB hub, just connecting the USB-C Ethernet adapter straight into the one and only USB-C port on the 5300 laptop.

I guess the docking station (that did seem to work with imaging it) probably acts like a USB hub with multiple external USB devices inbuilt into it (e.g Ethernet, video adaptors etc.) which might explain why it worked?

When I’m back at work tomorrow I will look into your suggestions and see what I can find out. Unfortunately the time difference between us makes it difficult!

Just an update to this. We tested the ‘Dell USB-C to Gigabit Ethernet adapter’ on a Lenovo L390 Yoga device that we are also trialing, and the Hardware Compatibility check passed for that for the Network.

Does that mean it’s likely to be an issue with the USB controller drivers on the Dell Latitude 5300?

Thanks,

Derek

Hi,

We are looking to purchase a whole heap of Dell Latitude 5300 2-in-1 devices, so we have got one as a trial unit and we are having trouble with it’s compatibility with FOG.

We have got it setup to PXE boot via EFI and that works OK using the Dell USB-C to Gigabit Ethernet adapter , but when we go into check the Hardware Compatibility we get some errors coming up about being unable to enable the USB device, and then we do the Hardware check it fails on the network side. Strangely enough, if we disconnect the USB adapter while at the ‘select option’ screen, and then reconnect it and select the Hardware Check option it seems to pass on the network side then. But that trick doesn’t work if you are trying to register the device in FOG, so I assume it’s just a glitch that it’s passing.

We have managed to get it to image through a Dell Thunderbolt Dock that we got with the trial device, but that isn’t going to be a feasible solution when we buy a whole heap of these laptops. Also the USB adapter supports MAC address passthrough which would be useful when registering them with FOG as we would get a different MAC address for every device then rather than just seeing the USB adapters MAC address.

I assume it’s just a kernel issue, and I’ve tried updating to both the ‘4.19.64’ and ‘5.1.16’ TomElliott kernels but it hasn’t solved the issue.

Any ideas how we can get this to work?

FOG Version: 1.5.4 (I know it’s out of date, unfortunately not easy for us to update FOG in our environment, and I don’t think the version of FOG would cause this issue, more so the kernel version?)

Thankyou!

Derek!