@jj-fullmer It looks like it should be working I now see the carrier detect that was missing previously without the firmware installed. Did an ip a s show an ip address?

@jj-fullmer The other thread referenced new hardware IDs. I did not change that on the updated kernels. Hopefully those numbers will be in there. I think so because the picture said it was working just couldn’t load the firmware.

@jj-fullmer Sorry I was having fun playing with the flash compiler at work.

Here is the updated bzImage5618RT3 with the firmware it was missing from the previous image [rtl_nic/rtl8153a-3.fw] : https://drive.google.com/file/d/1vSu5L-DAZYK7VYiJtFfCYrrqJb963cMg/view?usp=sharing

Here is the 5.9.3 version with the updated firmware bzImage593RT3 https://drive.google.com/file/d/1O-4tvx4DywWef75qfSxLRK9M6CoDS9pd/view?usp=sharing

For your case the 5.9.3 version has no advantage over 5.6.18. The 5.9.3 does have a few new network adapters and some in the 10Gb and 40Gb range. Also realtek 8125 2Gb nic.

@jj-fullmer sorry I had an update “Duh, and blind. It is missing a hardware driver. SO this last images was that from the one-off kernel or from the FOG standard kernel?”

@jj-fullmer Interesting that this computer has an intel ethernet nic in it.

Duh, and blind. It is missing a hardware driver. SO this last images was that from the one-off kernel or from the FOG standard kernel?

@colossalfalafel No that’s fine. My question was more focused on have you ever pxe booted a uefi system before.

ok now the fun part (maybe). Lets grab a pcap of the pxe booting process. https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

This will let us evesdrop on the pxe booting process using the FOG server. Upload the pcap to a file share site and either DM me the link or post it in this thread and I will take a look at it.

@colossalfalafel The older dells are also uefi mode? (sorry have to ask so I can build a picture of the setup in my mind)

@jj-fullmer I wonder if there is nic card firmware missing. This is telling me its now loading and talking to the network adapter, its having a problem fully communicating with it. When you have time boot into debug mode and then search /var/logs/syslog for that network adapter and see if there are any hints in there to why its not happy.

@bluedude For a longer term solution I would implement the dhcp policies from the document Sebastian provided. That solution will help you when you have a mix of bios and uefi systems on your campus.

BUT for a test right now, replace undionly.kpxe with snponly.efi then try to pxe boot that troubled target computer. Understand when you move away from the bios boot loader the bios systems will fail to pxe boot. But what we are looking at right now is/does snponly.efi resolve uefi booting on this troubled computer. Once you find out then put back the undionly.kpxe file until you can get the dhcp policies setup. I can tell you they do work because I have them setup in my environment.

@colossalfalafel So just to be clear you can put another system of the same model or a different model and it pxe boots into the iPXE menu just fine?

Is the fog server on the same IP subnet as this 5510?

@will Well the issue is on the target computer side. If the ssd was always disk 0 then it would be easy because in the host definition you could say to deploy the image to /dev/sda but the issue comes when there is two hard drives which one is detected first. The first detected (sata) hard drive is /dev/sda and the second detected hard drive is /dev/sdb This most of the time corresponds to which sata cable is connect to the drive. The cable for drive0 is usually detected as /dev/sda and the cable for drive1 is usually detected as /dev/sdb but only when there is a drive connected to the drive0 cable.

So can you have fog image properly, sure. You just need to tell it on a host by host basis when the ssd is connected to any other cable than the one for drive0.

@jj-fullmer Ok I looked and the realtek driver has been in the linux kernel for a while (sorry just closed the page and don’t remember). That is also a very old driver in the official linux kernel. I patched a one off kernel with the updated realtek driver for the 8125 adapter.

https://drive.google.com/file/d/1zcQvZNkick_Q4DyHKL9_X8dSXHjkN_BD/view?usp=sharing

