[EMAIL PROTECTED] wrote:
I'm not very familiar with diskless boot, so could you please you help
me understand the typical usage here? It seems to me
that if a diskless client tries to change configuration permanently
at runtime, the settings would be attached to config files in the server,
so that the next client would pick up the changes.
Yes and no.
The image pulled from the server could be for multiple clients (as in a
netinstall case) or it could be for an individual host.
So it seems
like the more practical option here would be to use 'dladm -t' (i.e.,
temporary). If, otoh, you are referring to the usage of obp for
setting driver configuration on sparc, it's not clear to me how
equivalent functionality is available on intel? Also, my understanding
is that the obp method only applies to a very limited set of
parameters?
The person which crafts the boot image on the server can put in a
driver.conf file which means that once the Solaris kernel takes over
from OBP/PXE (i.e., the Solaris Ethernet driver is what is used and not
the OBP or PXE/BIOS driver), then those driver.conf settings would apply.
However, given that driver.conf is used for non-network driver parameters
as well, I don't think driver.conf itself can be completely eradicated
even if it is somewhat clumsy to use. Brussels will, at least, provide
a cleaner method for network drivers.
I don't think it helps at all in the diskless case, which is why I
suspect that most of the networking driver knobs in driver.conf will remain.
If the customer needs some workaround (e.g., turn of autonegotation of
speed; force 100 Mbps) or some performance tweak (e.g., enable
jumboframes) they can do that in the driver.conf on the server which
serves up the root file system/boot archive.
*If* and only if you can have the Brussels properties apply when the
driver is attached then you have a way to avoid driver.conf settings for
networking drivers.
Erik
_______________________________________________
networking-discuss mailing list
[email protected]
