@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.

@george1421 Once again sir, you are a legend. Fixed 🙂

@tacOS updated main post, turning off notifications on this post.

@Warsonix Great you figured out how to switch to a different iPXE binary. You are welcome. Feel free to ask whatever issue you run into in a new topic.

@Can-eh-dian11 said in Kernel Panic - Unable to mount root fs on unknown-block:

As suggested I gradually brought the FOG server and the clients closer together until eventually they were on the same switch/subnet and I’m still encountering the error.

Good work! Although we have not found the root cause of this we did rule out a very important factor.

We’ve also done some more deployments and have found that the issue isn’t as limited to a specific hardware vendor as we initially thought. There have been some recent Dell laptops where we are starting to see this pop up.

So from what we know so far I would guess this is a driver issue in iPXE. Do all the devices showing this issue have the same or a similar network chip (same vendor)?

Try using a different iPXE binary. Which one do you currently use? Are the devices set to UEFI or legacy BIOS mode?