#766291 ifupdown: doesn't bring up dhcp interfaces on boot, when these are set allow-auto

Package:
ifupdown
Source:
ifupdown
Description:
high level tools to configure network interfaces
Submitter:
Christoph Anton Mitterer
Date:
2014-12-06 23:51:16 UTC
Severity:
important
#766291#5
Date:
2014-10-22 00:35:05 UTC
From:
To:

Hi.

This kinda feels like the other evil twin sibling from #727073:

What I have is a VM that runs on qemu/libvirt with Debian sid
(everthing updated as of now).

The /e/n/interfaces was a simple plain:
allow-auto      lo
allow-hotplug   eth0
iface lo inet loopback
iface eth0 inet dhcp

The VM is basically my template for any other server I set up.
Because of this, and because of #727073, I've changed the
allow-hotplug to allow-auto as well, since that seems the only
solution right now for using it on servers with statically
configured IPv6 addresses.


After the change, I noted that the networking of the VM no longer
works (after the first reboot).

It seems that eth0 isn't brought up anymore *at all* (which
is in contrast to #727073, which brings stuff up, but just "too
late" - therefore also the new ticket).

But it seems again to be some timing issue between when ifupdown
tries the ifup, and when the DHCP of the VM is ready (even
though I'd expect that to be ready much earlier).

Or maybe I have just some complete misunderstanding of allow-*.


Any help on how to even debug this, would be appreciated. :)


Cheers,
Chris.


PS: If you need further data, then of course ask and I'll write it.
#766291#10
Date:
2014-11-08 00:53:04 UTC
From:
To:
Hey.

There's also that issue:#768514

It's smells after one of these three bugs here (#766943, #727073 and
#766291), but OTOH, the 30s sleep ugly workaround is still in place
right now, and all other daemons can bind to their addresses,... bind9
however can not and fails at start.


Cheers,
Chris.
#766291#15
Date:
2014-12-04 04:04:48 UTC
From:
To:
This should be fixed by 0.7.50, right? Can you please test again and
report back.
#766291#20
Date:
2014-12-06 23:47:35 UTC
From:
To:
fixed 766291 0.7.50
fixed 727073 0.7.50
stop

Hi Michael.
Yes it's "fixed/workarounded".

The same also applies to #727073, which his fixed by 0.7.50 as well.

I'm not sure whether we should close this bug now, since the udevadm
settle is only intended to be a temporary workaround, right?
So maybe it would be good to keep those bugs open and just marked fixed
in versions xxx (which I did above), so that once we properly get rid of
the udevadm settle, all these issues can be checked back again.

Cheers,
Chris.