Most likely these are partially (or fully captured that were unable to move) capture images hanging out in /images/dev

@irishfoguser Hi, generally speaking you’re better off using Resizable image. If this for some reason doesn’t work (fails to deploy), then trying the other options is recommended.

For your situation, it sounds like Resizable Image will do the trick. So I recommend picking an image, setting it to resizable, recapture, deploy and see if it works for you.

1.3 is able to resize the correct partition for you before Windows even boots for the first time.

@AlexPDX Rule of thumb is to create a new thread, since the OP in this case was using a very old version, and you are likely using FOG 1.5.8

That said, quick fix is:

sed -i 's#/usr/bin/php env #/usr/bin/env php #g' /usr/lib/systemd/system/FOGSnapinReplicator.service
systemctl daemon-reload
systemctl start FOGSnapinReplicator

To be fair, it’s been a longstanding recommendation that the FOG server should be running nothing but the FOG server for a reason.

Apparentally, to prevent Windows search from breaking after copying the profile over, all you have to do is delete

AppData\Local\Microsoft\Windows\UsrClass.dat

Windows will create one on login.

@TomBagley Considering you have to enter tftp server address, it is likely you have another DHCP server on your network (likely your modem), which might be interfering.

I’m guessing you launch a batch script which launches a msiexec and then closes rather than waiting

Adjust accordingly.

It’s /var/www/fog/service/ipxe (singular service)

@lebrun78 You could try a different disk boot command. You can choose these globally, per group or per host I believe. Default is Sanboot if I’m not mistaken.

There’s different options because different hardware handles it differrently, annoyingly enough.

What error are you getting?

set username foglogin
set password foglogin
params
param mac0 ${net0/mac}
param arch ${arch}
param username ${username}
param password ${password}
param qihost 1
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme

Try using that, changing the set username and set password parts to your own webgui login info

@juntacadaveres Well, it’s pretty clear, boot in recovery mode and fsck -fy it.

@gutter Microsoft actually provides an executable that tries to convert MBR to GPT

https://www.tenforums.com/tutorials/81502-convert-windows-10-legacy-bios-uefi-without-data-loss.html

Your mileage may vary; I’ve used it only once (still works fine to this day), but I’m not sure it’s going to be exactly the same as a clean GPT install, that would still be your best bet imo.

In VBOX you can create an image in EFI, turn off the VM, switch off EFI, boot to PXE in legacy, capture the image and now you have an EFI image ready to go.

Key aspect to remember is that the mode PXE boots in is irrelevant to the image.

@seppim If you load it over http like in the example it should be quite fast. I use the same method, works fine.

@wayne-workman I just did the same today (easy to swap from 8 to Stream) to test it out and see how different it really is.

Most packages got fairly minor updates (eg it runs the same Kernel, just a newer security release), interestingily, httpd got downgraded.

Still, only minor point differences in packages as far as I can tell. I don’t foresee any issues with it.

Of course we have no idea how it will evolve over time.

@baessens I’m going to take a guess, but is the disk a “dynamic virtual disk” by any chance?

There is a missing , at https://github.com/FOGProject/fogproject/blob/ddcc96c4ff8158314ab0383f988c9c6666e8686e/packages/web/lib/pages/processlogin.class.php#L260

and

https://github.com/FOGProject/fogproject/blob/ddcc96c4ff8158314ab0383f988c9c6666e8686e/packages/web/lib/pages/processlogin.class.php#L283

@developers can you fix this one?

@enzogislard It doesn’t care about whether or not there is data on it, the structure gets captured and deployed.

@enzogislard I think it is a similar problem here, even if Centos.

If you move the swap partition before the root partition and then capture it again (in resizable mode) it should work I reckon.

Are you capturing in resizable mode already? Other modes will fail since your source disk is much larger than target disks, even if the partitions on it are smaller than the target disks (could be mistaken about this though)

@gfrancesco84 What is the output of list vol in diskpart?

@enzogislard This is a known problem on newer Windows 10 versions.

They put a partition (recovery I think) after the main Windows partition now, which FOG doesn’t handle that well currently. (it expects ‘data’ partitions to be last)

You can use a partition manager program to move the partitions around.

If you capture it after moving the Windows partition to the end of the disk, then it should work as expected.