Matthew Palmer <[EMAIL PROTECTED]> writes: > I've just been trying out the new Linux bootdisk with Unattended > 4.0b, and it rocks longer and harder than ever.
Thanks! Allowing DHCP options has been a goal from the beginning. Thank you for doing the legwork on this. > From the manpage, it appears that udhcpc will pass the value of the > option 'root-path' to the DHCP client script (/etc/udhcpc-script in > Unattended) as $rootpath. Unfortunately, from my testing I don't > think that udhcpc requests the root-path option, and I've not > managed to work out how to tell udhcpc to ask for it, and dhcpd2 > doesn't send it out by default and I can't work out how to force it > to do so. I think we can fix this with a one-line patch to udhcp. "root-path", eh? Let's see, http://www.faqs.org/rfcs/rfc2132.html ... section 3.19 ... Here we are: 3.19. Root Path This option specifies the path-name that contains the client's root disk. The path is formatted as a character string consisting of characters from the NVT ASCII character set. On the one hand, this is not exactly what we have in mind. On the other hand, I doubt Windows machines normally use this option. So unless you are using the option in a dual-boot environment, it should not cause any problems. (And you can always use the kernel command-line parameter to override the DHCP option.) So maybe. We also need a way to specify the username and password. We can either steal some "local" DHCP options (128-254) or we can use vendor encapsulated options. I am inclined to do the former because it is easier to implement. We have to decide which local option identifier(s) (between 128 and 254) to steal. It looks like some of them are already in "unofficial" use; e.g., 135 is used by BpBatch. Hm. If we are going to steal a local DHCP option anyway, maybe we should only take one but give it this syntax: z_user=... z_pass=... z_path=... That is, it would have the same syntax as the current kernel command-line options. This 1) avoids abusing the "root path" option, 2) only consumes one local option, and 3) is easy to extend. I think this is what I will do. Give me a day or two. > (Please excuse the dodgy "patch" format, but I'm hacking on this on > another machine in the ramdisk because I haven't gotten around to > setting up a bootdisk foundry yet). Excuses, excuses. Thanks again for the research and ideas. - Pat ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ unattended-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unattended-devel