@x23piracy it isn’t a can I it’s a you should. Php and Apache is always installed regardless of node or server install.

@dholtz-docbox On Dells, they can be in UEFI mode, but if legacy option ROMs is enabled, that UEFI system will boot from something like undionly.kpxe. But when this happens, it will never properly exit to a GPT disk. I’ve seen this before at work.

Most likely, the answer here is to configure DHCP to hand out only ipxe.efi.

@Joe-Schmitt Just to add a little more detail here.

As I posted before. I have MDT build my reference image using the lite touch process. Once the process is kicked off I don’t touch the reference image until its time for sysprep. I have the fog client installed via an application in MDT. This is the command I use to install the FOG Client.

@Echo Off start /wait msiexec.exe /i FOGService.msi /quiet USETRAY="0" WEBADDRESS="192.168.1.53" net stop "FogService" sc config "FogService" start= disabled

This makes a lot of sense. I have seen the FOG Client referenced numerous times and thought it to be the web portal this whole time! Thanks for pointing me in this direction though! This is exactly what I wanted, before I went and did a whole bunch of unnecessary work, heh.

-Dustin

Everything here works now though - including EXIT where I need it. Thanks again.

-Dustin

Very cool, thanks! I set the image type back to Single Disk - Resizable and everything is kicking off like I would expect now.

-Dustin

I had to table these efforts, as I have been unable to successfully clone and deploy an extended linux image without having the swap drive hiccup during the cloning/imaging process. I will return to this as soon as time permits, but I have a few tentative workarounds for this milestone.

-Dustin

Understood - I felt I should have done that as well; my mistake.

That said, I have resolved the issue. The issue was addressed by updating the swap drive’s UUID. I raised this question before, how the swap drive does not correctly re-assign its UUID upon deploying an existing image. I had to manually re-assign this to get the image capture to work correctly. Moving forward, the swap drive’s UUID needs to be set as a part of the post-imaging process. Otherwise, subsequent image captures will fail, it appears, from my experience so far.

Nonetheless, thank you for being so attentive - all of you. You guys are seriously the most enjoyable group of dev’s I have had the pleasure of asking questions.

-Dustin

@Wayne-Workman If you look at the scripts you see that it makes perfectly sense what Tom is saying. In capture we usually create a text file called d1.original.swapuuids where we store the UUID of the original SWAP partition. In deploy we generate a new SWAP partition on the target system using the saved UUID. So there shouldn’t be a need to modify /etc/fstab at all!

I haven’t tested this in a while as I am too busy with other things. Just saying that this is how I think FOG is behaving. Same as Tom does. Anyone keen to try this and see if we have an issue in the scripts?

https://github.com/FOGProject/fogproject/blob/dev-branch/src/buildroot/package/fog/scripts/usr/share/fog/lib/partition-funcs.sh#L309
https://github.com/FOGProject/fogproject/blob/dev-branch/src/buildroot/package/fog/scripts/usr/share/fog/lib/partition-funcs.sh#L377