udhcpc: sending discover
-
@jhalbert Understand I’m NOT recommending you turn off spanning tree, only change its mode to one of the fast spanning tree protocols. The fast protocols use optimistic blocking (forward first then listen for BPDU) instead of pessimistic (block while listening for BPDU) that standard stp uses.
Is there a way to do it without changing the network, yes but it will require a little work on your part (honestly you need to enable RSTP to fix it for all). You will need to unpack the init.xz file. Its located on the fog server in /var/www/html/fog/service/ipxe directory. The instructions for unpacking and packing the inits are here: https://wiki.fogproject.org/wiki/index.php/Modifying_the_Init_Image Follow the 1.0.0 and up instructions. Once they are unpacked in the unpacked directory you need to edit a file in ./etc/init.d called S40Network. Just before the
udhcpc
command add in a line that sayssleep 27
Save the file and then repack the inits and move to the /var/www/html/fog/service/ipxe directory.What that will do is have FOS Linux pause for 27 seconds on every boot to let the network settle before trying to dhcp boot.
-
@george1421 I hate to ask this, but could you write up a detailed guide on how to do this? I’m beginner level at linux. I unpacked the file and when i tried to open up the init file i could not save the file after changing the values. It was being edited in Terminal.
I also noticed in fog that there is a setting called “Remit Hello Interval” in the storage settings. Would this be the same settings?
Thanks for any advice you can give!
-
@tech49 What version of FOG are you using?
I don’t have a step by step because this is a bit more advanced function than beginners should approach. But if you unpack the inits it will create a directory structure that mirrors the virtual hard drive. You can than traverse that directory. You can edit the file using the host OS gui editor if you are using a gui based OS like ubuntu. Or you can edit the file using a character based editor.
vi
is the most common but also the most cryptic to use.I’ll go through the steps with
vi
to show you at least how to edit.You will need to navigate to the etc/init.d directory where the inits were unpacked to.
vi S40Network
Use the down arrow to find the line withudhcp
there will be more stuff after but you want the line with the text that starts out as udhcp. At the beginning of the line key in
i
to insert mode
cr
for a new line
esc
key to edit insert mode
up arrow
to go to the inserted blank line
i
to enter insert mode
space over until cursor is just above the u in udhcp then key in
sleep 27
esc
to exit insert mode
:wq
colon write quitThat will drop you back to the linux command prompt. Go back up to the root of where you unpacked the inits and then repack them back into init.xz
-
@george1421 Thanks, I’m using fog 1.5.7 on Ubuntu 18 LTS
for notes reasons this is what I did. I was unable to open it in VI for some reason. The screen was blank, SO I did a sudo gedit and opened it up in the text editor software. This is what I did for the sleep 27 line.
for retry in $(seq 3); do sleep 27 /sbin/udhcpc -i $iface --now
About to give this puppy a whirl. Will let you know if it worked.
-
@tech49 No go
-
@george1421 @tech49 Shouldn’t it be:
for retry in $(seq 3); do sleep 27 /sbin/udhcpc -i $iface --now done
-
@Sebastian-Roth Oh no, I was just typing in the little bit of it freehanded described in the instruction and guide. I’m not sure if there’s a done there or not. I will check asap.
-
@tech49 The other thing I would recommend is that you add an echo statement just above the sleep 27 like
echo "Sleeping for a bit";
to be sure that the code is executing like we think. Let me go and get the github page so we can be sure.The other thing is to (with the fog delivered inits) pxe boot into debug mode and then key in
/sbin/udhcpc -i $iface --now
replacing $iface with the name of your physical network adapter collected with theip addr show
command.This is the line in question https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/etc/init.d/S40network#L38, where the echo and sleep command needs to be inserted.
-
Wait till the interface is fully up and ready (spanning tree)
timeout=0 linkstate=0 until [[ $linkstate -eq 1 || $timeout -ge 35 ]]; do let timeout+=1 linkstate=$(/bin/cat /sys/class/net/$iface/carrier) [[ $linkstate -eq 0 ]] && sleep 1 || break done [[ $linkstate -eq 0 ]] && echo "No link detected on $iface for $timeout seconds, skipping it." && continue for retry in $(seq 3); do sleep 27 /sbin/udhcpc -i $iface --now ustat="$?" curl -Ikfso /dev/null "${web}"/index.php --connect-timeout 5 cstat="$?" # If the udhcp is okay AND we can curl our web # we know we have link so no need to continue on. # NOTE: the link to web is kind of important, just # exiting on dhcp request is not sufficient. [[ $ustat -eq 0 && $cstat -eq 0 ]] && exit 0 echo "Either DHCP failed or we were unable to access ${web}/index.php for connection testing." sleep 1 done echo "No DHCP response on interface $iface, skipping it."
done
If we end up here something went wrong as we do exit the script as soon as we get an IP
-
@george1421 How do I pxeboot into debug mode?
-
@george1421 Is it worth modifying anything in init_32.xz?
-
@tech49 said in udhcpc: sending discover:
@george1421 How do I pxeboot into debug mode?
When you schedule a task (capture or deploy) before you hit the schedule task button tick the debug checkbox. Then pxe boot the target computer.
The idea with this route is to manually wait the 27 seconds before manually issuing the udhcp command. Your issue may be totally different if time doesn’t fix the dhcp issue (i.e. your computer uses one of the new realtek nic chip sets) .
-
@tech49 said in udhcpc: sending discover:
@george1421 Is it worth modifying anything in init_32.xz?
Not unless you are working with 32 bit hardware (not likely now days)
-
@george1421
Ok, I entered in the Echo line and repackaged the file with the guide on the wiki.The echo command did not work. I saw nothing saying “Sleeping for a bit”
-
@tech49 What version of FOG are you using? Oh I see it never mind. Let me do this to the inits.
-
OK here is the modified init: https://drive.google.com/open?id=1ZDLcftq_yx3c0BiIAVhNwwpn2j-gDzCE
If this fails to print the sleep 27 we will need a screen shot of what you see when it fails because it should print the waiting a bit .
-
@george1421 No echos seen
I saved the file to my desktop and did sudo cp -r /home/username/desktop /var/www/fog/…/ipxe… I browsed to it on the GUI and confirmed on properties it was modified the time id id so.
The output I got after a quick host registration was
populating .dev: done
initializing random number done
starting haveged: ok
starting enp1so interface and waiting fof the link to come up
udhcpc: started v1.29.3
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
udhcpc: no lease, failing
Either DHCP failed or we were unable to access http://fogserveripaddress/fog//index.php for connection testing.
repeat 3 times
No DHCP respawn on interface enp1s0 , skipping it.
failed to get an ip via dhcp, tried on interfaces enp1s0Note: I’m using a laptop for the fog server , Dell latitude e5420 Bios: LegacyBoot Secure off
I’m trying to do a Quick or Full host registration on a Dell Optiplex 3050. Bios: Uefi on SecureBoot onBoth confirmed pxe on
-
@george1421 I got it to work! I plugged a dumb switch inbetween the managed ciscos and the PC i was trying to pxe boot. I’m thinking there is a power saving issue setup that keeps it from powering on
Now here’s another problem.
When its at
*Start host registration
*Enter hostname for this computer:I’m going to reinstall fog from scratch i think
I cannot type anything !!!
Much love to you developers who have helped this linux noob out with this problem. It’s been super educational
-
@tech49 said in udhcpc: sending discover:
I plugged a dumb switch inbetween the managed ciscos and the PC i was trying to pxe boot
We have seen this condition as a spanning tree issue (not using one of the fast spanning tree protocols like portFast or RSTP. Also we see this condition with the green ethernet settings on the switch getting confused and powering off the port. Placing a dumb switch in between the building switch and the pxe booting computer keeps the building switch active while PXE hands off to iPXE and then iPXE hands off to FOS Linux. Every time this hand off happens it drops the ethernet link momentarily. The switch sees this as a disconnect/reconnect.
-
@tech49 Please make a new thread for the new issue so we can help you there. (since it’s unrelated to the thread)