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

autopkgtest-build-lxd failing with bionic

Steve Langasek [2018-02-16 11:12 -0800]:
> > >   [ -n "$(ip route show to 0/0)" ]
> > This is better though, and works too. Please take a look at the attached
> > patch. Thanks! :-)
> Actually no, this is racy, because the route comes up before DNS resolution
> is in place.

I'm not actually sure if network-online.target would actually guard against
that with all implementations. But in practice, in most cases you'll get DNS
either via static configuration (in which case there's nothing further to wait
for) or via DHCP (in which case your address and DNS solvers ought to arrive at
the same time). And there's still the "apt retries several times" fallback
(which is why I do see the initial apt failure, but the retry works).

> It's also not forwards-compatible with ipv6-only deploys.

Right now the container network config created by lxc/lxd/netplan assumes IPv4
only, so let's cross that bridge when we get to it. Indeed adding an
alternative `ip -6 show...` would easily rectify that.

> I think the network-online.target is the better thing to key on.

I still don't like that much, though:
  -  there is no requirement that this actually gets "implemented" or even
     started (it's a passive target)

  - it's supposed to be a SysV backwards compat shim for LSB's "network"
    dependency, and not well-defined

  - These tools should also work with Debian containers, which in theory could
    also run sysvinit. This is also the reason why they still use `runlevel`
    instead of `systemctl is-system-running` or something similar.

All of these are just heuristics, though; you could have all sorts of cases
where all of these break, like sharing the host's network namespace, having no
default route but a route to the configured apt proxy, etc. Maybe the closest
approximation to this would be to grab the archive URL from
/etc/apt/sources.list and put it in a curl loop, but (1) neither wget nor curl
are in minimal installs, and (2) at that point it could just as well be an
apt-get retry loop.

So in summary, IMHO the "wait for default route" heuristics is simple and
effective enough for now.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/autopkgtest-devel/attachments/20180220/aedf4286/attachment.sig>

Reply to: