[7835] in athena10
Re: [Debathena] #960: Make the stage1 iPXE instead of Linux
daemon@ATHENA.MIT.EDU (Debathena Trac)
Tue Jul 12 10:59:05 2011
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
From: "Debathena Trac" <debathena@MIT.EDU>
Cc: debathena@mit.edu, oremanj@mit.edu
To: geofft@mit.edu
Date: Tue, 12 Jul 2011 14:58:57 -0000
Reply-To:
Message-ID: <052.7bfbbf3740f9ff7a1729207eb9ebfe1f@mit.edu>
In-Reply-To: <043.bcc6579dc25fb2a180fd78d6bb7e3c49@mit.edu>
Content-Transfer-Encoding: 8bit
#960: Make the stage1 iPXE instead of Linux-------------------------+--------------------------------------------------
Reporter: geofft | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: The Distant Future
Component: -- | Keywords:
See_also: |
-------------------------+--------------------------------------------------
Comment(by geofft):
Looked a bit more at this.
Josh says that we can keep the same DHCP IP address/lease if we tell iPXE
`set use-cached 1` before running dhcp, and if we use the undionly.kkpxe
(not .kpxe) build of iPXE (see also his [http://lists.ipxe.org/pipermail
/ipxe-devel/2011-May/000687.html comment to the same effect on ipxe-
devel]). Since DHCP is generally slow, this would be a win.
I've built an [http://debathena.mit.edu/ipxe/undionly.kkpxe
undionly.kkpxe] with the EMBED parameter pointing to a script that does:
{{{
#!text
#!ipxe
set use-cached 1
dhcp
set dns 18.70.0.160
chain http://debathena.mit.edu/ipxe/boot
}}}
This works, as evidenced by "kvm -boot n -net nic -net
user,tftp=/mit/debathena/web_scripts/website/ipxe,bootfile=/undionly.kkpxe".
So if we give this undionly.kkpxe to Network and tell them to call it the
Debathena option, we can chainload our own stuff on the other end.
Note that we don't actually want to give this particular copy. Apart from
wanting to build it on the build server in some reasonable way, current
iPXE doesn't support multiple DNS servers. I'd like to add that support
before we deploy this.
Also, as the name would imply, undionly.kkpxe includes only the UNDI
drivers, and it might be nice to build in some native drivers for common
cluster hardware. But Josh tells me that use-cached won't work with native
drivers, so this requires a second DHCP request. This doesn't strike me as
a fundamental limitation, though... still, we should see if UNDI works
well enough on the hardware we care about or not, before caring.
Obviously we also need to write a better iPXE script that does what we
want, too...
-- Ticket URL: <http://debathena.mit.edu/trac/ticket/960#comment:1>Debathena <http://debathena.mit.edu/>MIT Debathena Project
