[EMAIL PROTECTED] wrote:
>Jason Pattie figured out how to have the older etherboot
>grab a newer etherboot from the tftp server, which in turn
>would grab the kernel and pass the options properly.
>
>it involved trickery in the dhcpd.conf file, which btw, required
>dhcpd version 3.0.
>
>I'll see if I can get Jason to document what he has done.
>
You can try. :)
-------------------------------------------------------------------------------------------------------
Technically speaking, you could have Etherboot load Etherboot load
Etherboot load Etherboot etc. etc. (depending on how many different
criteria you can come up with to differentiate different versions of
Etherboot to load), but we will only detail having an older version of
Etherboot load a newer version of Etherboot. The differentiating factor
in this scenario is the fact that older versions of Etherboot did not
send the Vendor Class Identifier to the DHCP server when requesting an
IP address and configuration information. Consequently, we cannot use
this differentiation for future versions of Etherboot since they will be
sending VCI information. We would have to depend on a versioning scheme
or something else to make a difference that we can use to send the
newest version of Etherboot to the booting client. This time, we will
use the fact that older Etherboot versions do not send VCI information
to configure the dhcpd.conf file to be aware of the request from the
non-VCI aware version of Etherboot and send a response that contains a
new version of Etherboot that does send VCI information. The old
version of Etherboot will execute the new version of Etherboot, which
when requesting IP information from the DHCP server will send VCI
information. The actual Vendor Class Identifier information that is
sent to the DHCP server from Etherboot is (what do you know!) the string
"Etherboot". You can contrast this with a PXE client that sends the
string "PXEClient" for its Vendor Class Identifier. The "Etherboot"
string will be used to match incoming requests from general or specific
clients as your needs may be.
In the scenario that I had to do this, since there were only two
different kinds of network cards with one kind being broken at the
BOOTROM level (i.e., an older version of Etherboot was acting up causing
kernel panics by generating spurious interrupts) and the client not
monetarily able to fix the problem by replacing/reprogramming the
BOOTROM's, I was able to get away with having all incoming DHCP requests
funneled through a single if {...} else {...} block that checked for the
VCI string equal to "Etherboot" or not and served the appropriate image,
either a new version of Etherboot for those requests that don't send VCI
information or the Etherboot tagged kernel image.
Now of course, you would like a dhcpd.conf configuration sample. Well,
here is the generic case where all incoming requests are checked:
ddns-update-style none;
subnet 192.168.0.0 netmask 255.255.255.0
{
range dynamic-bootp 192.168.0.100 192.168.0.200;
option domain-name-servers 192.168.0.254;
option routers 192.168.0.254;
next-server 192.168.0.254;
if substring (option vendor-class-identifier, 0, 9) = "Etherboot" {
filename "/tftpboot/lts/vmlinuz.generic";
}
else {
filename "/tftpboot/lts/rtl8139.rom.nbi";
}
group
{
use-host-decl-names on;
...
}
}
Notice in this example that a very specific file is downloaded in the
case where the DHCP request does not have the VCI information set to
"Etherboot". That file is an NBI tagged ROM image, and that image is
only for an RTL8139 chipset based network card. Obviously, this
configuration is not very useful if you have more than just Realtek
cards in your network of thin-clients and/or any other machines that
retrieve their IP settings via DHCP. Of course the other DHCP clients
on your network that are not using DHCP settings with which to boot will
not be affected, since they should just throw away the 'filename' value
and are not running that file anyway.
The next question you are doubtless to ask is how to create an NBI
tagged ROM image for your network card(s). All you need is the mknbi
utility -- that is downloadable in source or RPM and other formats from
etherboot.sourceforge.net -- and the Etherboot ROM image for your
network card. Install the mknbi utility, and a symbolic link to
mknbi-rom will be created (among other symbolic links to mknbi that do
other tagging functions). Download the Etherboot ROM image from
www.rom-o-matic.net for your network card (or alternatively download and
install the latest version of the Etherboot project and build your
network card ROM from it). Use mknbi-rom to generate an NBI tagged
version of the Etherboot ROM for your network card:
mknbi-rom --output=/tftpboot/lts/rtl8139.rom.nbi rtl8139.rom
That's all there is to generating the NBI tagged ROM. This will wrap a
new version of Etherboot with the tagging information necessary to allow
another version of Etherboot to download it and see it as a properly
tagged format and execute it.
You can obviously put the generic check into specific host entries in
order to hand out different NBI tagged Etherboot ROM images for all the
different network cards you might have. Something similar to the
following would be necessary in dhcpd.conf:
host ws001 {
hardware ethernet 00:02:B3:25:45:56;
if substring (option vendor-class-identifier, 0, 9) = "Etherboot" {
filename "/lts/vmlinuz.generic";
} else {
filename "/lts/ne2000.rom.nbi";
}
}
host ws002 {
hardware ethernet 00:02:B3:25:56:78;
if substring (option vendor-class-identifier, 0, 9) = "Etherboot" {
filename "/lts/vmlinuz.generic";
} else {
filename "/lts/sis900.rom.nbi";
}
}
...
I used mknbi-1.2. I'm not sure if the same technique can be applied
with older versions of mknbi, but I would think so. You will also
definitely need ISC DHCP 3.0 or better or a DHCP server that can
recognize the 'vendor-class-identifier' option.
Hope this has been helpful.
--------------------------------------------------------
Jim, chop this up as you see fit. :)
--
Jason A. Pattie
[EMAIL PROTECTED]
_____________________________________________________________________
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp channel on irc.openprojects.net
