← Back to team overview

touch-packages team mailing list archive

[Bug 1524452] Re: TrustyTestNetwork boots with cloud-init-nonet timeout

 

So unless ifup/ifdown brings the aliases up/down itself, I don't think filtering those out is the right fix.
Take this scenario as an example:
 - System boots quickly
 - networking.conf kicks in, fails to bring eth0 because it's not showed up yet (happen reasonably often with complex blade systems)
 - network-wait kicks in
 - eth0 does show up
 - interface is brought up but not the eth0:X ones

The interface labeling thing isn't as cool as it used to be and most
people just add multiple IPs on the same interface nowadays, it used to
be that ifconfig and other tools were confused by that, but they're not
anymore.

Anyway, I guess people are still using that feature and so it's probably
worth fixing. The fix I'd suggest is to do something similar to the
bridge-utils and vlan udev hooks, that is, have a udev hook which
triggers on new interfaces, have the hook use ifquery to check for
downstream interfaces (INTERFACE:X) and then bring those up.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
https://bugs.launchpad.net/bugs/1524452

Title:
  TrustyTestNetwork boots with cloud-init-nonet timeout

Status in ifupdown package in Ubuntu:
  Confirmed

Bug description:
  $ grep -ri "gave up waiting" --include "*-serial.log" output.success1/
  output.success1/TrustyTestNetwork/logs/boot-serial.log:cloud-init-nonet[133.62]: gave up waiting for a network device.

  This reproduces with:
  ./tools/jenkins-runner -vv tests/vmtests/test_network.py:TrustyTestNetwork

  basically something is causing networking to not automatically come up
  there.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1524452/+subscriptions