Paul Millar wrote: > 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. One thing we could do is append something to the filename, so d-i would try to tftp down files from /pxelinux.0.preseed/ using the same set of schemes for finding host-specific files as does pxelinux, or just looking for /prxlinux.0.preseed/$hostname. Only problem is that we'd need a tftp client in d-i. -- see shy jo
Attachment:
signature.asc
Description: Digital signature