Download this and save as bzImage5618RT into /var/www/html/fog/service/ipxe directory. Then update the host definition to use this kernel (or just change the global kernel from bzImage to bzImage5618RT. It is the same kernel as the official FOG kernel except I’ve patched the kernel with the updated realtek drivers.

ref: https://cateee.net/lkddb/web-lkddb/USB_RTL8152.html

@bluedude Issues before the FOG iPXE menu are related to the pxe bootloader program (undionly.kpxe and ipxe.efi). After you pick a menu item and see bzImage and init.xz then if you have problems its with FOS Linux (a.k.a “kernel”). I skimmed this thread and it looks like you are having issues with the pxe boot loader.

Without going too deep in the innerworking of pxe booting. The bios boot loader undionly.kpxe only has one network driver in it. That is the undi driver. Almost all bios based network adapter has a rom chip on it and it contains the undi specific driver for its hardware. This undi driver is written by the hardware manufacturer and provides a common interface for the operating system (undionly.kpxe in this example).

Now on the uefi side, FOG is using ipxe.efi. This specific boot loader has network drivers built in for most all network adapters. Where undionly.kpxe only has one network driver built in, ipxe.efi might have 100. Its possible that ipxe.efi doesn’t have the specific network driver for your NIC adapter. UEFI also has something similar to the bios undi driver its called snp. So what Sebastian is asking you to test is to swap out the ipxe.efi (all network drivers) for the snponly.efi driver that only contains the snp interface hoping that the snp driver built into the network adapter will work better.

@bluedude said in New Lenovo M75s don't Connect to FOG:

So to configure with snponly.efi how do I do that?

This would replace ipxe.efi in your dhcp option 67 or if you are using dnsmasq or isc-dhcp server that would be done in the configuration file on the FOG server.

@jj-fullmer From a windows computer will you give me the vendor and hardware ID of that network adapter? I’ll look up to see if that driver is in the FOG kernel.

@epsilon52 First let me say that I 100% agree with Sebastian, but I also know a secret for the Dells.

Using the Dell CCTK (Command and configure tool) you can instruct the bios to pxe boot on the next boot up. This is totally outside the scope of FOG and not something that FOG is capable of, but the cctk tool has the ability to update/change bios settings from inside windows. So using that thought one could create a snapin (FOG deployable program) to run the preinstalled cctk command with the proper parameters to pxe boot on the next reboot only then instruct the computer to reboot. You would deploy that task after you have created an imaging task. I have not personally do this on my campus because I have other rules, but it should be totally possible with snapins and the fog client (I don’t use either in my environment).

As I said before I require the Imaging Tech to sit in front of the computer being imaged so they are 100% certain on what computer they are imaging. Because once in the past with the fully automated process we had an Imaging Tech pick the wrong computer and reimaged (i.e. erased) a VIP’s computer.

@epsilon52 said in I think i may be just dumb:

im not sure this will be a good fix as i belive it is going to boot the ipxe menues every time the computer is started now.

Ah ok, lets circle back to the title of this thread.

You can only get into the iPXE menu IF you pxe boot the computer. Without pxe booting it will ALWAYS boot into windows. The computer is doing exactly what you are telling it to do, but alas not what you want it to do.

FWIW, I have the hard drive set first in the boot order. I require the Imaging Tech to sit in front of the computer to be imaged and use the F12 boot manager to select PXE boot for imaging. You press the F12 key to get the boot manager just after the computer powers up and before it starts loading windows. From the boot manager you can pick network boot under uefi. That way after imaging the computer boots right into windows. The boot order never needs to be touched.

@epsilon52 Its not displaying any error message and in the bios you have the network adapter setup as the first boot item?

You don’t see an error about NBF or anything like that?

Is the FOG server on the same subnet as the pxe booting computer? There has to be something missing from your environment. It should boot.

@flareimp said in Add Full Inventory Task to PXE Menu:

can’t we do something similar to that with hosts that are already registered? I do remember back in the Fog .32 days it was possible.

This was my initial thought as the inventory was driven by the client computer. But as we just confirmed this is no longer the case with FOG 1.5.9. With 1.5.9 a task has to be running on the fog server to start the inventory process.

Does your environment use the FOG Client? If so that should also perform an inventory on some interval.

@flareimp So it looks like this route isn’t possible to perform an immediate inventory since a task needs to be deployed on the FOG server. This appears to not be target computer driven. Sorry I should have tested it in my lab first. I know when you run a registration from the iPXE menu it also sends an inventory to the FOG server and that is target computer driven.