Thanks for at least understanding. I wonder if some of the similar types of issues we’ve seen historically have a similar style of problem that I’m only coming to realize now-a-days.

I have a problem.
When I try to deploy a Win10 image on motherboards with a B760M chipset, the network card freezes and the ping completely disappears. The green light on the network card stays on constantly. The only way to fix it is to unplug the power supply from the outlet and discharge the battery by holding down the power button.

Does anyone know what might be causing this and how to fix it?

Thank you!

Generally if you’re able to pxe boot though, it should find the adapter within pxe. It could be a case of it being too “new” an adapter that requires a different driver not in ipxe. In that case though, I would try using snponly.efi as it may have different behavior with less things loaded in the pxe side. It may also be a driver or setting needed in ipxe that could be handled in a custom compile of ipxe, there’s some info on that here https://docs.fogproject.org/en/latest/compile_ipxe_binaries

It’s also possible to use a tool such as rEFInd to get to a uefi cli console. If you load the ipxe.efi and or snponly.efi and then if you can obtain them the efi driver for the adapter you can do a fs0: to enter the usb disk (it may be fs1: or fs2: you gotta ls on each disk to find the right one) then load usb-network-driver.efi then ipxe.efi to ensure the usb network driver is loaded in the efi for that session and then boot direct to the pxe file which will start the fog network boot. It’s a bit of a hassle but it usually works for me when all else fails. I have an old startech usb 2 ethernet adapter I do this with. This has worked universally but it’s not an ideal solution, but can be poc that it can be done on any device.

I hope my rant was helpful.

have tried both SAN and GRUB exit options

boot loader == snponly.efi

These are in contradiction with each other. SAN boot and Grub are bios boot methods. snponly.efi is a uefi boot loader. Since you are getting into the fog iPXE menu we can assume the hardware IS uefi based since it is booting snp.efi. Try a uefi exit mode of rEFInd (refind) to see if that will boot from the hard drive. The default value can be set globally in the fog configuration->fog settings page. Don’t force a bios attempted boot from a uefi booted computer, that never works.

I boot with a USB-C network adapter on an HP Elitebook. It finds FOG, I have the menu, I choose to deploy an image, and then I get this error message:

IMG_20251106_162705.jpg

Is this the problem in question?
If so, what exactly should I do? I see (link @FlorianLenz ) that I need to replace two files with the new ones, then run the .sh. But isn’t that dangerous for other network boots?

Thank you in advance for your help.

thank you for your great answer. You are completely right, it is a 17-x104ng, not a fg. It was an error of me 🙂

The needed hardware id is VEN_10EC&DEV_8136

Hope that helps

Thx,
mchristo

Hello!

Do you have Secure Boot enabled?

I worked with this Dell Machine about 6 months ago and don’t have it with me now.

So here it goes.

Otherwise, check what bzImage files you are using. The bzImage files have the linux kernel drivers which I think I used the latest stable ones I could find. These are placed in /var./www/html/fog/service/ipxe

There are 4 files in there which need to be there
bzImage
bzImage32
init.zx
init_32.zx

Or others depending on what CPU architecture your machines use. These are available on the following URL
https://github.com/FOGProject/fos/releases

I found that some work better than others as the FOG project is maintaining their FOS releases and adding computers. It is possible that one you are using simply does not have the drivers for the PC you are using. I would back up these files before updating these to ensure your older machines can PXE when updating your FOS (fog OS).

Matt

I have a vsphere server with my W11 VM that I use to build my images. The Fog server is currently 1.5.10.1673. The previous fog server was on a centos box so I just rebuilt one from scratch using ubuntu. There were no issues on the old version ( I cant recall what it was).

My W11 machine now crashes as it loads ipxe. Is there a way to go back to an older ipxe file to test?

Thanks

I just recompiled the linux 6.6.85 for a 586 based CPU. I can recompile for a 486, but I don’t know if that is going to get us anything better.

Here is 6.6.85 586 version
https://drive.google.com/file/d/1GAzFjbtpDVXXCRpe6bIZ5mwySSXeDHko/view?usp=drive_link

Here is 6.6.85 586 where I stripped out some drivers like scsi, nvme, uncommon network drivers, virtualization drivers, etc. I was able to strip out over 1MB of kernel size from the previous one above. Did I through out too much?? YMMV.
https://drive.google.com/file/d/13dE7BLgofsFiNJj_Q8nLDknplRbWRqkJ/view?usp=drive_link

