[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: DHCP, BOOTP and linux

"Eray Ozkural (exa)" <erayo@cs.bilkent.edu.tr> writes:

> In linux-2.2.18 I have been perfectly unable to use kernel level network
> autoconf with DHCP because it simply wouldn't work with my 3c905/c.

Works for me... I don't have that exact card, however.

> The BOOTP didn't work either. I then realized that it was broken for
> my card at least and switched to 2.4.1 for my net box. The 2.4.1 did
> have BOOTP but it didn't seem to have DHCP. Anybody knows why?

I dunno -- do you have the necessary kernel options compiled in?
You'd have to see the DHCP documentation for what exact options these
are, I forget.

> Second, you know debian has a copy of this wonder dhcp server released
> by ISC.

Yes, that's what I use, although I use the v3 version from

> Anyway, I configured it and managed to run it for the first time.
> It did allocate some IP from the range I config'd. The problem is that
> my MBA (managed boot agent) on eth0 just didn't know how well that server
> was written. Yes, it did work when I said DHCP, but it wouldn't work
> as a BOOTP client. I'd specified the host explicitly (as a BOOTP client)
> in the DHCP conf. Like this:
> host stardust {
>   hardware ethernet 0:1:2:e0:62:55;
>   filename "/boot/bootimage.stardust";
> }
> That was supposed to work for BOOTP clients, too. (is it?)

Well, if you configure your subnet right.  I do:

subnet netmask {
  range dynamic-bootp;

> Anyway, it didn't.
> And I'm not sure whether dhcp really obsoletes bootp anymore.

Yes, it certainly does.

> In fact, a lot of things are easier to set up with bootp and then you
> can expect more stability. For instance you can set up a root-path for
> your clients (NFS root) and then they will use that path. With DHCP,
> it seems a HOWTO author hadn't managed it (option root-path I guess).
> I don't know if it works because I can't try it for the reasons I've told,
> has anybody managed to use DHCP for a clean nfs root setup?

No, haven't gotten around to trying that.

> Third, there is the boot rom / netboot disk issue. There's netboot in debian
> but etherboot is lacking. I'll go ahead and package it if nobody has a plan
> to do it. There is also this non-free imggen utility which makes it possible
> to use some of the boot roms. (what was it called lanworks or what?)
> Anyway, that one should be packaged (if it can be distributed), too.

Sure, sounds fun.  Doesn't etherboot the packet driver stuff and
requires custom compilation based on the needed packet driver?  You'll
need to check the copyright of the packet drivers as well.

> Of course, all of these are important for the new installer because at
> some point we will have to devise an "installation server" for non-interactive
> installation over the network. netboot is an important part of that process.
> We'll have to support both net-boot methods and a "magic floppy" approach.
> Well, we already have some sort of a magic floppy ;) But it looks like
> we'll need to spend some thought on the interaction between the server
> and the client (that is the machine to install). 

Yes, that would be nice.   I think I could pretty easily add a
boot-floppies secondary package created during the process that let
you install it and have a boot server for i386 machines, or sparcs, or

.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>

Reply to: