[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#293682: netcfg/choose_interface has priority critical



Alex Mohr wrote:
> netcfg/choose_interface has priority critical, but the default in most
> cases is going to be fine.  Normally that wouldn't be a problem, but
> for unattended installs, asking this question is a problem.

Why do you think that the default will be correct? If a machine has more
than one interface then they're probably connected to different
networks, which are likely to need different setups, and likely only one
of them will connect to the internet. If both of them are plugged in or
the link detection is broken (it often is) then the installer can only
guess at which one is the appropriate interface to use.

> For what it's worth, preseeding the answer as in
> "d-i netcfg/choose_interface select auto" or passing a kernel
> parameter "netcfg/choose_interface=auto" does not stop the
> question from being asked.  (Using eth0 instead of auto doesn't
> help either).

Well it's a bit of a mess actually. I do think that you're doing
something wrong with your attempts at preseeding or entering that on the
command line since either will avoid the question; the seen flag is set
to true and the interactive question skipped as long as you set
netcfg/choose_interface to anything via any type of preseeding. Here's a
transcript from DEBCONF_DEBUG=5 of an install that I booted with
netcfg/choose_interface=eth1

Feb  8 18:05:13 frontend: --> SET netcfg/choose_interface eth1
Feb  8 18:05:13 frontend: <-- 0 value set
Feb  8 18:05:13 frontend: --> FSET netcfg/choose_interface seen true           
Feb  8 18:05:13 frontend: <-- 0 true
...
Feb  8 18:05:21 debconf: --> SUBST netcfg/choose_interface ifchoices eth0: BROADCOM Corporation NetXtreme BCM5703X Gigabit Ethernet, eth1: BROADCOM Corporation NetXtreme BCM5703X Gigabit Ethernet
Feb  8 18:05:21 debconf: --> INPUT critical netcfg/choose_interface
Feb  8 18:05:21 debconf: <-- 30 question skipped
Feb  8 18:05:21 debconf: --> GET netcfg/choose_interface
Feb  8 18:05:21 debconf: <-- 0 eth1

As you can see, seen flag gets set, question is skipped.

The messy bit is that sometimes preseeding it to "auto" will work and it
will make a reasonable try at choosing an interface, and sometimes it
will fail and try to use an interface named "auto". Or, if you set it to
a real interface name, sometimes it will use that interface, while
other times it may choose instead to use an interface it picks itself.

Currently, netcfg uses heuristics including link detection to try to
determine a default interface. If it succeeds, it sets
netcfg/choose_interface to that interface. If it fails,
netcfg/choose_interface is left alone. So we have four possibilities:

1. Default interface selection succeeded, interface preseeded to "auto:
	Netcfg will choose an interface, possibly even the right one.
2. Default interface selection succeeded, interface preseeded to "ethX":
	Netcfg will wrongly ignore the preseeded value and use the default
	interface it selected. Most people won't notice since it's
	fairly likely to be the same one they preseeded, but not always.
3. Default interface selection failed, interface preseeded to "auto":
	Netcfg will try to use interface "auto", and fail horribly.
4. Default interface selection failed, interface preseeded to "ethX":
	Netcfg will use the preseeded interface value.

I'm able to reproduce all four cases on two different machines; my ia64
can do link detection, while it fails on my proliant.

I think this will work in all cases:
	
	- Back up the value of netcfg/choose_interface.
	- Do default interface selection. If all the heuristics fail to
	  point to a default, use the first available interface as the
	  default.
	- Always set netcfg/choose_interface to the selected default.
	- Ask the question. If the question is not displayed, then
	  restore the old value of netcfg/choose_interface, unless the
	  old value was "auto", or there was no old value.

Seems to work for me anyway after as extensive testing as I can do.
I've put a patch for it in subversion.

-- 
see shy jo

Attachment: signature.asc
Description: Digital signature


Reply to: