@Noseman The tools used within FOS (FOG OS doing all the hard work when capturing and deploying) are no official Microsoft certified software products but from open source community. They work in 99% of cases but I can imagine there can be special states of the filesystem or certain edge cases those tools simply cannot handle (yet).

Great you found a workaround!

@wass Since all of the boot loaders you mentioned are bios boot loaders and you are seeing the no configuration methods succeeded it sounds like the computer is in bios mode. Its strange that iPXE and bios mode computers are not able to configure the interface. For bios the boot loaders undionly.kpxe or ipxe.kpxe should work on 99.8% of all computers. Does this computer have multiple nic cards?

@kamburta Pretty sure this is known and fixed in the dev-branch versions of the FOG repository.

@repier89 Nice you got that external NIC adapter to try and see if it’s a network issue or now. And yes, we have a winner. 😉

Please schedule a debug deploy task for the HP Probook 450 G9 and boot into it. Run lspci -nn | grep -i net and post output here.

@Sebastian-Roth @rodluz

Thanks so much for the info, guys!

@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