Wrong interface for host registration
-
Hi,
I am trying to build a Fog server, i installed it on Ubuntu server 20.04. I did an online installation so i got the 1.5.9-RC2.
I am making test on an old laptop Lenovo E530. My DHCP is a Windows 2016 Server Std.Now i can have the Fog menu (i had to put on option 67 : “realtek.kpxe”), i want to register that laptop so i choose “Full host registration and inventory”, the DHCP fail, and i dont know where that come from, it try to start Interface enp12s0 … i dont have any enp12s0 interface on my ubuntu and fog server, it’s enp7s1, so it cannot reach the http fog, for registration.
If someone can help me, thanks.
-
I think you may be confused on network interfaces and what system is running at the time there is a problem. (understand I’m not saying there isn’t a problem).
On your FOG server using 20.04 that is fine. For this problem you can exclude that server from the problem.
The specialty bootloader “realtek.kpxe” is only used to load and display the FOG iPXE menu. If you can see the FOG iPXE menu then this bootloader and be excluded from the problem. Just be aware that realtek.kpxe is a BIOS based boot loader. If you have a uefi based system you will need to send the ipxe.efi boot loader.
Now once you select registration/imaging/compatibility testing a high performance linux OS is transferred to the target computer that actually does the work. This OS is called FOS (Fog Operating System). This FOS Linux OS is where I think you are getting enp12s0 mixed with enp7s1 interface names.
So if I understand the problem, FOS Linux is not able to get an IP address? Can you post a clear screen shot of the error taken with a mobile phone?
-
Hi, thank you for all explanations.
I used “undionly.kpxe” as the installation documentation said, but i got “no configuration methods” error.
I changed it for “intel.kpxe” as i saw on a blog for Lenovo error, but i got DHCP fail without “no configuration methods”.
With “realtek.kpxe” i have the menu.Here is some screenshots i took.
-
@Julien-asv Ok I want you to go through this process.
- Manually register this target computer in the FOG Web UI.
- Schedule a capture/deployment (don’t care we won’t get that far), but before you hit the schedule task button tick the debug checkbox.
- PXE boot the target computer, it will boot into debug mode.
- After a few screens of text that you will need to clear with the enter key you will be dropped to the FOS Linux command prompt.
- At the fos linux command prompt key in the following and grab a screen shot.
ip addr show
lspci -nn | grep -i netAfter you grab that screen shot (we need to make sure its longer than 30 seconds after you got to the command prompt), key in these commands.
/sbin/udhcpc -i enp12s0 --now
ip addr showSee if it picks up an IP address. See if time heals what is broken.
-
1 - done
2 - done
3 - I installed the client on the laptop, i thought it will reboot automatically the computer but no. I had to reboot manually and select lan boot on bios boot menu. normal ?
4,5- Here is the screenshots
I am not sur to anderstand the 30sc …
-
@Julien-asv Ok in regards to your pictures. The first one the network interface doesn’t have an IP address, but in the second picture it did detect and load an IP address. So time fixed the issue.
The 30 seconds part. What is typically the issue when time fixes the problem is that on your network/building switch you have spanning tree enabled, but you are not using one of the fast spanning tree protocols like RSTP, MSTP, port-fast or what ever your switch vendor calls it. Another test to confirm if its a spanning tree issue is to place a dumb (read really cheap switch) between the building switch and the pxe booting computer. If this solves your issue without having to enter debug mode then its a spanning tree problem.
The basic explanation is this. Standard spanning tree will listen for a loop back packet (BPDU) for 27 seconds before forwarding data. That 27 second counter is reset every time the link light comes on. That link light will “wink” 2 times during the imaging process. Once as iPXE takes over to create the iPXE menu and the second time is when FOS Linux takes over the network port. The problem comes that the target computers boots into FOS Linux so fast (~15 seconds) so by the time spanning tree starts forwarding data on the network cable FOS Linux has already given up and presents the error you posted.
-
@george1421 Hi, Thank you for your complete and interesting feedback.
I think you are right, but i cannot be sure yet at 100% because i am not the network guy of my office, and i don’t really have … one. it’s more an external company followed by the network administrator (who never do network jobs), … it’s complicate this day’s.
I should be able to fix that network issue (by the way we have full of Cisco 2950, 3750, etc), but not yet, i don’t have the hand of Cisco switchs.In the meantime i will follow your tip with a “simple” switch, i tried it this afternoon and it’s working, it maybe will fix my 1st issue with “undionly.kpxe”. I tried to boot a Lenovo M73e in a computers room, and it failed with “no configuration methods”, but with a “simple” switch i was able to boot completly and make an auto registration to FOG Server. I did the same with the Lenovo Laptop and it worked too.
Next week i will try to make images of a windows 7 computers, a Windows 10, import a computers room and deploy somes softwares, i should be ok, the FOG server look good. Just need to anderstand how FOG works
Thank you.
-
@Julien-asv I’m glad you have a working path. Yes you will need to get in contact with your network admins to enable port-fast on every network port that you need to pxe boot from. This is a common error when people leave the default settings enabled on their network switches. So we have seen it before that is why I had you try the “time fixed it” path for debugging.
