@barachd Have you read my post about there being a bug within the Linux client implementation. See further down in this topic.

I guess what do you mean nothing happens?

Do you see it transfer vmlinuz ?
Is vmlinuz in /tftpboot/os/lubuntu directory?

If the menu is executing correctly it should transfer both vmlinuz and initrd.lz. It might not boot, but it should transfer the files.

If the menu is not executing at all, did you remember to fill out the description field in the ipxe menu config for that ipxe entry?

Thanks All!..

Solution has worked perfectly!

Hello @Fernando-Gietz,

thanks for the awesome help and support, it works now as needed.

Is there something I should be aware or edit in our openLDAP implementation to make the plugin work correctly without editing the /var/www/[html/]fog/lib/plugin/ldap/class/ldap.class.php file?

Ciao,
Antonio

@Sebastian-Roth It appears the UEFI Network boot selection is not available. Only the PXE option from Legacy works.

Amidst me trying to load different pxe binaries onto the server, I rm -rf /*'ed in root, so I destroyed the server by accident. Just made a new one and thankfully I have a PC with the existing image in tact with no modifications.

Is there a more in-depth guide to setting iPXE binaries? I was messing around with custom fog.local parameters using all sorts of iPXE commands I found on their site. It’s definitely getting the changes, but I can’t tell if it can’t load the bootloaders or if it the bootloaders can’t find windows.

Good evening, I’m configuring the FOG Project on several remote networks and so far it’s been a success.
I did the FOG Master in a DMZ network and in the other distinct networks I did the FOG Storage doing the replication of all the images of machines inside the FOG Storage.
The boot checks the FOG Master the PXE and after that it does the entire cloning process inside the network itself, thus avoiding bandwidth consumption and competition with other services.

@george1421 Thank you very much for the help, and surprised by the quick response that great work do you congratulations.

@andrewhancock91 yes

@mpmackenna said in Unable to build FOS:

Unfortunately, that is the only output I receive. The screen just hangs with the print statement displayed and never progresses past that statement.

Well that’s a perfect start to get into debugging where exactly it hangs. Simply add more of those efi_printk further down that function and possibly as well in sub functions called by efi_main. In other models we often saw issues with PCI initialization. You’ll see that code a bit further down.

@astrugatch Thanks for pointing us to JAMF as example for CA/cert management with clients. It’s been a while but I had this on my list of things to do/check and now I got to it.

JAMF can be setup to use different CAs/certs: https://docs.jamf.com/10.0.0/jamf-pro/administrator-guide/PKI_Certificates.html

That page led me to the so called Simple Certificate Enrollment Protocol (SCEP) which does handle some of the things that come with certificates. But the initial problem of establishing a CA trust is still the same - described in section 5.5:

Before any transaction begins, end entities have to get the CA (and possibly RA) certificate(s) first. Since the requester may have no CA certificates or CA public keys at all, this message can not be encrypted and the response must be authenticated by out-of-band means.
[…]
If the requester does not have a certificate path to a trusted CA certificate, this fingerprint may be used to verify the certificate, by some positive out-of-band means, such as a phone call.

Let’s assume the situation where the clients already trust the built-in self-signed FOG server certificate. We could use that to establish a trusted communication channel and send the new CA certificate to the clients and tell them to install and trust it. Definitely a possible route. But what about clients that are switched off at that moment? We would need allow clients to use both CA trusts over a period of time till all of them have moved to the new one. This is definitely possible but complex to implement and I wouldn’t find the time although I find it interesting and challenging.

Trying to digg a little deeper if and how JAMF has solved the above mentioned trust problem when moving from one CA to another I found those notes in the manual:

Note: By default, Jamf Pro uses the signing and CA certificates for the Jamf Pro built-in CA. You must replace these certificates with the ones for the external CA when you initially set up the integration.

and

Note: If you need to make changes to your organizational or third-party CA in Jamf Pro, it is recommended that you contact your Jamf account representative. Changes to the PKI could lead to re-enrolling the mobile devices in your environment.

Now let’s look at the other situation where no clients have been pinned to the FOG server yet. If you re-compile the client to check on a different name in the CA cert you can happily use external CA certs without an issue.

Thank you. I’ll look in to it.

@george1421 Fog is a waaaaaaayyyyyyyyyyy better fit than Zenworks at the moment, it images 4x faster and its more stable. Fog is actually working very well without these refinements that I want to do 🙂

@Tom-Elliott Ouch. I feel silly now. That was totally the issue. Thanks!

Your Fantastic! My system admin and I have been going through as many settings as we could find this week. The Dnsmasq solved it!

Please mark as read

@emryz @ragnurenson From my point of view it’s all working fine. See the screenshot below. You are right that the power management task is not in the scheduledTasks table. I was on the wrong track with that when I had a brief look at this last time. As mentioned by @emryz the power management tasks show up in the same view where you schedule those for the host. See my screenshot below.

@emryz I can imagine that some kind of AdBlock add-on in the browser could make this view disappear. We had a very strange case where one single text field was missing just because of an AdBlock add-on. Please disable these and see if it works for you.

Note: I corrected my other post so when people come along and find this, they don’t get confused.

laa.jpg

I need to deploy the image I created from the virtual machine (legacy) onto uefi is that possible or do I need to create another image?

@george1421 Okay so 19.1 seems to work great, on my desktop. The only thing I had to do different was change the permissions on the 19.1 folder since it locked it down to root but that was most likely from me running the terminal in “su” I’m guessing.

For some odd reason the laptop I’ve been using to test these does not want to boot it still and I am not sure why, it boots the Windows and Debian installers fine which is odd. It is plugged in with an ethernet cable the same as the desktop. I’m guessing this may have been giving me some of the issues in the past but I did double check on my desktop before posting and it was not going in my case.

I must be missing something in Mint 19 v2 but I’m not going to worry about it at this point since 19.1 is working great. I am doing the install right now and it so far is having no issues.

Thank you for all your help and if I figure out what the issue is with the laptop I’ll be sure to share in case anyone else happen to come across a similar issue.

Cheers
Ben

SOLVED
Thanks guys, once the certificates were copied to the fog2 server, AD join started working

Yay 🙂

@Sebastian-Roth yes, the esxi host has a NIC on each network. I am attempting to get the network to allow access to an single IP in the management for each lab so I can just use the 066 DHCP option to point to the interface that works for TFTP which I believe is the way the guys that are doing similar setups are making it work.