DHCP FAILED

[jeremyvdv]

I disabled the TPM in the bios but here is the problem I have now

[jeremyvdv]

my capture is in court it’s good.

It was necessary to disable the hibernation of the hard disk.

I still have the problem on my hp for DHCP FAILED

IF you have ideas … I test everything in bios

[Sebastian Roth]

@jeremyvdv said in DHCP FAILED:

I still have the problem on my hp for DHCP FAILED

What do you mean by that? We see that you get past the DHCP stuff und ran into other issues. So does the DHCP fail only on random occation??

[jeremyvdv]

Hello

When I want to capture from an HP post, I always have this message:

I can decend an image on it but not capture

Thanks for your help

[george1421]

@jeremyvdv OK for the HP lets take these steps.

1. Cancel any current tasks if imaging is still setup.
2. Create a new capture task, but before you hit the schedule task button tick the debug checkbox. Then schedule the task.
3. PXE boot the target computer like you are going to image it.
4. After several screens of text on the target computer that you must clear by pressing enter key, you will be dropped to the FOS Linux command prompt. You may see the error messages again from your last picture but the system will continue to the command prompt.
5. Key in the following and post the output picture here.
   lspci -nn | grep -i net
6. Remain in this debug mode because there maybe additional commands based on the answer provided in the picture.

What this command does is print out all of the network interfaces that the HP has onboard. It will also give us the vendor and model numbers of the network adapter. We can then use those numbers for debugging.

[jeremyvdv]

Thank you for your reply.

I can not do “|” keyboard .

I tried lots of things … an idea?
thank you

[george1421]

@jeremyvdv said in DHCP FAILED:

I can not do “|” keyboard .

What language keyboard do you have? The pipe symbol ( | ) is kind of a required key for unix.

If you can’t get the pipe symbol then just run the lspci -nn and hope we get luck that the network adapter is towards the end of the list.

[jeremyvdv]

that’s what I get with this command:

[george1421]

@jeremyvdv Luckily the answer I was looking for is the realtek ethernet adapter [10ec:5227] RTS5227 PCI Express Card

So now we know what we are looking for. Let me check a few things.

I see the version of the FOS Linux kernel is 4.19.0 (a bit strange for having 1.5.7 installed. But let me look up some things.

Edit: Ugh, RTS5227 PCI Express Card is not the nic adapter, that’s a card reader, which is wrong… The correct card is the intel I218LM [8086:15a2] that should have been supported by the linux kernel since 4.12.0. Very strange.

[jeremyvdv]

Great if you have any info
i do not understand … what do you want as information

[george1421]

@jeremyvdv said in DHCP FAILED:

Great if you have any info
i do not understand … what do you want as information

Ok so the target computer should be sitting at the FOS Linux command prompt at the moment. Post the output of this command ip addr show Make sure the network adapter is plugged into the ethernet cable then issue the command. After issuing the ip addr show command issue uname -a Post both answers to this thread.

[jeremyvdv]

this is what I have:

[george1421]

@jeremyvdv Ok from the picture the network adapter appears to be UP as well as we can see a link light. I can see the driver is loaded and is talking to the card because we have a mac address.

At the FOS Linux command prompt lets key in this /sbin/udhcpc -i enp0s25 --now and see if we can pick up an IP address now.

[jeremyvdv]

That’s it

[Sebastian Roth]

@george1421 @jeremyvdv Probably a spanning tree issue?!

[jeremyvdv]

how to explain that works on a Spanning TREE problem?

[Tom Elliott]

@jeremyvdv Spanning tree enables the ports to wait for a period of time between link up/link down before the switch will pass the information to the machine in case there’s a link connected back to itself on the switch.

This up/down time can be around 27 seconds in normal Spanning tree mode. This would explain why during the automated portion the device cannot get a link or IP, but once at the terminal and restarting the networking it will pick it up.

If your network is using spanning tree, if you can do so, disable it, or if not it’s best to use one of the Fast/Rapid stp methodologies as their up/down time is much more significantly reduced.

[jeremyvdv]

do you want to find out by
“or if not it’s best to use one of the Fast/Rapid stp methodologies as their up/down time is much more significantly reduced.”

Thanks

[george1421]

@jeremyvdv said in DHCP FAILED:

That’s it

This is what I wanted to see, to see if TIME fixed the problem. As the others have said its probably a spanning tree issue. Check with your network infrastructure people to see if they can turn on one of the fast spanning tree protocols on your network switches.

Another test would be to place a dumb (umanaged cheap switch) between the building switch and the target computer. If the system boots and imaging fine then its surely is either spanning tree or green ethernet settings causing the problem.

I do find it strange that if it is spanning tree, why didn’t the dell have the same problem? Is the dell possibly plugged into a different network switch?

[jeremyvdv]

No The dell is on the same switch.

That’s why I have a doubt about the idea of ​​the spanning tree.

And I’m pretty sure the spanning tree is off