@george1421 I’ve actually looked into this - I have to emulate ARM on x86_64. I’ve found one good article on it for the platform I use, KVM + libvirtd + virt-manager

No need for multiple posts: https://forums.fogproject.org/topic/10060/acer-laptop-uefi-pxe-works-in-general-wds-but-i-tried-it-with-fog-and-it-runs-through-code-and-boots-from-hard-drive/2

@Tom-Elliott don’t slap me, i will not use the script i was just fighting for the op 😉

If you upgraded your main fog server to 1.4.0RCx without issue then your storage nodes will update without issue. The storage nodes use a subset of the features of the master node. In that they do not have a local database (mysql and ftp) seem to cause us the most issues during the upgrade.

With that said, expect issues (we are here to help). When it works successfully be happy and move onto the next issue.

@george1421

I added a Cisco switch in the mix, but I couldn’t get it to pass any traffic, even from the switch itself. I don’t know if adding a layer 3 switch into the mix confused everything?

Anyway, I’ll wait until we get new equipment and then debug it from there, like you suggested. We’re going to be reimaging multiple machines at a time before we get new network equipment anyway, so I most likely need to get a RAID 10 set up.

Once we get new equipment in, I’ll give the Multicast a shot and then reply back to this thread. But, that’s way in the future. Probably several months or more.

I appreciate all the help you guys have put in to this! Thanks a bunch!

@Joe-Gill You should have no problems running a node on CentOS.

This is a slight alternative if you updated your workflow.

When the computer is checked back in and placed in the dock.
The staff member would boot the computer up in the dock and either press F12 to get to the boot menu and select network to reach the fog menu (or based on the boot order it would boot to the FOG Menu right away). Once at the fog menu the staff member would pick quick image (or what ever its called now). Then fog will lay down the image. There is no need to touch the web console. I’d have to check but I think we can even set the quick image feature as a default FOG Menu option. In FOG 1.4.0 (soon to be released) there is an option to limit the quick image menu to only display the image you defined for that host system. Today it will list all images defined in the FOG environment.

There is another option that may take a little hacking (very little). When you schedule an image deployment FOG creates a task for this. At the very end of the image deployment the target computer checks back into the fog server and tells it “I’m all done”. When the fog server gets the “I’m all done” signal it will remove the task from the list. If that “I’m all done” signal is not sent by the target computer the task will remain in the queue. Someone with little computing skills could make this change to the inits to disable this signal. I’m not in favor of this route, but it is possible to do without much effort.

@Wayne-Workman Thanks so much! Setting up auto updates will be next on the list 🙂

@Quazz said in Post Sysprep Driver Install:

But say you work repair service where every possible model under the sun gets dumped for you to fix, then you need a broader solution.

warning with snappy driver installer… the project was hijacked and now includes malware… therefore a fork was generated called snappy driver installer origin…

https://sourceforge.net/projects/snappy-driver-installer-origin/

Someone had made a change to the dhcp server and took option 066. Working now. Thanks

Thanks all good!

@Wayne-Workman not tested yet, but i will try this but don’t expect it in the next hours 🙂

@george1421 Thanks a lot

@Bob-Henderson The sometimes not part - that’s probably a fog client issue. Like encryption reset needing done or bad config or something.

@george1421 ah, that’s right. i forgot about that. that would make his version a month or two before the first 1.3.0 RC build. there shouldn’t be any problems with upgrading that.

@Rj_linux Wayne I think explained it well. FOG uses distibution standard dhcp server (if running on an isolated network). If you already have a dhcp server the clients are using there we have other ways to support pxe booting if you existing dhcp server is not able to supply the dhcp option 66 and 67 values for you.

@george1421 said in Imaging HP EliteBook 840G4 : Could not boot: No such device:

@jamessl That is the entire content of that file?

I would expect the config file to look a bit more like the one in this link: https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence#Example_1

With the IP addresses change to match your isolated network setup.

George - full file posted above. Any ideas why it doesn’t work? I guess that none of the classes are able to interpret the UEFI on the HP laptop and boot it? If so, how would I build a class to make it boot?

unless you’re specifically testing the ipxe boot file, you can just set up a line in the default.ipxe file like this

:bootme # redirected to dev server for test environments ##test-computer iseq ${serial} F8HLK02 && chain http://test-server/fog/service/ipxe/boot.php##params || # normal fog server chain http://normal-fogserver/fog/service/ipxe/boot.php##params

The certificate stored on the “clients” is the Public certificate from the FOG Server.

The only certificates to backup are in /opt/fog/snapins/ssl on the main FOG Server. As long as the public cert the clients receive match the originating server’s private certificate CA signature, all will be well.

So there’s nothing to do with the “FOG Client” install.

As of FOG 1.4.0-RC-3 the /opt/fog/ssl directory is backed up to other storage nodes as necessary too.

@george1421 Ah ok. I think I may be fine with the i5 and 8GB of ram in that model, but I do have a Optiplex 780 image that I can improve by lowering the compression then. Thanks for the tips!