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

Bug#700292: netcfg/choose_interface=auto fails to select eth1 when eth0 has no link



On 24/04/15 at 09:38 +0200, Lucas Nussbaum wrote:
> On 18/02/13 at 07:28 +0800, Paul Wise wrote:
> > On Sun, 2013-02-17 at 23:24 +0100, Philipp Kern wrote:
> > 
> > > Now I'm not sure why we're checking for a link in netcfg_autoconfig
> > > again without error handling, but why does it try the wrong ifname in
> > > the first place? In the auto selection process we should've picked
> > > one earlier that had a link already in GET_INTERFACE.
> > 
> > If you or anyone else needs a way to test this, you can use a libvirt
> > based virtual machine and run this command after setting up the VM:
> > 
> > virsh domif-setlink <machine> <mac> down --persistent
> 
> Hi,
> 
> I'm hit by this bug. My case is simple: two interfaces, only one with link (and
> netcfg correctly detects the link only on one interface, so the expected
> behaviour of "just pick up the interface with the link" would work).
> 
> So the known workaround for this bug is:
> Still set:
>   d-i netcfg/choose_interface select auto
> add "IPAPPEND 2" in debian-installer/amd64/boot-screens/adtxt.cfg, so
> that it looks like:
> 
> label auto
>         menu label ^Automated install
>         kernel debian-installer/amd64/linux
>         append auto=true priority=critical vga=788 initrd=debian-installer/amd64/initrd.gz --- quiet
>         IPAPPEND 2
> 
> However, even with that, it doesn't select automatically the bootif interface:
> - I get BOOTIF=<mac> in /proc/cmdline
> - the installer detects it (I get the "Found interface eth2 with link-layer address <mac>)
> - but I still get prompted for the interface
> 
> After booting with DEBCONF_DEBUG=developer DEBCONF_DEVELOPER=debug (Cyril
> wasn't sure which one was working), I see that:
> - netcfg/choose_interface gets SET to eth2: Intel Corporation [.... rest of desc]
> - I see the SUBST netcfg/choose_interface ifchoices eth2: [desc], eth3: [desc]
> - I see the INPUT critical netcfg/choose_interface
> 
> So I think that the bottom line is: why did I get prompted by this INPUT since
> netcfg/choose_interface was already SET before? Shouldn't the priority be lower
> than critical?
> 
> For reference, the code is in netcfg-common.c, in netcfg_get_interface.
> The corresponding code for the input is:
> 
>     else if (num_interfaces > 1) {
>         *numif = num_interfaces;
>         /* remove the trailing ", ", which confuses cdebconf */
>         ptr[strlen(ptr) - 2] = '\0';
> 
>         debconf_subst(client, "netcfg/choose_interface", "ifchoices", ptr);
>         free(ptr);
> 
>         asked = (debconf_input(client, "critical", "netcfg/choose_interface") == CMD_SUCCESS);
>         ret = debconf_go(client);
> 
>         /* If the question is not asked, honor preseeded interface name.
>          * However, if it was preseeded to "auto", or there was no old value,
>          * leave it set to defif. */
>         if (!asked && strlen(old_selection) && strcmp(old_selection, "auto") != 0) {
>             debconf_set(client, "netcfg/choose_interface", old_selection);
>         }
> 
>         free(old_selection);
> 
>         if (ret)
>             return ret;
> 
>         debconf_get(client, "netcfg/choose_interface");
>         inter = client->value;
> 
>         if (!inter)
>             netcfg_die(client);
>     }
> 
> 
> I also tried with "d-i netcfg/choose_interface select eth2" and BOOTIF in
> /proc/cmdline, and I still get prompted.
> 
> With "d-i netcfg/choose_interface select eth2" and no BOOTIF in /proc/cmdline,
> I also get prompted! So this is more severely broken than I thought.

After encountering this problem again, I understood something that
wasn't clear to me before (but is quite obvious when you think about
it).
What you put in the preseeding file has no effect for network detection
(at least in the case where this file is fetched over the network).

For me, setting netcfg/choose_interface=auto on the kernel command-line
(in amd64/boot-screens/adtxt.cfg, in my case) did the trick.

So it's possible that this bug could be closed, but I wasn't the
original submitter. Paul, do you have a way to check again?

Lucas


Reply to: