Thread: [Etherboot-users] REQUIRE_VCI_ETHERBOOT Question
Brought to you by:
marty_connor,
stefanhajnoczi
Menu
▾
▴
etherboot-users
|
From: Lonnie C. <lo...@ou...> - 2006-03-09 01:58:41
|
Greetings All,
I am trying to figure out how to set up a floppy boot image so that I
can boot a LTSP client but take advantage of possibly
"*REQUIRE_VCI_ETHERBOOT*" and not loose the MAC address as well.
The problem is that we have multiple DHCP servers and need to the client
to ignore all requests except from a specific one that is located on
another subnet.
I have been told that there is supposed to be a way for me to add in an
additional string of information into the floppy boot rom and also on my
DHCP server so that when the client nic receives a response from the
correct server then it will check for this string as well.
If this is possible, then I would like to be able to specify my own
string and not some default one like "Etherboot" which what I have read
seems to be in the documentation.
Can anyone please tell me more about this?
Thanks and have a good day,
Lonnie T. Cumberland
OutStep Technologies Incorporated
Email: Lo...@ou...
Lon...@ya...
Recommended sites:
http://www.peoplesquest.com
|
|
From: Jim M. <jam@McQuil.com> - 2006-03-09 04:01:23
|
Lonnie, While it's true that you can configure Etherboot to set the 'REQUIRE_VCI_ETHERBOOT' option, it won't do everything you think it will. The problem is, booting an LTSP workstation involves 2 DHCP requests. The first one is from the bootrom (Etherboot OR PXE). The 2nd DHCP request comes from dhclient inside the initrd that is downloaded along with the kernel. That 2nd DHCP request won't do the 'REQUIRE_VCI_ETHERBOOT' option, it will simply make a DHCP request and accept the first response, no matter which dhcp server offers that response. Then, it'll fail, if the wrong server offers it, because the wrong server probably isn't sending a 'root-path' value. You might instead try to set your LTSP dhcp to use ports 1067/1068, instead of the standard 67/68. That way, the workstation will make a request, and the only DHCP server that will ever see the request is the LTSP dhcp server. To use ports 1067/1068, there are 3 places you'll have to make a change: 1) The etherboot bootrom configuration 2) In the dhcpd.conf file, you'll have to set 'DPORT=1067' in an 'option-129' field. 3) You'll have to tell your dhcpd to ONLY listen on port 1067 Take a look at: http://wiki.ltsp.org/twiki/bin/view/Ltsp/DHCP#Multiple_DHCP_servers_on_the_sam for more information. ALSO, keep in mind, that using Ports 1067/1068 is ONLY an option for Etherboot. You can't do this with PXE. Hope that helps, Jim McQuillan jam@Ltsp.org Lonnie Cumberland wrote: > Greetings All, > > I am trying to figure out how to set up a floppy boot image so that I > can boot a LTSP client but take advantage of possibly > "*REQUIRE_VCI_ETHERBOOT*" and not loose the MAC address as well. > > The problem is that we have multiple DHCP servers and need to the > client to ignore all requests except from a specific one that is > located on another subnet. > > I have been told that there is supposed to be a way for me to add in > an additional string of information into the floppy boot rom and also > on my DHCP server so that when the client nic receives a response from > the correct server then it will check for this string as well. > > If this is possible, then I would like to be able to specify my own > string and not some default one like "Etherboot" which what I have > read seems to be in the documentation. > > Can anyone please tell me more about this? > > Thanks and have a good day, > > Lonnie T. Cumberland > OutStep Technologies Incorporated > > Email: Lo...@ou... > Lon...@ya... > Recommended sites: > http://www.peoplesquest.com > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting > language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Etherboot-users mailing list > Eth...@li... > https://lists.sourceforge.net/lists/listinfo/etherboot-users |
|
From: <lo...@ou...> - 2006-03-09 13:42:46
|
Hi Jim,
I see what you are saying and this all looks like a very limiting
factor of DHCP.
Let me ask you this, ok.
When a boot client does a broadcast for a DHCP request, then there
could be more than 1 DHCP server responding and the client would
receive requests from all responding DHCP servers looking for the one
that accepted that particular client and gave it a lease, right?
Would this also mean that, in general, for all of the DHCP servers,
then if only one of the had the client MAC address in their list then
that would be the request that would have the valid information (IP,
gateway, etc....) for that client?
I guess what I am getting at is that it is probably ok for there to be
multiple DHCP servers on the net and subnets as long a only one of them
had the client address as an acceptable MAC address.
The problem with changing ports for the DHCP server and Etherboot is
that there might already be other DHCP servers on those ports without
us bing aware of it by some chance and then we would still have
multiple requests beign fielded by multiple DHCP servers and in which
the problem is really not solved.
Thanks and have a good day,
Lonnie T. Cumberland
OutStep Technologies Incorporated
Email: Lo...@ou...
Lon...@ya...
Recommended sites:
http://www.peoplesquest.com
Quoting Jim McQuillan <jam@McQuil.com>:
> Lonnie,
>
> While it's true that you can configure Etherboot to set the
> 'REQUIRE_VCI_ETHERBOOT' option, it won't do everything you think it
> will.
>
> The problem is, booting an LTSP workstation involves 2 DHCP requests.
> The first one is from the bootrom (Etherboot OR PXE). The 2nd DHCP
> request comes from dhclient inside the initrd that is downloaded
> along with the kernel. That 2nd DHCP request won't do the
> 'REQUIRE_VCI_ETHERBOOT' option, it will simply make a DHCP request
> and accept the first response, no matter which dhcp server offers
> that response. Then, it'll fail, if the wrong server offers it,
> because the wrong server probably isn't sending a 'root-path' value.
>
> You might instead try to set your LTSP dhcp to use ports 1067/1068,
> instead of the standard 67/68. That way, the workstation will make a
> request, and the only DHCP server that will ever see the request is
> the LTSP dhcp server.
>
> To use ports 1067/1068, there are 3 places you'll have to make a change:
>
> 1) The etherboot bootrom configuration
> 2) In the dhcpd.conf file, you'll have to set 'DPORT=1067' in an
> 'option-129' field.
> 3) You'll have to tell your dhcpd to ONLY listen on port 1067
>
> Take a look at:
> http://wiki.ltsp.org/twiki/bin/view/Ltsp/DHCP#Multiple_DHCP_servers_on_the_sam
> for more information.
>
> ALSO, keep in mind, that using Ports 1067/1068 is ONLY an option for
> Etherboot. You can't do this with PXE.
>
> Hope that helps,
>
> Jim McQuillan
> jam@Ltsp.org
>
>
>
> Lonnie Cumberland wrote:
>> Greetings All,
>>
>> I am trying to figure out how to set up a floppy boot image so that
>> I can boot a LTSP client but take advantage of possibly
>> "*REQUIRE_VCI_ETHERBOOT*" and not loose the MAC address as well.
>>
>> The problem is that we have multiple DHCP servers and need to the
>> client to ignore all requests except from a specific one that is
>> located on another subnet.
>>
>> I have been told that there is supposed to be a way for me to add in
>> an additional string of information into the floppy boot rom and
>> also on my DHCP server so that when the client nic receives a
>> response from the correct server then it will check for this string
>> as well.
>>
>> If this is possible, then I would like to be able to specify my own
>> string and not some default one like "Etherboot" which what I have
>> read seems to be in the documentation.
>>
>> Can anyone please tell me more about this?
>>
>> Thanks and have a good day,
>>
>> Lonnie T. Cumberland
>> OutStep Technologies Incorporated
>>
>> Email: Lo...@ou...
>> Lon...@ya...
>> Recommended sites:
>> http://www.peoplesquest.com
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
>> that extends applications into web and mobile media. Attend the live webcast
>> and join the prime developer group breaking into this new coding territory!
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>> _______________________________________________
>> Etherboot-users mailing list
>> Eth...@li...
>> https://lists.sourceforge.net/lists/listinfo/etherboot-users
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Etherboot-users mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-users
>
|
|
From: Jim M. <jam@McQuil.com> - 2006-03-09 13:54:22
|
lo...@ou... wrote: > Hi Jim, > > I see what you are saying and this all looks like a very limiting > factor of DHCP. > > Let me ask you this, ok. > > When a boot client does a broadcast for a DHCP request, then there > could be more than 1 DHCP server responding and the client would > receive requests from all responding DHCP servers looking for the one > that accepted that particular client and gave it a lease, right? > > Would this also mean that, in general, for all of the DHCP servers, > then if only one of the had the client MAC address in their list then > that would be the request that would have the valid information (IP, > gateway, etc....) for that client? Well, sort of. Many people configure their dhcp servers to automatically hand out an IP address from a pool of addresses. So, you could have a 2nd dhcp server that responds to the dhcp request BEFORE your ltsp server gets a chance to. Then, the Etherboot or PXE bootrom would receive the offer, and possibly accept it. I think recent versions of Etherboot will ignore any responses that don't have a 'filename' parameter, so as far as etherboot is concerned, you'd only accept a reply from a dhcp server properly configured for diskless booted. BUT, after the kernel gets loaded in memory, and the 2nd DHCP request is sent out by the dhclient program inside the initrd, it doesn't make the distinction about the 'filename' parameter, and will accept an address from the first dhcp server that replies. This could cause a problem, because the reply that it gets might not have a 'root-path' parameter, and without that, the workstation will just die with an error. So, my advice is anytime you are thinking of putting a dhcp server on an existing network, you should make sure you know what other dhcp servers already exist, and if there are any, make sure they are configured to ignore requests from unknown clients, or they are configured to hand out the information that you need. I realize it's not always easy to know that information, but if I was one of the guys responsible for one of the existing DHCP servers, i'd be very angry if somebody dropped another dhcp server on my network without informing me. Many people just setup a separate lan segment for their LTSP thin clients that is completely separate from the existing network. Also, a smart switch with VLAN capabilities can help to separate the network for you. Jim McQuillan jam@Ltsp.org > > I guess what I am getting at is that it is probably ok for there to be > multiple DHCP servers on the net and subnets as long a only one of > them had the client address as an acceptable MAC address. > > The problem with changing ports for the DHCP server and Etherboot is > that there might already be other DHCP servers on those ports without > us bing aware of it by some chance and then we would still have > multiple requests beign fielded by multiple DHCP servers and in which > the problem is really not solved. > > Thanks and have a good day, > > Lonnie T. Cumberland > OutStep Technologies Incorporated > > Email: Lo...@ou... > Lon...@ya... > > Recommended sites: > > http://www.peoplesquest.com > > > > Quoting Jim McQuillan <jam@McQuil.com>: > >> Lonnie, >> >> While it's true that you can configure Etherboot to set the >> 'REQUIRE_VCI_ETHERBOOT' option, it won't do everything you think it >> will. >> >> The problem is, booting an LTSP workstation involves 2 DHCP requests. >> The first one is from the bootrom (Etherboot OR PXE). The 2nd DHCP >> request comes from dhclient inside the initrd that is downloaded >> along with the kernel. That 2nd DHCP request won't do the >> 'REQUIRE_VCI_ETHERBOOT' option, it will simply make a DHCP request >> and accept the first response, no matter which dhcp server offers >> that response. Then, it'll fail, if the wrong server offers it, >> because the wrong server probably isn't sending a 'root-path' value. >> >> You might instead try to set your LTSP dhcp to use ports 1067/1068, >> instead of the standard 67/68. That way, the workstation will make a >> request, and the only DHCP server that will ever see the request is >> the LTSP dhcp server. >> >> To use ports 1067/1068, there are 3 places you'll have to make a change: >> >> 1) The etherboot bootrom configuration >> 2) In the dhcpd.conf file, you'll have to set 'DPORT=1067' in an >> 'option-129' field. >> 3) You'll have to tell your dhcpd to ONLY listen on port 1067 >> >> Take a look at: >> http://wiki.ltsp.org/twiki/bin/view/Ltsp/DHCP#Multiple_DHCP_servers_on_the_sam >> >> for more information. >> >> ALSO, keep in mind, that using Ports 1067/1068 is ONLY an option for >> Etherboot. You can't do this with PXE. >> >> Hope that helps, >> >> Jim McQuillan >> jam@Ltsp.org >> >> >> >> Lonnie Cumberland wrote: >>> Greetings All, >>> >>> I am trying to figure out how to set up a floppy boot image so that >>> I can boot a LTSP client but take advantage of possibly >>> "*REQUIRE_VCI_ETHERBOOT*" and not loose the MAC address as well. >>> >>> The problem is that we have multiple DHCP servers and need to the >>> client to ignore all requests except from a specific one that is >>> located on another subnet. >>> >>> I have been told that there is supposed to be a way for me to add in >>> an additional string of information into the floppy boot rom and >>> also on my DHCP server so that when the client nic receives a >>> response from the correct server then it will check for this string >>> as well. >>> >>> If this is possible, then I would like to be able to specify my own >>> string and not some default one like "Etherboot" which what I have >>> read seems to be in the documentation. >>> >>> Can anyone please tell me more about this? >>> >>> Thanks and have a good day, >>> >>> Lonnie T. Cumberland >>> OutStep Technologies Incorporated >>> >>> Email: Lo...@ou... >>> Lon...@ya... >>> Recommended sites: >>> http://www.peoplesquest.com >>> >>> >>> >>> >>> ------------------------------------------------------- >>> This SF.Net email is sponsored by xPML, a groundbreaking scripting >>> language >>> that extends applications into web and mobile media. Attend the live >>> webcast >>> and join the prime developer group breaking into this new coding >>> territory! >>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 >>> >>> _______________________________________________ >>> Etherboot-users mailing list >>> Eth...@li... >>> https://lists.sourceforge.net/lists/listinfo/etherboot-users >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by xPML, a groundbreaking scripting >> language >> that extends applications into web and mobile media. Attend the live >> webcast >> and join the prime developer group breaking into this new coding >> territory! >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 >> _______________________________________________ >> Etherboot-users mailing list >> Eth...@li... >> https://lists.sourceforge.net/lists/listinfo/etherboot-users >> > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting > language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Etherboot-users mailing list > Eth...@li... > https://lists.sourceforge.net/lists/listinfo/etherboot-users |
|
From: Peter <pl...@ac...> - 2006-03-09 14:20:27
|
When a DHCP server has no data for a client it does not respond. 'No data' means the client is not in its SOA (or explicitly excluded by MAC). Peter |
|
From: Marty C. <md...@et...> - 2006-03-09 19:15:09
|
On Mar 9, 2006, at 4:52 PM, lo...@ou... wrote:
> When a boot client does a broadcast for a DHCP request, then there
> could be more than 1 DHCP server responding and the client would
> receive requests from all responding DHCP servers looking for the
> one that accepted that particular client and gave it a lease, right?
It's more elaborate than that. PXE says the client should wait for
up to 3 DHCP offers, and pick the one it likes the best (correct me
if I'm wrong, PXE mavens).
> Would this also mean that, in general, for all of the DHCP servers,
> then if only one of the had the client MAC address in their list
> then that would be the request that would have the valid
> information (IP, gateway, etc....) for that client?
> I guess what I am getting at is that it is probably ok for there to
> be multiple DHCP servers on the net and subnets as long a only one
> of them had the client address as an acceptable MAC address.
It depends on if they're (the DHCP server) are "authoritative" for
the subnet or "not authoritative" in ISC dhcpd.conf parlance.
If they have the "not authoritative" directive turned on, they don't
say anything. If they're authoritative, I believe they say "no lease"
if you don't have a pool of addresses defined.
> The problem with changing ports for the DHCP server and Etherboot
> is that there might already be other DHCP servers on those ports
> without us bing aware of it by some chance and then we would still
> have multiple requests beign fielded by multiple DHCP servers and
> in which the problem is really not solved.
We're looking at allowing people to put STATIC information in their
Etherboot configuration so that no DHCP server is required to load a
file.
This means that someone could mess up and walk on an IP address on
the LAN, but this is already possible on just about any device I know
about.
The consequences would be between you and your LAN administrator if
you blow it.
Isn't there some way to use DEFAULT_BOOTFILE to get what you want
using Etherboot?
setting DEFAULT_BOOTFILE to:
tftp://192.168.1.xxx/tftpboot/lts/kernel.nb
(I believe) would get an IP address from a DHCP server, and then
(assuming the DHCP server didn't give a filename) would use the
DEFAULT_BOOTFILE.
I even found an old patch that would FORCE_BOOTFILE (although I would
rename it FORCE_DEFAULT_BOOTFILE :) that ignores all the DHCP
filenames and uses the one you supplied.
This strikes me as a likely scenario. You can get an IP, Router,
DNS, etc, but you can't modify the DHCP server to do the filename
thing, even though you have your own little tftp server (they're so
much less objectionable than DHCP servers to LAN admins, after all).
So you get everything from normal DHCP except DEFAULT_BOOTFILE, and
you get your kernel from where you need to.
Does this help?
Marty
--- etherboot-5.3.6/src/core/nic.c 2003-12-13 07:27:21.000000000
+0100
+++ etherboot-5.3.6.new/src/core/nic.c 2003-12-21 15:22:27.000000000
+0100
@@ -267,7 +267,11 @@
rpc_init();
#endif
#ifdef DEFAULT_BOOTFILE
+#ifdef FORCE_BOOTFILE
+ kernel = DEFAULT_BOOTFILE;
+#else
kernel = KERNEL_BUF[0] != '\0' ? KERNEL_BUF : DEFAULT_BOOTFILE;
+#endif /*FORCE_BOOTFILE */
#else
kernel = KERNEL_BUF;
#endif
|
|
From: Jim M. <jam@McQuil.com> - 2006-03-09 19:30:10
|
On Thu, March 9, 2006 2:14 pm, Marty Connor wrote: > On Mar 9, 2006, at 4:52 PM, lonnie=40outstep.com wrote: >> When a boot client does a broadcast for a DHCP request, then there >> could be more than 1 DHCP server responding and the client would >> receive requests from all responding DHCP servers looking for the >> one that accepted that particular client and gave it a lease, right? > > It's more elaborate than that. PXE says the client should wait for > up to 3 DHCP offers, and pick the one it likes the best (correct me > if I'm wrong, PXE mavens). > >> Would this also mean that, in general, for all of the DHCP servers, >> then if only one of the had the client MAC address in their list >> then that would be the request that would have the valid >> information (IP, gateway, etc....) for that client? >> I guess what I am getting at is that it is probably ok for there to >> be multiple DHCP servers on the net and subnets as long a only one >> of them had the client address as an acceptable MAC address. > > It depends on if they're (the DHCP server) are =22authoritative=22 for > the subnet or =22not authoritative=22 in ISC dhcpd.conf parlance. > If they have the =22not authoritative=22 directive turned on, they don'= t > say anything. If they're authoritative, I believe they say =22no lease=22= > if you don't have a pool of addresses defined. > >> The problem with changing ports for the DHCP server and Etherboot >> is that there might already be other DHCP servers on those ports >> without us bing aware of it by some chance and then we would still >> have multiple requests beign fielded by multiple DHCP servers and >> in which the problem is really not solved. > > We're looking at allowing people to put STATIC information in their > Etherboot configuration so that no DHCP server is required to load a > file. > This means that someone could mess up and walk on an IP address on > the LAN, but this is already possible on just about any device I know > about. > The consequences would be between you and your LAN administrator if > you blow it. > > Isn't there some way to use DEFAULT_BOOTFILE to get what you want > using Etherboot? > > setting DEFAULT_BOOTFILE to: > > tftp://192.168.1.xxx/tftpboot/lts/kernel.nb > > (I believe) would get an IP address from a DHCP server, and then > (assuming the DHCP server didn't give a filename) would use the > DEFAULT_BOOTFILE. > > I even found an old patch that would FORCE_BOOTFILE (although I would > rename it FORCE_DEFAULT_BOOTFILE :) that ignores all the DHCP > filenames and uses the one you supplied. > > This strikes me as a likely scenario. You can get an IP, Router, > DNS, etc, but you can't modify the DHCP server to do the filename > thing, even though you have your own little tftp server (they're so > much less objectionable than DHCP servers to LAN admins, after all). > > So you get everything from normal DHCP except DEFAULT_BOOTFILE, and > you get your kernel from where you need to. > > Does this help? He'd still be missing the root-path option that is required by LTSP (assuming he's using LTSP). Fortunately, it's possible to fix that in LTSP (Don't ya just love open source?) Jim. > > Marty > > --- etherboot-5.3.6/src/core/nic.c 2003-12-13 07:27:21.000000000 > +0100 > +++ etherboot-5.3.6.new/src/core/nic.c 2003-12-21 15:22:27.000000000 > +0100 > =40=40 -267,7 +267,11 =40=40 > rpc_init(); > =23endif > =23ifdef DEFAULT_BOOTFILE > +=23ifdef FORCE_BOOTFILE > + kernel =3D DEFAULT_BOOTFILE; > +=23else > kernel =3D KERNEL_BUF=5B0=5D =21=3D '=5C0' ? KERNEL_BUF : DEFA= ULT_BOOTFILE; > +=23endif /*FORCE_BOOTFILE */ > =23else > kernel =3D KERNEL_BUF; > =23endif > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting > language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding > territory=21 > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat= =3D121642 > _______________________________________________ > Etherboot-users mailing list > Etherboot-users=40lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/etherboot-users > |
|
From: Marty C. <md...@et...> - 2006-03-09 19:48:41
|
On Mar 9, 2006, at 2:30 PM, Jim McQuillan wrote:
> On Thu, March 9, 2006 2:14 pm, Marty Connor wrote:
>> Isn't there some way to use DEFAULT_BOOTFILE to get what you want
>> using Etherboot?
>>
>> setting DEFAULT_BOOTFILE to:
>>
>> tftp://192.168.1.xxx/tftpboot/lts/kernel.nb
>>
>> (I believe) would get an IP address from a DHCP server, and then
>> (assuming the DHCP server didn't give a filename) would use the
>> DEFAULT_BOOTFILE.
...
> He'd still be missing the root-path option that is required by LTSP
> (assuming he's using LTSP).
"There's always somethin'"... :)
> Fortunately, it's possible to fix that in LTSP (Don't ya just love
> open
> source?)
OK, I'm dying of suspense. How do you fix this in LTSP?
Inquiring minds, WanT tO KnOw...
Marty
|
|
From: Jim M. <jam@McQuil.com> - 2006-03-09 21:36:37
|
On Thu, March 9, 2006 2:48 pm, Marty Connor wrote: > On Mar 9, 2006, at 2:30 PM, Jim McQuillan wrote: >> On Thu, March 9, 2006 2:14 pm, Marty Connor wrote: >>> Isn't there some way to use DEFAULT_BOOTFILE to get what you want >>> using Etherboot? >>> >>> setting DEFAULT_BOOTFILE to: >>> >>> tftp://192.168.1.xxx/tftpboot/lts/kernel.nb >>> >>> (I believe) would get an IP address from a DHCP server, and then >>> (assuming the DHCP server didn't give a filename) would use the >>> DEFAULT_BOOTFILE. > ... >> He'd still be missing the root-path option that is required by LTSP >> (assuming he's using LTSP). > > =22There's always somethin'=22... :) > >> Fortunately, it's possible to fix that in LTSP (Don't ya just love >> open >> source?) > > OK, I'm dying of suspense. How do you fix this in LTSP? > Inquiring minds, WanT tO KnOw... You'd have to edit the linuxrc script in the initrd to accept a new optio= n for forcing root-path. In fact, you'd have to figure out if DHCP is completely out of the picture, or of it's still OK for the workstation to query dhcp for it's I= P address and netmask/broadcast/gateway info. If you want DHCP completely out of the picture, you'd have to pass all of= the information via the kernel cmdline, and then the linuxrc script would= have to pick that up and NOT call dhclient. So, I suppose we could add a couple of kernel cmdline options, like: ROOTPATH=3D<ipaddr and directory> NODHCP=3D=22ipaddr:netmask:broadcast:gateway:rootpath=22 So, you could either set ROOTPATH to the root-path value and use dhcp to get the rest, OR, you could set NODHCP to contain everything. of course, with Etherboot, you'd have to set option-128/129 to pass that kernel cmdline. Also, I think there's a limit to how long the kernel cmdline can be, but i'm not sure if the limit is in the range that we should be worried about= . Also, the comments above about 'initrd' will all change with LTSP-4.2, because we are switching over to initramfs. But, the concepts are still pretty much the same. btw, we're on track to deliver LTSP-4.2 for LinuxWorld in Boston (Apr 3-6= ). Jim. > > Marty > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting > language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding > territory=21 > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat= =3D121642 > _______________________________________________ > Etherboot-users mailing list > Etherboot-users=40lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/etherboot-users > |
Thanks for helping keep SourceForge clean.
X