@xcess said in "Please enter tftp server:" with single dhcp server:

I’m using the built-in dhcp server on a ExtremeNetworks switch.

OK knowing this are your pxe booting computers on the same subnet as the FOG server? (while I need to know this…)

I would recommend you move away from the network switch providing the PXE boot information for your network. Can you probably make it work, maybe yes. Is there an easier way to go about it and make the pxe booting a bit more dynamic, yes. So the short answer is to install dnsmasq on your FOG server to provide pxe boot info only. The reset of the dhcp stuff will come from your main dhcp server.

If you want to use your switch dhcp sever only, then you must pick either bios or uefi system booting, because the dhcp options are static, so you have to pick one or the other. The problem why it didn’t work the first time is that because the {next-server} and {boot-file} entries were missing in the ethernet header. This is the bootp part of pxe booting where dhcp uses dhcp options 66 and 67. So in your network switch you need to turn on bootp as well as dhcp. Sometimes they are separate tasks and sometimes they are combined. Some clients will look at the ethernet header for boot info and others will use the dhcp options, that’s why both need to be filled out, or just use dnsmasq.

I have instructions on installing dnsmasq, it should take you about 10 minutes start to finish. If you have the pxe booting computers on a different subnet than the fog server, you will need to update you dhcp-relay service to include the fog server ip address.

@xcess said in "Please enter tftp server:" with single dhcp server:

Server host name not given
Boot file name not given

This will be a problem too. That should align up with dhcp options 66 and 67.

So now to the question, what is your dhcp server (mfg/model)?

@xcess said in "Please enter tftp server:" with single dhcp server:

DHCP Option Code 67 : string “tftp://192.168.xxx.xx/undionly.kpxe”

^^ This value is wrong ^^, just enter undionly.kpxe for bios based computers and ipxe.efi for uefi based computers.

@joyboy11111 Ok I think we need to regroup because we somehow have moved off course.

You are using the isc-dhcp dhcp server on your FOG server. So what I’m recommending is that you go into the configuration file for the isc-dhcp server and change the references from ipxe.efi to snponly.efi, then restart the isc-dhcp server.

I’m going to assume you are running debian/ubuntu variant so these instructions will help you: https://help.ubuntu.com/community/isc-dhcp-server

The fog installed configuration file for the isc-dhcp server looks similar to this: https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence#Example_1

OK so to my thoughts. The ipxe.efi boot loader is much like an operating system itself where it will have a hardware driver for every common model of network adapter. The snponly.efi boot loader is much like the undionly.kpxe bios boot loader in it only contains one network driver which speaks to the network driver built into the network card. The idea is that maybe there is a bug in the ipxe.efi boot loader driver for that nic, where the driver built into the network adapter would respond correctly.

There is something uniquely special about that network adapter to why it is reporting a different mac address for iPXE vs linux and windows.

@joyboy11111 OK so to answer my question, you use the FOG server as the dhcp server for your FOG imaging network. So you need to edit your dhcp server configuration file.

Replace these parameters filename "ipxe.efi" with filename "snponly.efi" then restart your dhcp server. Lets try the snponly.efi boot loader. Lets see if it finds the right mac address.

@joyboy11111 I don’t think you did anything wrong, just updating ipxe didn’t solve the problem.

So what device is your dhcp server?

@joyboy11111 The files are not zipped, you can directly download them using your computer and then transfer to the FOG server if you want to go that way too.

Or from the linux console

wget https://github.com/FOGProject/fogproject/raw/master/packages/tftp/undionly.kpxe

and
wget https://github.com/FOGProject/fogproject/raw/master/packages/tftp/ipxe.efi

@joyboy11111 I personnally think it would be quicker to just update the pxe boot file to see if that addresses the issue.

But it you want to update fog, it looks like you might have the git install files in that screen shot. So change into the fogproject directory then issue the following command git pull that should update the installer files. Then change into the bin directory and run ./installfog.sh script. It should remember the settings you made the last time you installed fog. The installer will stop half way through asking you to go to the website and update the database. Then don’t forget to go back to the linux console to finish the install.

@joyboy11111 said in HP Elitebook 840 G7:

60 6d 3c 79 b0 f4

OK we have correlation between linux and Windows. So the kernel at fault here is iPXE. Since you have and older install of FOG you probably have older versions of iPXE. Let me get the link so you can download 1.5.9’s version. Lets see if we replace iPXE we get the right mac address.

Edit OK lets grab ipxe.efi and undionly.kpxe from here: https://github.com/FOGProject/fogproject/tree/master/packages/tftp those files should replace the files by the same name in /tftpboot directory on the FOG server. Swap out the files, go in and tweak the mac address on the test host you created so it doesn’t match, then pxe boot into the fog ipxe menu see if its registered or not, we need to get iPXE mac address to match what windows and linux say.

I know there are hardware specific ipxe drivers too you might try. Also there is a generic driver for uefi (akin to undionly.kpxe) called snponly.efi. You might try that one too to see if we can get it to match the inventoried mac addresses.

I do have to say I have not seen this issue before. So this is unique.

@joyboy11111 said in HP Elitebook 840 G7:

6c:02:e0 mac company codes comes back to HP
60:64:3c comes back as invalid
Edit bifocals and sideways reading doesn’t give good answers.
60:6d:3c mac company code is Luxshare Precision Industry Company Limited

FYI the first 6 characters of the MAC identifies the nic manufacturer.

@joyboy11111 Sorry I just added this to a previous post:

