autopkgtest-build-lxd failing with bionic
Hi,
[ I've dropped ubuntu-devel ]
On Fri, Feb 16, 2018 at 08:15:35PM +0100, Julian Andres Klode wrote:
> On Fri, Feb 16, 2018 at 11:12:32AM -0800, Steve Langasek wrote:
> > [?? ]
> > Actually no, this is racy, because the route comes up before DNS resolution
> > is in place.
> >
> > It's also not forwards-compatible with ipv6-only deploys.
Fair point. I could add an `ip -6' equivalent.
> > I think the network-online.target is the better thing to key on.
Ho hum. Well then, I've now made patches for both ways. Can you and
pitti please decide what is actually better between you? I'll not bother
writing any more code until then. :-)
BTW, while I experience a network-is-not-up race most times in current
autopkgtest, I didn't experience it at all with pitti's suggestion so at
least for me the race is won all of the time. I'm not sure if
network-onilne.target's semantics are enough for this either?
> I think we should just grep the apt output and retry if it fails with
> connection error messages. This should be fine until I have an improved
> solution in apt itself, one of
>
> (1) "there are no transient errors"
> (2) one source must have updated
> (3) all sources must have updated
>
> Not sure on details. Could be an option for all three.
autopkgtest calls apt all over the place. Some of them are covered by
retry loops already, but I'm not super excited about hunting down the
rest until we can do it in a clean way or, even better from my POV, if
apt were to retry itself a few times before giving up.
It seems sensible to me to try not do work until we think the network is
"up" enough to contact our apt sources anyway.
Cheers,
--
Iain Lane [ iain at orangesquash.org.uk ]
Debian Developer [ laney at debian.org ]
Ubuntu Developer [ laney at ubuntu.com ]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/autopkgtest-devel/attachments/20180219/8d6738d7/attachment.sig>
Reply to: