On Friday 07 December 2007, Joey Hess wrote: > dann frazier wrote: > > * Modify cdebconf to support multi-line choice fields. Make each > > interface choice be a multi-lined option that includes things like > > vendor, model, mac, slot. > > eth0: foo bar description, eth0: mac address: xxx:xxx... [slot 1] > > That would be one way to do it without modifying debconf. You could also > get rid of the "eth0: " prefix if you wanted to by using Choices-C. I'm probably just being thick, but what exactly are you proposing here? Having the description and then having other details behind that on the same line separated by a comma obviously will not work as most of it will just be truncated as it's over the screen width. What I have been thinking of is allowing to switch between the two: ================================================== eth0: regular description A eth1: regular description B eth2: regular description B Show interface MAC address and slot information (select this line) ================================================== eth0: xx:xx:xx:xx:xx:xx [Slot Q] (+ other info?) eth1: yy:yy:yy:yy:yy:yy [Slot R] eth2: zz:zz:zz:zz:zz:zz [Slot S] Show interface description ================================================== This could be done with existing debconf. > Although while all these controls and detail can be nice, I'd generally > prefer that d-i just figured out which nic has link and a dhcp server > and got on with it. We already have the test for the link (although I'm not sure that it works in all cases). Any ideas on how to test for a dhcp server in netcfg? Maybe using something like dhcping on all NICs where a link is detected? One problem is that the available version of dhcping requires a specific server as target and we'd really want to do a broadcast. # dhcping -r -h 00:16:76:04:ff:09 no answer # dhcping -r -h 00:16:76:04:ff:09 -s elrond Got answer from: 10.19.66.2 Although it can be tricked (but then returns with error 1): # dhcping -r -h 00:16:76:04:ff:09 -s 255.255.255.255 Got answer from: 10.19.66.2 received from 10.19.66.2, expected from 255.255.255.255 no answer You'd then also still need to solve the case where you get replies from different (sets of?) dhcp servers on different NICs, and of course the case where there is no dhcp server still needs to be handled without too much delay due to timeouts.
Attachment:
signature.asc
Description: This is a digitally signed message part.