Secondly if you take that usb nic to a windows computer and insert it, what MAC address does windows see? We need to figure out which kernel is giving us false information.

@joyboy11111 so does the mac address for enp55xxx match what inventory says or what iPXE is seeing (what you entered for the test system in fog?

Secondly if you take that usb nic to a windows computer and insert it, what MAC address does windows see? We need to figure out which kernel is giving us false information.

@joyboy11111 what about the ip a s command. That is kind of what I want to focus on immediately.

@joyboy11111 said in HP Elitebook 840 G7:

I did try to do a regular capture and it gave me a legit error. Could not mount because the disk contains a unclean file system. I assume just because of all the bios changes, power on and off I have just corrupted win 10 so badly it just needs to have a fresh copy of windows installed.

This is something you can fix. What happens with windows is shutdown is not actually a power off shutdown. In windows 10 term its actually an enhanced sleep mode which leave files open and the dirty bit set. So before a capture we recommend you do one of these things.

1. Let sysprep power off the computer after its done. sysprep will properly close open files for cloning.
2. Use shutdown -s -t 0 to power off the computer.
3. Disable fast startup, reboot then shutdown via the start menu.

NOW back to the issue at hand.

lets start with ip a s and post a screen shot of the error here

Then the lspci and lsusb output.

What we need to find is where is the mac address coming from that iPXE is reporting? Is there multiple network adapters? Is there some other kinds of monkey business going on?

@matthew73 This is a unique condition. I can understand what is going on because we use NAC and VLAN switching on my campus. I can say that I have not seen this issue (anywhere) on my campus.

I think I understand what needs to happen. Basically iPXE needs to say something and then wait XX seconds for your NAC system to identify the hardware and to switch it to the right vlan. The network link light winking happens 2 times during a normal pxe booting. The first time is when the PXE turns over control of the network adapter to iPXE and then when iPXE turns over control of the network adapter to FOS Linux. We see a similar issue when the network switches are using standard spanning tree and not one of the fast protocols (RSTP,MSTP, port-fast).

The developers have created a specific group of iPXE boot loaders that have an embedded 10 second delay before iPXE tries to request an IP address. This gives STP and powersaver functions on the switch a chance to react before iPXE starts to talk. These files are in the 10secdelay folder. So to use these update dhcp option from ipxe.efi to 10secdelay/ipxe.efi This will call in the 10 second delay boot loader. See if that makes things better or not.

@joyboy11111 said in HP Elitebook 840 G7:

. It captures the laptop SN and all the other data. I assigned an image to it, created a capture task, FOG wont capture it, just keeps bringing me to the host not registered.

Boy we always seem to get the difficult ones. So a little bit more on what is going on behind the screen. iPXE (undonly.kpxe or ipxe.efi) is picking the mac address of the network adapter that is pxe booting computer. That is reporting one mac address. This is the mac address you see on the screen in the ipxe menu when it says not registered. Record that mac address from the FOG iPXE screen. Now when FOS Linux starts (bzImage) and its seems to be detecting a different mac address (because inventory says one thing, and iPXE says something else).

I think I understand how this might be happening but not the why part.

So what I want you to do next is to take that mac address that is on the iPXE screen and manually register a test computer using that MAC address. Then deploy a debug capture task to that test computer. We may get some different error messages but I want to get to the FOS Linux command prompt to see if we can find out what is going on here (like there is 2 network adapters and iPXE is selecting the wrong one)

@birgit-godfrey said in Dell Latitude 5510 No network interface found! Kernel might not have the correct driver!:

Any reason why the newest version is back to 4.xx?

Yes there is a reason. The developers are sticking to a release strategy that stays in line with the linux kernel developers and the latest Long Term Support kernel. The latest linux kernel LTS release is 4.19.x. Realizing that new drivers are added to the “current” linux kernel releases the developers have released 5.6.18 where there was many new drivers added to linux 5.5.x series. The FOG developers were told that the next LTS kernel would be 5.10.x. When LTS has been set on 5.10.x the FOG Developers will release a new “current” release.

@joyboy11111 Interesting, in that this network adapter works with the G6 for imaging?

So we don’t head in too many directions all at once, follow my last post first.

I do have to say some of the newer Realtek 8152/8152 nics need a patch driver to work. I have this as a one off kernel, BUT lets not do too many things at once. If the official FOG kernels work we should stick with them because they have been tested and proven to work for most all hardware.

@joyboy11111 said in HP Elitebook 840 G7:

When I boot, FOG goes right passed the debug command (never loads) prompt and goes to the FOG menu of host is not registered, boot from hard disk etc. I took a video with my phone but it would not upload.

On a side note, I left the task active and booted a 840 G6 with the same dongle and, it came right into the debug screen

Rereading this makes me think a little differently now. If that same network adapter works in a G6 but note G7 then its not the kernel driver for the network adapter.

What I also find strange is that the network adapter has a different MAC address from the G6 to G7. On the G7 when you boot into the ipxe menu it should tell you the mac address iPXE sees on the screen. On some of the newer bios (uefi firmware) there is a mac address pass-through option. In this case it makes the usb adapter transparent to the target computer, where you get the mac address of the PC itself as if the network adapter was built into the G7 directly.

So with this new understanding, on the G7 go ahead and register that computer using the normal process. Then schedule a new task using the MAC address detected during the registration process. The system may be working as designed, just not as we might expect. It is actually working better than on the G6 because that makes the mac in the nic irrelevant.

@joyboy11111 ok just get me the windows hardware ID of this usb network adapter and I can trace it to the linux driver then.