Re: [Etherboot-developers] Q: Multiple drivers.

[Peter L. <P.L...@sy...>]

> I agree that user interaction isn't right when you want unattended
> booting.  I'm not so sure that sending out requests on all interfaces is
> the right policy either. An example is my firewall machine. If it sends
> out a request to the cable modem it will get an ISP assigned address,
> but this is useless for remote booting.

It depends why you have multiple nics. In our case it's for channel
bonding and failover, so multiple requests on all available nics is
definitely the right thing to do. I'd add a client identifier to each
request, which identifies the system rather than the nic so that a dhcp
server receiving multiple requests can decide to react to just one. The
multiple requests should all have different xids, though, and the
clients should politely decline they replies they don't use.

Anyway, REQUIRE_VCI_ETHERBOOT makes you ignore the ISP, no?

> When the code is in a ROM on a NIC, the right action is more obvious, it
> should only send out requests on the NIC it lives in. When it's part of
> the BIOS ROM, then it's harder to say what the right policy is.

Using the nic the bios lives might be a tie-breaker when you have a
choice, but I don't think it is "obviously" right; in fact I think it's
evil to vary the behaviour of Etherboot depending on whether you
happened to boot from a nic rom, bios rom, via PXE, lilo, etc. As Vasil
says, the major win of Etherboot is the number of media it will boot
from and the fact that behaviour is identical regardless of how the boot
happens. My experience has been that which nic happens to have been used
for booting is actually a function of dumbass things like which slot the
BIOS chose, which nics were able flashed (I've had 2 bad flash roms in
905Cs, so in a couple of machines it's not the same slot as the others).
These are not criteria which should be influencing Etherboot.

We have lots of systems with multiple NICs, and have used Etherboot via
PXE; which *does* use the nic it booted from - and is inclined to use
different MAC addresses from that which Etherboot chooses (the first it
finds). Initially I thought that was a problem, but now I keep the PXE
Etherboot, and Sychron DHCP configs separate. No problem at all.

Finally, it's worth considering that, if one has e.g. a router or other
system where the nics are not used for channel bonding + failover to a
common infrastructure, then the correct thing to consider is not which
nic it is, which PCI slot it's in, or where it came in Linux's scan
order - the critical factor is what network it is connected to. It seems
perfectly reasonable to me that a router should checking who's at the
other end BEFORE configuring. Maybe you (or your trusted assistant) got
those grey cables back to front. Maybe that minor OS release reversed
the scan order (it's happened to me).

> Perhaps the answer is to allow all these behaviours, chosen by compile
> options. I could then put a single driver ROM on my internal NIC, and
> you can put a multiple driver multiple request ROM in your BIOS.

Absolutely. :) There's a great deal of scope for people to experiment
with new ways of using this kind of thing. Another of Etherboot's wins
for me is that it seems eminently extendable. with functionality just
like this.