@Almeida I suggest you update to 1.5.10 or at least manually update the FOS kernel.

@KaiHerlemann Yes, @JJ-Fullmer is right there. The installer is not made to handle custom certificates properly yet. We never found the time to make this work reliably. But if you are good with managing this yourself you can still do it.

The whole topic is a bit complex due to the different tools and layers involved.

Basic web access to the web UI - just adjust Apache config as you like But along with that the iPXE boot loader is using HTTP/HTTPS to load the menu items. So if you switch to HTTPS you also need to compile your own iPXE binaries - not very hard: https://docs.fogproject.org/en/latest/development/fog-release/#ipxe (but use ./buildipxe.sh /path/to/your/CAcert.pem and skip the armsupport=1 if you don’t have ARM CPUs) Now this was the easy part. I started to write about the fog-client here but then realized I did so in the wiki already: https://wiki.fogproject.org/wiki/index.php?title=HTTPS#Custom_CA_and_certificates

I know, this is not ideal having to stich together the pieces from various sources and make up the rest yourself. So if you are keen we would appreciate if you document exactly what you do and we’ll add it to the official documents. That would be really great!

@KaiHerlemann said:

Usually we use ACME to create certificates.

I would not setup a FOG server open to the public. There are ways to get certificates through ACME without facing it to the web, e.g. opening ports only for the time of cert renewal on the firewall, doing cert renewal on a separate machine and copy those over and so on. Please consider wisely because FOG is not made to run on a public IP/hostname safely.

@JJ-Fullmer said:

I would suggest at install time NOT selecting ssl and then altering the config to use your custom certificate.

In the one hand I agree. Doing it this way you can go step by step. On the other hand if you do a fresh install (don’t if you have a running server) then I tend to suggest you enable SSL straight away because it will generate a SSL enabled Apache config for you and save you some time.

thanks @Tom-Elliott

worked for me in the fog.deployimage option
like this
params
param mac0 ${net0/mac}
param arch ${arch}
set username myuser
set password mypassword
param username ${username}
param password ${password}
param qihost 1
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme

The Problem with my previous approach was i tried do set this in one line
like

params
param mac0 ${net0/mac}
param arch ${arch}
param set username myuser
param set password mypassword
param qihost 1
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme

make obviously no sense when i look at it now 😉

@LLamaPie Thanks for testing and letting me know.

@JJ-Fullmer I think I have determined this is a problem in an internal process with the api. Gonna try to narrow it down some more.

@Richarizard504 Then I may suggest you provide the full fog.log file from that client having the issue. We might find out what’s wrong with some more context.

@CedricoR @lebrun78 Check out this topic, seems to be related: https://forums.fogproject.org/topic/16859/rhel-initramfs-unpacking-failed-kernel-panic-not-syncing

@WT_101 As I mentioned, FOG doesn’t support imaging over wifi. The first roadblock that you will hit is iPXE because it needs the drivers and then your wifi settings to connect to. The second issue you will have is with FOS Linux, none of the wifi drivers are added into the kernel, nor is any of the wifi utilities compiled into the initrd file system. You would be better served with a usb ethernet adapter.

@mattah_18 Is fast boot disabled on this machine? How do you shutdown the machine before capture?

@pacodijou You likely need to rethink how FOG operates.

The fact that you got into FOS itself (which is where you’re at) at least shows DHCP is working and passing the Options 66/67 appropriately, but it’s failing to get access to the fog server.

Based on what I can see, the DHCP items are working properly, assuming 192.168.75.10 is the fog server since that’s also where it’s trying to connect to look for access directly to the fog server.

Do you access the fog server at url:
http://192.168.75.10/fog/index.php?

@capitald Let’s take a step back. Before we get into this any further we need to think about the whole connection between fog-client and the FOG server. The fog-client wouldn’t get as far as loading a snapin if there was a general problem with the SSL certs and trust.

So is must be very specific some issue at this stage. So you use the location plugin? Were both nodes setup with HTTPS (which is not the same encryption layer we are looking at here)?

it appears to have fixed itself, i tried again on a whim today and im no longer having issues with the locations plugin. sooo problem solved i guess.

@zuchowra This often happens because of either the DHCP server isn’t presenting boot options, but more often it’s because you ahve multiple things responding with what server should be used. The system has no idea which one to use, so it requests you manually enter it.

Please check your dhcp server to ensure the boot option is sending option 66/boot server name

@AlexPDX @Sebastian-Roth it was something simple in the end

BIOS > advanced > system options

i turned off/unticked - configure storage controller for VMD

basically its there version of RAID, untick it and its AHCI

@Wayne-Workman Hi Wayne, that was it - reb

Going to mark this as solve, my pc PS gave up the smoke and it killed the Drive so i lost my images.

Thanks for the help

@AlkarimJ You would likely want to set the primary disk to /dev/sda

It looks, at least from the image you provided, that it may be the nvme0n1p1-5 you have on “successful” machines may be 1TB (or at least large enough) to contain the raw image, but on the new machines these drives are smaller than the expected.

@robertkwild said in updating fog on centos 7:

it took ages compiling the ipxe binarys but now its been succesfully updated

THat’s right. Usually takes a few minutes depending on the CPU you have.

@danibashkov said in Exec format error during network boot:

Could not boot image: Exec format error (http://ipxe.org/2e008001).

Most likely the kernel image is missing or corrupt. Please check using the following command: file /var/www/{html/,}fog/service/ipxe/bzImage

As well I may ask how your DHCP server is being setup? Did you say yes for FOG to install and setup DHCP for you on the FOG server or do you manage your own DHCP server in the network? Just asking because possibly this might be a 32/64bit issue as well.