@Jamaal The tutorial was more of a proof of concept than something that should be used in production. Did it work, yeah. Would I probably use it… maybe not but some of the dedup capabilities in 2016 and 2019 make it sound intreaging.
For your case if you have additional space on your VM host server you might consider adding an additional virtual disk to your fog server then adding it to the LVM group for your fog server. There are a number of ways to go about this, but that discussion should be moved to a new thread.
Ok, I’ll create a new post, thanks for your assistance.
@Gabor This is a complex topic as I already mentioned! You need a lot of knowledge on different technologies and be able to debug things thoroughly. While we work on making this easier I am not sure it will ever be fail proof for everyone just because of the complexity.
Anyhow, I may ask you to re-read the wiki page. There is one part showing you how to re-build iPXE binaries using your custom CA. Whenever you change the CA and/or certs you need to recompile your iPXE binaries.
1.5.8 keep remembering the Windows Keys in the Host
Yes that info is stored in the database. With that said, the upgrade should not erase keys. If it does then there is a bug in the upgrade script. AFAIK nothing is ever deleted from the database during an upgrade. A schema change will add or remove fields but not data.
@jeremyvdv I’m sorry I don’t have a good answer for you. With the fog server max clients at 0 and other nodes greater than 0, the code should use the available storage nodes and not the FOG server for image delivery.
@Hubi i’m pretty sure there’s references on how to do it on the forums, but here’s how i’ve done it in the advanced menu. it will take just a little modification to put this into the ipxe menu entries instead, but it should give you a pretty good idea of where to start
@Tom-Elliott Thank you for your input. I realize that i have made a mistake in the code. I am new to bash and fog in general.
The idea is to have a while loop running until an image has been assigned. Or a sort of pause before it continues. The reason being that this is being done remotely and I would be assigning the correct image to the host. I am not psychically in front of the computer. The hosts users would only select that they want an image to be deployed and not select an image to deploy.
Hope that makes sense.
So what I guess I was looking for and I do realize that this is n the wrong thread is a way inside a while loop to see if an image has been assigned before continuing on with the deployment. BTW I have modified the fog.man.reg to go straight to the fog.download and the end of the registration.
True that, George. I was just surprised, as I had a few different USB-to-Ethernet adapters provided to me at work and none of those would work, and many Google searches solidified the suggestion that there were only a few USB Ethernet chipsets (chip manufacturers, chip-somethings, whatever) which were supported by PXE.
The search was made more difficult in that even in the last few years (2016-present) people seem to continue to prefer Legacy booting over UEFI. If I ever decide to get the other device, I’ll let you know how it works so it can also be added to the list, if that’s something you guys are keeping up.
IMHO spinning up a fog server from scratch takes out a lot of variables that may cause issues. The install script for FOG is quite streamlined these days. Though I am a vmware user, I find that templates and pre-builts save you literally just a few minutes at the cost of many potential issues, especially since network environments vary so much.
This ipxe7156.ipxe also seems to be working for some Dell machines we have.
To make Hyper-V Generation 2 VM’s to PXE boot UEFI correctly; I had to add a new PXEclient mapping of PXEClient:Arch:00007:UNDI:003000 for the ipxe7156.ipxe boot file. (Secure boot should also be disabled!)