@fredlwal What do you mean?

When you create a definition, it just creates a reference point FOG will use to access the image.

Typically, people create the definition, assign the definition to a host, and then tell that host to perform a capture task. As the host is in the tasking, the image is being captured on the server. This step is unnecessary if you copied the image from another location.

The definition can be associated to any host though. It will use this definition during deploy tasks too.

@THEMCV said in Imaging a computer in UEFI mode doesn't add it in the boot order in the BIOS:

but when the computer reboots it doesn’t know how to get to Windows.

That sounds like an exit type problem to me.

At my old job, we had Optiplex 7040s, they imaged fine. If memory serves, set the UEFI and BIOS exit types to grub. Do this on the host’s general page via the web interface. If you have a bunch of them, this can also be done via groups.

It could also be that you took the image from a BIOS type machine, and are deploying to UEFI type machines. In this case, you need to make sure the reference machine is setup exactly like the target machines are firmware settings wise.

There is a client update.

I remember you were the one that had load issues in the past. You’ll be relieved that the communications between the client & server have been reworked to be far more efficient. I think your load issues are behind you now.

I need to revisit the image integrity plugin.

@K.Hays lol half a year later.

@Tom-Elliott Never mind I got it taken care of, it would seem that in the config.ini file underneath the taskreboot section the force restart the value must be set to 1. It also didn’t hurt to shorten the checkin time as well. Thank you and @Wayne-Workman for the help!

A year ago maybe I tried using a snapin to remove the old client and install the new one. I didn’t have any luck, I ended up using the hammer for it (group policy computer based startup script).

Good news I see the imaging process going through now. Problem fixed. Thanks Tom.

The holidays have officially begun here, so I will be unable to check on anything until at least 1/5/2017

But yes, I will perform all your recommended steps upon my return.

Happy holidays everyone!

Hi, I can’t help you, I’m French but I’m prefer to stay with english language
I tried to choose French on mamagement login page and in fog settings - General settings change FOG_DEFAULT_LOCALE with French also, but any change on display language.

@Maorui2k Package your own init using the source.

You can chroot into FOS while it’s uncompressed and change root’s password, then exit, and package FOS into an init.

This is a known issue. In systems with two NICs, the 1st NIC in iPXE isn’t always the 1st NIC in FOS (fog operating system). This messes with tasking. Also, I’m not entirely sure if both NICs or just the first NIC gets registered.

A long while back, I suggested that we should loop through all the NICs in FOS and try to get an address on them one at a time, and with each one try to contact the FOG Server from each. Once a NIC is found to be successful, exit the loop and proceed.

Some clarifications:

Snapins
A snapin is simply a way to get the client to run an executable. So why is there no EXE template? Well on windows .exe can simply be executed as is without a helper program. So no snapin fields have to be set. Imagine snapins like this:

Open a CMD prompt How do you want to perform your action? Is it an EXE? If so you just type MyProgram.exe and it runs. Want to run a batch script? You’d type something like cmd.exe /c MyScript.cmd. The bottom Snapin Command shows the end result of your snapin configuration

Snapin Packs
Now snapins are pretty limited, but that’s what legacy FOG was built with so we kept it for compatibility. In your post you say I generated a “SFX” silent printer installer that’s a work-a-round that snapins forced onto people. And when the new client introduced Linux and Mac support things like the SFX work-a-round were no longer viable as it’s Windows only.

So we came up with a concept being being able to “pack” up multiple files and deploy them using the pre-built snapin system (ergo “Snapin Pack”). I’ll admit we don’t have the best documentation when it comes to things like Snapins and Snapin Packs but it’s community driven documentation. Where people think it lacks, they add to the documentation.

@Wayne-Workman has done an awesome job providing almost all of the snapin pack documentation we have (https://wiki.fogproject.org/wiki/index.php?title=SnapinPacks).

The basic idea: zip up a bunch of files you need, and provide 1 runnable file/script in that zip to handle everything (e.g. a batch script to move all of your printer driver files in place).

If you’re using the default script, I believe it looks for /dev/sda, which nvme drives aren’t.

You’ll need to alter the script to a more universal version, I believe there’s a thread where some people were working on that a bit.

Thanks, that did it. I was able to push down the old images. Tks

@Tom-Elliott thanks, we managed to push the image with our work around in time, I can try your fix out soon when we re image the machines

I tried a few kernels and confirmed the issue is related to kernel version, kernels older than 3.14 worked in my host.

The exception might be an exception… I could not reproduce it.

Also just adding tidbits of info to the discussion, 0.32 and 1.2.0 used the same FOG Client. If it worked in 0.32, it most surely can work in 1.2.0.

Also, at this point I’d advise just using the release candidate of 1.3.0, it’s worlds beyond prior stuff.

@ethompson66 Thats great to hear it was just a driver. Some time down the road we can talk about having a universal image (that is sysprep’d) and injecting the model specific drivers during FOG imaging. That is what we do for our Dell fleet.

@Tom-Elliott working good now, thanks!