OK lets see if we can boot from a usb drive. This tutorial will instruct you on how to build a usb boot image. https://forums.fogproject.org/post/69606 the google drive link below will take you to step 7 in the thread.

https://drive.google.com/file/d/1psCrPVzBTvlakLkCMvhdoScAEZp1CKE6/view?usp=drive_link

Once you build the usb boot drive, take the kernel and init.xz from your current version of fog and replace the ones on the flash drive with the ones in from the FOG server. The files are in /var/www/html/fog/service/ipxe directory.

Once you have the usb drive ready, pxe boot into the grub menu on the flash drive, then go into debug mode. After several pages of text you need to clear with the enter key you will be dropped at a fos linux command prompt. If you can get that far then fos linux is OK and the problem is probably with ipxe or the handoff between the two.

If you want to image with the flash drive, schedule the task in the fog server BEFORE you usb boot and select option 1 from the menu. If you get it out of sequence you will get an error that says something about Null. Basically its saying you don’t have a task scheduled on the fog server so there is nothing to do. Lets see if we can get it to boot this way.

I used the top configuration ideas from Wilsol, and before I could get through the entire list, darned thing started working. (yeah probably secure boot, thanks Tom for pointing us in the right direction)

Thanks to everyone for the assist.

-Jim

@jflash Great! Did you use the default kernel from FOG after the update, or did you use the kernel from my repo?

I don’t try older kernel, just put new one 🙂

One comment before I get too deep into this, if you use for your dhcp server either WIndows 2016 or later or linux as your dhcp server, you can setup profiles with your dhcp server to automatically send the right ipxe boot loader based on the pxe booting computer. You won’t need to mess with the ipxe.efi files like you have. You can surely continue to do it that way, I just wanted to let you know there might be an easier way to go about it.

So you are able to pxe boot into the iPXE boot loader, as soon as you pick a menu option that is where the wheels come off, so to say. Looking at the screen shot the process is failing at the handoff between ipxe and FOS Linux (arm_Image+arm_init). Its hard to tell if its ipxe or fos linux at fault.

I have a process to create a debug usb image for x64, but I haven’t tried to create one for arm. In theory if you have a working Jetson Orin running ubuntu you should be able to follow this to create a FOS linux usb boot image: https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image In your case you don’t want to use bzImage and init.xy but use the arm_Imag… (to replace bzImage) and arm_init (to replace init.xz). The idea here is to see if you can select register from the grub menu to get FOS Linux to boot on the jetson nx. If it can then the issue is with ipxe. If it doesn’t hopefully you can debug with the usb boot image.

You may need to build a custom linux kernel for the Jetson. Just for reference https://docs.nvidia.com/jetson/archives/r36.3/DeveloperGuide/SD/Kernel/KernelCustomization.html

If in linux then use lspci -nn to get the device IDs. They will be 2 sets of 4 character hex numbers within the square brackets separated by a colon. i.e. [8086:1b4e].

With that code we can see if there are standard linux kernel drivers for this network adapter.

Bad news, we haven’t really had much time to troubleshoot against all potential arm devices and I believe this is a semi-known issue that we just haven’t been able to narrow down and/or fix at this point.

If you’re able, can you try loading a 6.1.22 arm kernel or maybe 6.1.89?

I suspect, and it’s just a sneaking suspicion, what you’re seeing is similar to the issue we’re seeing with hyper-v/proxmox and efi loading.

Anyway new firmware 1.21 now working.

@george1421 said in iPXE "Boot from hard disk" not working with RAID.:

Why refind is working is it is configured to find “windows” and boot it out of the box.

I tried configuring refind to boot grub and it partially works.
Grub shows and I can boot windows from it, but when booting Ubuntu Server I get error: failed to install protocols even though I manually installed grub with --disable-shim-lock and disabled secure boot.
Looks like it’s not secure boot related, but more like driver issue and I probably should try that iPXE chain load thing.

@george1421 said in iPXE "Boot from hard disk" not working with RAID.:

What you need is for iPXE to chain load grub.efi from the first partition so that the grub menu starts up correctly so you can dual boot.
I guess that I need to modify default.ipxe?
Could you direct me?