ok sounds like this needs to be addressed in netplan.
** Package changed: systemd (Ubuntu) => nplan (Ubuntu)
** Changed in: nplan (Ubuntu)
Importance: Undecided => High
** Changed in: nplan (Ubuntu)
Status: Incomplete => Triaged
** Changed in: nplan (Ubuntu)
Assignee: (unassigned
Finally found a work-around that also proves the failure to become
configured is caused by that stupid ipv6ll address added to the DNS
server list. But I did not find any way which integrates into netplan. I
basically took /run/systemd/network/10-netplan-br0.network and copied it
as /etc/systemd/ne
So that link local is from a Wireless AP that runs open-wrt. But why it
is picked up and how can I stop this madness?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1697730
Started to bring up real HW with the same woes and timeout on boot.
After some more cursing and faffing around I realized an odd element of
the resulting setup:
There is some weird ipv6 link local address for DNS server:
fe80::c66e:1fff:fe3b:bdcd. It is the same for the VM doing dhcp and for
real
On Wed, Jun 14, 2017 at 05:58:06PM -, Ryan Harper wrote:
> This is a known issue w.r.t waiting for IPV6 LL, on Xenial KVM, qemu -net
> user does not provide IPV6 LL response (yakkety and newer do), so there's a
> delay; it does sound like the IPV6 LL timeout is longer than it used to be
> as I
This is a known issue w.r.t waiting for IPV6 LL, on Xenial KVM, qemu -net
user does not provide IPV6 LL response (yakkety and newer do), so there's a
delay; it does sound like the IPV6 LL timeout is longer than it used to be
as I've seen a 5 to 10 second delay in VMs launched on KVM on xenial, but
So from what Steve wrote and what I see. the missing part is moving from
"Gained IPv6LL" to "Configured".
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1697730
Title:
Lon
@Ryan:
2: eth0
Link File: /lib/systemd/network/99-default.link
Network File: /run/systemd/network/10-netplan-eth0.network
Type: ether
State: routable (configuring)
Path: xen-vif-0
Driver: vif
HW Address: 00:16:3e:71:31:57 (Xensource, In
I noticed one difference between our configs was that you did not have
public ipv6 set up. I shut down radvd on my router and rebooted as a
test; this seems to cause a slight delay at boot (long enough for
systemd to send a message warning that it's waiting for the network to
be configured), but t
What does your networkctl status eth0 show?
On Wed, Jun 14, 2017 at 11:34 AM, Ryan Harper
wrote:
> It looks a lot like this issue:
>
> https://github.com/systemd/systemd/issues/1645
>
> Where DHCP works, it has an ip and can sync time and other items, but the
> wait service isn't happy.
>
> On W
It looks a lot like this issue:
https://github.com/systemd/systemd/issues/1645
Where DHCP works, it has an ip and can sync time and other items, but the
wait service isn't happy.
On Wed, Jun 14, 2017 at 10:46 AM, Steve Langasek <
steve.langa...@canonical.com> wrote:
> The journal shows, two min
Fresh install of an artful-server image in a VM, and I can't reproduce
this problem. For some reason, on your system networkd never logs that
the network interface has been 'configured'. So in fact, systemd-
networkd-wait-online is behaving correctly; you're somehow just never
getting the OK from
Hm, maybe that helps. This is the contents of /run/systemd/netif/links/2
(which is my eth0):
# This is private data. Do not parse.
ADMIN_STATE=configuring
OPER_STATE=routable
NETWORK_FILE=/run/systemd/network/10-netplan-eth0.network
DNS=192.168.2.1 fe80::c66e:1fff:fe3b:bdcd
NTP=
DOMAINS=
ROUTE_DOM
@Steve, eth0 is normal when you use Xen HVM guests. What I see when I
strace the wait command is that is is in some epoll most of the time.
That was the reason I was thinking that maybe it is waiting on some
status change. But then I also believe it did find two entries in
/run/systemd/netif/links
The journal shows, two minutes after the start of the wait-online job:
Jun 14 00:11:42 bar-artful6401 systemd-networkd-wait-online[618]: Event loop
failed: Connection timed out
Jun 14 00:11:42 bar-artful6401 systemd[1]:
systemd-networkd-wait-online.service: Main process exited, code=exited,
sta
On Wed, Jun 14, 2017 at 10:04:28AM -, Stefan Bader wrote:
> Sorry, forgot above:
> #> cat /run/systemd/network/10-netplan-eth0.network
> [Match]
> Name=eth0
> [Network]
> DHCP=ipv4
> [DHCP]
> RouteMetric=100
I know you say this is also reproducible for you when using ensX names, but
for co
This is annoying:
% journalctl -D var/log/journal -o short-precise Journal file
var/log/journal/1fe5c5ed88c14c81bd52acb9f96f3a18/system.journal uses an
unsupported feature, ignoring file.
-- No entries --
Why can't xenial systemd journalctl read an artful one? That seems like a
terrible idea w.r
Sorry, forgot above:
#> cat /run/systemd/network/10-netplan-eth0.network
[Match]
Name=eth0
[Network]
DHCP=ipv4
[DHCP]
RouteMetric=100
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpa
Here the netcat config. Note only eth0 appearing here (for KVM guests,
the same happens but with ensX NIC names).
** Attachment added: "01-netcfg.yaml"
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1697730/+attachment/4895673/+files/01-netcfg.yaml
--
You received this bug notificati
I created the directory and rebooted once ;) Here is the tarball.
** Attachment added: "journal.tgz"
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1697730/+attachment/4895674/+files/journal.tgz
--
You received this bug notification because you are a member of Ubuntu
Touch seeded pac
@Steve, yes it does. And if the wait is related to the list of NICs from
ifquery, it does make sense (in some way) as that list only contains
"lo", not "eth0". Also "ifquery --state eth0" does not return anything
while it does return "lo=lo" for "lo".
--
You received this bug notification because
Is this delay reproducible post-boot if you run '/lib/systemd/systemd-
networkd-wait-online' from the commandline?
** Changed in: systemd (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed
And what about /etc/netplan/*.yaml
and /run/systemd/network/*
If you can attach the journal binary file, we can query the state
independently from you
tar up /run/log/journal/
Thanks
On Tue, Jun 13, 2017 at 11:33 AM, Stefan Bader
wrote:
> #> ifquery --list
> lo
>
> #> ip link show
> 1: lo:
#> ifquery --list
lo
#> ip link show
1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: mtu 1500 qdisc mq state UP mode
DEFAULT group default qlen 1000
link/ether 00:16:3e:71:31:57 brd ff:ff:f
** Changed in: systemd (Ubuntu)
Milestone: None => ubuntu-17.10
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1697730
Title:
Long boot time due to systemd-networkd-wa
25 matches
Mail list logo
