Re: issue with detecting the right interface
Ok, I figured out why that code wasn't running. It skips the code that
iterates over all the interface because I have netboot=nfs in my
pxelinux stanza. But it's looking for all these to be null for that
code to run
if [ -z "${NETBOOT}" ] && [ -z "${FETCH}" ] && \
[ -z "${HTTPFS}" ] && [ -z "${FTPFS}" ]
then
I don't know why, it checks for these conditions, and shouldn't
netboot=nfs needs to be there? I took it out to test and it doesn't
like it and fails miserably. After it skips that code, it tries to get
a DHCP on the first NIC with a link which isn't right.
The following snippet is from scripts/live-premount/select_eth_device
..
for step in 1 2 3 4 5; do
for interface in $l_interfaces; do
carrier=$(cat /sys/class/net/$interface/carrier \
2>/dev/null)
# link detected
if [ "$carrier" = 1 ]; then
echo " found $interface."
# inform initrd's init script :
echo "DEVICE=$interface" >> /conf/param.conf
exit 0
fi
done
# wait a bit
sleep 1
done
...
It puts the first interface it finds with a link in conf/param.conf
and then exits. That is not right, in our case anyway, because we
could potentially have more then one interface with a link but only
one of the interface is on the network with a DHCP server running on
it. Now conf/param.conf has the the wrong interface and it runs
ipconfig on it and gets stuck there.
ipconfig ${DEVICE} | tee /netboot.config
Kashif
On Sun, Sep 4, 2011 at 2:45 PM, Joseph Gunn <armadefuego@gmail.com> wrote:
> On Sun, 4 Sep 2011 14:00:28 -0700
> Kash <melbogia@gmail.com> wrote:
>
>> For whatever reason the conditions were not met for it to run that
>> particular code where it would iterate through all the available interfaces.
>> It kept trying to run ipconfig on the first interface with the link and get
>> stuck there.
>>
>> Now, we have a number of machines with 12 interfaces and even if it did
>> iterate through all the interfaces, going through 12 is quite slow as you
>> can imagine, it takes 15 seconds to go through one interface. Rather then
>> spending time on figuring out why the conditions weren't met to go through
>> that code, I wrote another solution which would depend on bootif, which is
>> much faster.
>>
> Agreed.
>
> It is a good thing to have options.
>
> I never questioned your need, even with 2 interfaces 15 secs is a long time.
>
> i just wish to understand the failure mode for when autoconfig is the
> only viable option.
>
> We will see soon if i can recreate this.
>
Reply to: