@Sebastian-Roth Sorry, my bad, was thinking about a completely different page! doh

@Mr-Pinguin777 https://wiki.fogproject.org/wiki/index.php/FOG_Client#FOG_Client_with_Sysprep

Unattend.xml problems can also cause this issue, especially in combination with not doing the above.

If you didn’t choose to “generalize” hardware during sysprep, then it’s possible one of the drivers is causing issues as well.

Some antivirus software has been known to cause this as well and must be installed post OOBE (once client reaches the desktop in other words)

@Mr-Pinguin777 It not rebooting is annoying, but not the main issue.

FOG deployment seems to have gone as expected.

Do you use an unattend.xml file during sysprep?

Is FOG client installed before sysprep?

If yes, is the service disabled before sysprep?

@Sebastian-Roth Storage groups should be harmless. Could even make it a hierarchical structure if we’re so inclined.

@eVal I’ve heard of people having issues capturing when updating existing images like that.

Most people’s workflow consists of spinning up the latest Windows 10 ISOs, installing all their software, sysprep and then capture I believe.

You might have to use cleanmgr.exe (default windows cleaning utility) to clean up the updates after they’re installed.

Defragging might also be since a large amount of data was moved around.

I don’t know if you tried dism /online /cleanup-image /startcomponentcleanup either.

But even after all that it might still act up.

@Junkhacker Sebastian and I discussed ZSTD a bit and the coin kind of fell on the “let’s keep ZSTD at this version until Buildroot catches up” to keep things a bit simpler and requiring less maintenance from the dev team.

There are other tools in the toolchain that could theoretically also be upgraded, but at the point you’re putting so much maintenance on the board for any future release that you have to question why you’re using a bundled package like Buildroot anymore.

@Sebastian-Roth Possibly the same problem as https://forums.fogproject.org/topic/13546/problem-capturing-image-no-space-left-on-device

It’s really odd that the resize tests succeeds, but then the actual resizing fails! Logically speaking this shouldn’t happen, ever, since it makes no sense.

It’s worth noting that ntfsresize can fail due to bad sectors, which is potentially even the most likely explanation to this problem given that we rarely see people bring it up and they tend to fail to reproduce it.

@eVal How much data is currently in use on the main partition? We can see that FOS think it can go down to around 18.76GB

@kralon Can you also check the specific host (or hosts) page and see if it’s active in their settings too?

Your images didn’t seem to upload correctly.

You could try adding the kernel argument noacpi in the FOG settings, though potentially the real culprit might not be ACPI related at all, hard to say without the images being visible.

@VictorV I’m not 100% sure if this works, but you could try to make the partitions the relative percentage of size as to what you want and then capture as Resizable type image.

If I’m not mistaken, it will try to resize those partitions according to their relative size.

So if for example you have as 20GB of a 100GB disk and as 80GB of a 100GB disk, then it should come out as roughly 100GB for on a 500GB disk and 400GB for

Alternatively and perhaps more flexibly, you could make a non-Resizable image with just the partition and then include a SetupComplete script that automatically creates the new partition for you using diskpart.

Or, if you are more comfortable/knowledgeable in Linux, you could also try to do the same as the above, but using FOG postdownloadscripts (scripts that run after deploying the image, but before reboot)

Unattend files have multiple sections that describe a phase of the installation process.

Creating partitions is one of the first things that happens for an installation.

If you image after this part (eg in audit mode) then that has already taken place and will therefore not be ran at any point any more regardless of an unattend file.

As a sidenote, we recommend using partclone as image manager.

@ITSLUIGICASALE It’s worth noting that you can capture/deploy UEFI images from a legacy network stack.

So you can put the computers in UEFI, install windows, etc and then capture the image.

Or if you already have an image, you can boot into legacy network, deploy the image and then switch to UEFI.

@Ray-Zuchowski I think uninstall mariadb and install mysql should work fine, I’m not 100% sure, but that’s where I’d start.

But check the mentioned folder and see if you can find the fog database first.

This is a known problem on Ubuntu (the database moving when changing to mariadb)

You will likely find your fog database in /var/lib/mysql-5.7

Currently, FOG does not try to move to mariadb on Ubuntu for this reason.

If possible, going back to mysql would be the best option I reckon.

Some machines need UEFI network booting to be explicitily enabled.

If your boot options are set to “UEFI first” but there isn’t a UEFI network boot option, then it will logically just try to boot legacy network instead.

@Sebastian-Roth Those should still work yes. Also created a PR on github, so through that way people could check it out too I suppose.

We only really have consumer grade hardware here, rarely anything special, so I know it will work in most scenarios, just need to know if it also works in those other scenarios!

Would be great if we could come to a satisfactory answer on this matter. Unfortunately I reached the limit on what I can test on my end (all good), but obviously we want to be sure it works at least as well as the older version for everyone.

@Luc-Novales Kernel building is now part of the init building process

https://github.com/FOGProject/fos is the github branch if you want to check it out.

I believe George sent you a chat message (top right) with the kernel he made though.

@rogalskij ipxe.efi is the default file for UEFI.

However, it may pay to take a look at the default FOG DHCP config so you can serve both legacy and UEFI clients alike.

https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence#Using_Linux_DHCP

@oleg-knysh Download the init file from the provided link, put it in /var/www/fog/service/ipxe

Give it a name that isn’t init.xz (eg init_partclone.xz) so it doesn’t overwrite)

Then you can change the host init file in the host settings or globally under FOG Settings -> TFTP servers (eg init_partclone.xz)