@hancocza the default.ipxe that is compiled into the FOG iPXE boot loader is here: https://github.com/FOGProject/fogproject/blob/master/src/ipxe/src/ipxescript

Also you will need one boot USB for bios based systems and one for UEFI based systems.

@hancocza How are you usb booting? Are you loading iPXE onto a usb? If so, what does your boot time iPXE script (default.ipxe) look like. The FOG iPXE kernels have specific parameters captured and sent to the fog server.

@AndrewG78 said in Deploy wim images with fog:

It could be used to provide something like snapshoting. I remember people were asking on this forum for backup feature. From wimlib site - WIM allows storing multiple “images” in a single archive, automatically deduplicates all file contents.

Understand I’m not speaking for the developers these are my own narrow minded opinions.

1. First FOG is not a backup tool. There are many other free backup tools that are more robust and have better features than FOG (veeam endpoint backup comes to mind).
2. FOG already has a functioning disk imaging tool in partclone. To switch to or add support for another imaging format, it would have to provide something that the FOG Project developers thought was needed or would give fog a technical advantage based on its project mission. Remember the developers work pretty much for free (donations are always appreciated), so implementing a new “anything” would have to motivate the developers to do so.
3. WIM format is owned by Microsoft. I searched a bit, but couldn’t find if it was covered by any GPL license or is it encumbered by some patent rights? I see that wimlib supports WIM format, but its still not clear about the legality of using it in a FOSS application. The last thing the fog project wan’t to do is irritate a corporation with deep pockets and teams of lawyers.
4. Its not clear from searching if wimcapture/deploy supports operating systems other than MS Windows. If it does then that kind of breaks concept of one appliance for all.

Again these are only my opinions on the matter. I don’t see any value in adding wim capabilities to FOG. The developers have a very limited amount of time these days. Working on a niche functionality for an unsupported use of FOG might not be a good use of their time.

BUT with that said, on the surface it doesn’t look like it would be too painful if someone understood programming to add that capability to FOG, if they were so motivated. If it worked, I’m sure the developers would accept the code addition.

@martial Thank you for your response. Can you tell me what that for the USB-A or USB-C dongle?

The device VID_0BDA PID_8153 [linux 0bda:8153] is a Realtek RTL8153 USB 3.0 GbE adapter.

Just collecting data here:
ref: https://www.pcsuggest.com/install-rtl8153-driver-linux/

@lschnider said in Dell Latitude 5590 issues after imaging:

Also you stated the thing about doing sysprep, is there any big benefit to doing sysprep before capturing the image?

Yes there is. Sysprep prepares the system for cloning and gets it ready for OOBE on the next boot (to be used once the golden image has been deployed to the final target computer). You should use the sysprep command line option to power off the windows computer to ensure its power off correctly. In windows 8 and later the start menu shutdown doesn’t actually power off the computer, but puts it into a deep sleep leaving files open and the disk marked as dirty. FOG will not backup a disk with the dirty bit set. If you don’t let sysprep power off the computer, then use shutdown -f -s -t 0 to power off the computer.

@jflippen I’ve been kind of background thinking about this all afternoon. What needs to happen is a deploy task needs to be created in the task scheduler then the target computer needs to reboot into a pxe boot.

FOG passes a kernel parameter to FOS during FOS startup in the variable called mode. A new mode value could be create like mode=autocap The master fog bash script would need to be updated to understand this new mode. this new mode could make a curl call back to the FOG server passing the target computer’s mac address to a php page on the FOG server. That php page would then enter the task into the task scheduler to capture an image. Finally after the curl call was made FOS would then reboot. Upon restart (since the capture task was scheduled) FOS would upload the image to FOG.

As a basic workflow that should work. Then a custom iPXE menu could be created to invoke FOS with that new kernel parameter mode=autocap.

The only missing/unknown bit is that a php page needs to be created to take the parameters passed by the curl call and update the task scheduler table on the FOG server.

I would recommend that you NOT upgrade fog 1.2.0 to the latest release of fog. But in stead spin up a new FOG server. My bet the linux OS that fog 1.2.0 is nearing not being supported by the linux distro as well as there has been 1000s of changes to the code base since 1.2.0 and 1.5.5. The upgrade should work, but your OS is probably old and there is always a risk of the upgrade failing and then you not having a FOG server while the bits are being reassembled.

Wayne did a pretty great job with the how to step by step to install fog on centos linux: https://wiki.fogproject.org/wiki/index.php?title=CentOS_7

Here is more general guide: https://wiki.fogproject.org/wiki/index.php/Installation

@cristianvalente said in ADK provisioning package settings won't apply after an PXE Boot:

Is somebody familiar with ADK and PXE?

Yes and they are not related. Provisioning packages are deployed from inside the OS. FOG doesn’t now or care about windows applications. Are you trying to deploy a provisioning package as a fog snapin?

@lschnider Does virtual box pxe boot in uefi mode? If not you will need to do what you suggested, switch back to bios mode on the vm to capture, change the boot file to undionly.kpxe, capture the image. Then change your boot file back to ipxe.efi and deploy the uefi image to a uefi computer (hint: setting up dhcp to dynamically handle this would save you troubles later)

I get the impression you are using the FOG server as some kind of backup tool. If you are doing that, there are better (free) tools out there than FOG, such as Veeam Endpoint Backup (free).

There are surely risks in proceeding with your plan. Uncontrolled disc consumption is one that comes to mind.