Hi Ralf,
I had similar problems with FSC RX300S3 systems, which have an
onboard Broadcom 5715 dual port interface. My systems have an
additional Intel quad port card, so I end up with 6 interfaces, and the
one I need for FAI install is never eth0. This was no problem with
my etch environment, I see these problems only since I started with
lenny/FAI3.2.14.
I thought if we have an 'ip=dhcp' in the kernel command line of the
pxelinux config file then ipconfig from klibc-utils would just try
all interfaces and use the one, where it gets an answer. At least, that's
how I understand Documentation/nfsroot in the kernel sources.
That would seem logical, though admittedly I've only glossed through the
kernel source (panic.c, exit.c, etc.), and not enough to know it very well.
My first try was to use entries like 'ip=:::::eth1:dhcp', but the systems
was still hanging before the nfsroot mount.
My current solution with the FAI3.2.14/lenny server is to use a
specific initrd and nfsroot for these boxes and fix the interface
naming with an udev rules file in the initrd. Then the dhcp-connected
interface is forced to be eth0 and it works.
[As I have a couple of systems with identical setup for the interface
cards, I use the PCI slot id for naming, with entries like
ACTION=="add", SUBSYSTEM=="net", BUS=="pci", ID=="0000:12:04.1", NAME="eth0"
ACTION=="add", SUBSYSTEM=="net", BUS=="pci", ID=="0000:12:04.0", NAME="eth1"
This is included in the initrd with a initramfs-tools/hooks script.]
Though this works I would still like to understand why the default
setup did not. I'll follow this thread and hope to learn ...
Yeah, I have a similar custom script that runs near the end of my FAI
installation, because we have a convention of making the main interface
eth1 - the intranet port, since many boxes are not public facing. It
basically swaps the interfaces via some udev hand-waving. I never
considered doing this in the initrd, but that may be a possible solution.
However, I don't know if probing all interfaces is a solution, since
ipconfig seems to hang indefinitely if it probes an interface that
doesn't have a cable or is otherwise unavailable. It may be that a bug
needs to be filed against the klibc-utils package; a binary that hangs
after trying one interface is a horrible implementation - it cripples
PXE functionality. I'll keep you and the list in the loop as to how I
end up solving this.
Thanks for your input - it could certainly prove useful!
Respectfully,
Ryan
