This bug was fixed in the package systemd - 237-3ubuntu10
---
systemd (237-3ubuntu10) bionic; urgency=medium
* Create tmpfiles for persistent journal in postinst only when running
systemd (LP: #1748659)
-- Balint Reczey Fri, 20 Apr 2018 18:55:56 +0200
** Changed in: systemd
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: systemd (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1765173
Title:
ne
The semantics of systemd-networkd-wait-online.service are that the
service is ready when "the Internet" is reachable. In the past, the
implementation of network-online.target has been less correct on Ubuntu,
*because* ipv6 RA was handled asynchronously, and this target did not
block waiting to fin
The default will remain, implicit, RequiredForOnline=yes. And it will be
up to netplan / cloud metdata / cloud-init, to pass via netplan whatever
the right syntax there needs to be to tell networkd that
RequiredForOnline needs to be relaxed for ipv4, or ipv6, or for the
whole interface altogether.
NetworkManager I believe already supports settings if ipv6/ipv4 should
be attempted, and whether or not ipv4/ipv6 needs to be considered for a
networkmanager-network to be considered up.
networkd wise, I am currently inclined to extend following options passed to
RequiredForOnline=no|ipv4|ipv6|ye
I disagree that SLAAC is something that we should by default block reaching
network-online.target.
In general we cannot know in advance whether or not another system in the same
subnet is providing Router Advertisements to other instances.
If one instance in my VPC is running radvd, ec2 has n
I am wary of any design decision in netplan that fundamentally
prioritizes ipv4 over ipv6. I'd like to suggest the following working
definition of network-online.target:
- all "non-optional" interfaces have an address configured for at least one
address family or have timed out, and
- there is
Addendum: we also need to be sure that the DNS server address is one
that we have a route for. It does no good to start trying to talk to
the DNS server if the DNS address is IPv4 but we only have routes for
IPv6.
--
You received this bug notification because you are a member of Ubuntu
Bugs, whi
I don't think not blocking for RAs during boot as a decision that
prefers ipv4 over ipv6. networkd is just doing something else by
default that the kernel doesn't do today, or historically; *and* there
is no toggle for the blocking; only do you want RAs or not *and* if you
say you don't want RAs i
in summary the consensus is as follows:
- cloud-init should not provide accept-ra key to netplan.io
- netplan.io should not emit any accept-ra keys to networkd
- networkd, when not receiving any accept-ra keys should use kernel implicit
default
- networkd, when in implicit RA mode, should not blo
** Description changed:
+ [Impact]
+
+ * On ipv6 less hosts, boot stalls for 10s
+ * This is due to implicit RA being on, and wait-online awaiting for RA to
timeout
+ * Expectation is, that since explicit request for RA was not done, it should
not block network-online.target, whilst all othe
Test PPA is available at $ sudo add-apt-repository ppa:ci-train-ppa-
service/3243
** Changed in: systemd (Ubuntu)
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/b
I've given this a test in LXD on my system which triggers the RA stall;
after upgrading it does not wait for an RA before marking the interface
configured and also confirmed that it does not regress the case where
there are existing RA's on the network; those are still received. Note
that we see e
13 matches
Mail list logo