Sounds like a good idea. As you say, the PXE boot will have already used the next-server:/filename DHCP extensions to download the next-stage installer (PXElinux / d-i / whatever). Overloading the filename parameter seems like a recipe for disaster; sure, we can return a vendor-ID-based value, but vendor-specific replies is a bit of a faff. IIRC, PXELinux gets around this by looking for a configuration file in a standard subdirectory on the next-server (could be "/pxelinux", I don't have a machine handy). The filename is the hex-encoded version of its IP address (e.g. 192.168.1.1 == "C0A80101"). If this fails, then the least significant bytes are successively zero-ed out (simulating different common subnet masks) until it tries "default" as a filename (instead of "00000000"). Grub, on the other hand, uses a specific tag (150) to store the location of its config file. On the face of things, this seems in violation of RFC2939. But, if there's no way of registering new tags ... Those, I think, are our three options. Personally, I'd go for the third one, if we can do it without violating RFC2939. Failing that, having a standard filename (perhaps cascading, like PXELinux) might be OK. HTH, Paul. On Tuesday 30 November 2004 08:12, Joey Hess wrote: > Since it looks like hppa automated installs cannot be done with a > preseed url in the kernel boot parameters, due to size > restrictions, I took at look at ways to deliver the information > about preseeding via dhcp. > > First, how kickstart does it: I was under the impression before > that kickstart allowed specifying the kickstart file to use in the > dhcp configuation, and that this would work with PXE booting. Well, > sort of. Kickstart will look at the dhcp next-server and filename > fields in the dhcp response, and try to use something like > next-server:/filename (nfs) as the kickstart file. However, I don't > see how this can be used for PXE booting, since we need filename > there to point to the file to boot, and if next-server is set, it > is used as the tftp server. The filename field is also used when > netbooting sparc, hppa, etc. So overloading it to be used for > preseeding doesn't seem good. In fact all the kickstart pxe boot > setups I've found specify the kickstart file via a ks= kernel boot > option to avoid this. > > Next I looked at the dhcp rfcs. The dhcp options seemed like the > obvious way to get an url passed from dhcp to d-i. I looked at > using option 43, the vendor defined option, since its use is quite > close to how d-i would work. However, at least the debian dhcp > package does not allow option-43 in dhcpd.conf. > > We could pick an option in the 128-254 range and use it, but we > might be violating rfc2939 by doing so, since it requires that > these "MUST NOT be defined for use by any publicly distributed DHCP > server, client or relay agent implementations". I'm not sure how > much wiggle room there is in "client" -- it's not like d-i's dhcp > client would know about the option, though d-i would, and we'd have > to put something like "request option-nnn" in dhclient.conf. > There's always the potential that whatever private use option > number we choose will be used at some installation site for > something else. > > We could add a boot option to make d-i look at a particular dhcp > option for preseeding, and leave it up to the admin. > preseed/dhcp_opt=128. This might still run out of kernel command > line space on hppa (it's very small) and it's a lot of layers of > indirection to get to the preseed file. > > We could go through the process to get an option numer assigned by > iana. I don't have the time or the patience, but if someone does > this is probably the best way.
Attachment:
pgp5jEjht4b2w.pgp
Description: PGP signature