dhcp issue - Lenovo E73 - Realtek RTL8111GN
-
Sorry about the screen issue. I just calibrated it and ran command again, This time it returned with “1”
-
@pdit Ok, now we know that our link state check in the startup scripts is indeed working as well for your network card. So question remains, why does it take more than 35 seconds after boot up to change its link state to UP?
Sure we can adjust the wait time for you but I suspect this time to be caused by either spanning tree or energy efficency settings on your switch.
You said that you have an isolated setup with a dumb switch. Which switch model exactly are you using??
-
I use following 2 switches. I get same problem in both. but when same switches are used with in network fog server there is no problem. it only happens with one particular desktop and in isolated setup only.
https://www.linksys.com/us/p/P-LGS108P/
https://www.amazon.com/KEEBOX-SGE05-1000Mbps-Gigabit-Ethernet/dp/B004FM58MO/ref=sr_1_fkmrnull_2?crid=3C2KC43XR3UPQ&keywords=keebox+switch&qid=1556297026&s=gateway&sprefix=keebox+%2Caps%2C192&sr=8-2-fkmrnull -
-
@pdit Try those inits: https://fogproject.org/inits/delay/init.xz and https://fogproject.org/inits/delay/init_32.xz (both have the timeout increased from 35 to 120 seconds - let’s see if that works for you)
-
Please provide instructions how to do this.
-
mv /var/www/fog/service/ipxe/init{,_orig_26-APR-19}.xz mv /var/www/fog/service/ipxe/init_32{,_orig_26-APR-19}.xz wget -O /var/www/fog/service/ipxe/init.xz --no-check-certificate https://fogproject.org/inits/delay/init.xz wget -O /var/www/fog/service/ipxe/init_32.xz --no-check-certificate https://fogproject.org/inits/delay/init_32.xz -
i have updated inits and tried to PX boot again but it made no difference. now it says 120 seconds instead of 35.
-
@pdit Really strange. Why would it detect the link properly after you get to the shell? Can you possibly connect your client directly to the FOG server just for a quick test? Just to get those switches out of the equation for the moment?
-
“no link detected on eth0” which port is it talking about ? Fog server or the desktop that is being imaged/captured ?
-
@pdit Well if you connected those directly, then I would assume both don’t have a link.
In the old days there were cross over cables for connecting PCs/server directly without switch. But that was 15 years ago. Do you see a link up LED on the server or desktop when both are connected to each other and switched on??
-
It does same thing even if they are connected directly. But my question was about "eth0’ which fails to come up. which port is this ?
Also would you mind explaining me the process that is going on right from pxe booting until the computer starts being imaged or captured ?
-
@pdit Linux usually names the first (Ethernet) network interface
eth0. As we see when doing a debugging session the interface comes up later on and it just seems to take hell of a lot of time. I have no idea why. Suppose this is some kind of driver issue with this particular model.Can you do me a favor? We should see the same effect when you boot any kind of Live Linux system. Download and boot Ubuntu Live DVD for example and see if it can bring up the network in the first 120 seconds of booting.
You can find some information on the boot process here: https://wiki.fogproject.org/wiki/index.php?title=Booting_into_FOG_and_Capturing_your_first_Image#PXE_booting
-
Sebastian, My fog server is running on centos 7 in minimal installation. can this cause the issue i am having? i did yum update all after i install Centos 7 but it is still minimal installation. let me know.
-
@pdit said in dhcp issue:
My fog server is running on centos 7 in minimal installation. can this cause the issue i am having?
Definitely not! FOG server system is not causing this I am fairly sure!
-
anything to do with Ethernet port name ? in centos 7 port is named as eno1 and that is what FOG picked up.
-
@pdit said in dhcp issue:
anything to do with Ethernet port name ? in centos 7 port is named as eno1 and that is what FOG picked up.
Nope! Some Linux systems use the “old” style
ethXwhile others use names likeenoXor evenenp0sX. But it’s just the naming and does not have anything to do with carrier/link status. -
After trying all kinds of options we tried removing patch cable and re connecting it back when FOG was showing "starting eth0 interface " it worked for that moment and than we re tried it worked again for same E73 desktop but when we tried completely different e73 we are back to same issue. sound like it is some type physical issue. but can’t seems to figure it out. different patch cable were tried as well.
anyways Thank you guys for all your support and quick replies. please close this thread. i will just create another Fog server hopefully it won’t give me this trouble.
-
@pdit I am farily sure this is not an issue with your FOG server but more a network card/driver issue on that E73!!! Don’t think building a new FOG server will help at all.
Try other Linux Live systems to see if they have the same issue or not.
-
Same E73’s works when imaged using in network Fog server. which is in Vmware VM. and connected using same old switches. we are going to replicate same setup with same hardware but in an isolated network.
