*** This bug is a duplicate of bug 1714301 ***
https://bugs.launchpad.net/bugs/1714301
If you are looking for newer bug reports with this issue try
LP: #1717152
LP: #1728181
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
*** This bug is a duplicate of bug 1714301 ***
https://bugs.launchpad.net/bugs/1714301
** This bug has been marked a duplicate of bug 1714301
systemd-networkd hangs my boot (wireless)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
My part of this is resolved by the fixed for
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1714301
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1697730
Title:
Long boot time due to
** Tags added: id-597a82fe3afb3d970a8f04e5
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1697730
Title:
Long boot time due to systemd-networkd-wait-online.service failure
To manage notifications
I have an XPS 13 9350 and have this problem. I found that I had both
systemd-networkd and NetworkManager services enabled, but no
configuration for systemd-networkd in /etc/systemd/network, and no
configuration in /etc/netplan.
I noticed on a artful VM I had
Affected on ThinkPad X240 after upgrade from 17.04 when booting in an
environment with no known wifi networks. If a known wifi network is
available (and set accessible to all users) the boot time is more
reasonable.
--
You received this bug notification because you are a member of Ubuntu
Bugs,
Also affected on real hardware after upgrading from 17.04. Lenovo T450s.
Same messages as above.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1697730
Title:
Long boot time due to
Reproduced on a Dell XPS 13, latest generation.
At startup I have a 2+ min delay relating to this, syslog shows the same
messages as the OP.
I can run 'systemctl start systemd-networkd-wait-online.service' with no
problems post startup
--
You received this bug notification because you are a
I am also affected in real hardware. Running artful with a wireless and
ethernet card (there are also some docker bridges from some images that
don't run at startup)
I don't have any contents in /etc/systemd/network but I do in
'/lib/systemd/network'
After it times out I can run 'systemctl start
Hi, I'm also affected by this bug on real hardware (Lenovo Yoga 2 13
laptop), let me know if I can give feedback to help fix this bug.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1697730
Title:
Adding some random thoughts on this. First I finally was able to change
the AP configuration to not do IPv6RA. That solved the immediate
problem. But it was not straight forward to do and what other cases of
broken IPv6 setup there is in the wild.
One thing systemd-netword was doing wrong (imo)
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:
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
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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1697730
Title:
Long boot time due
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
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,
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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1697730
Title:
Long boot time due to
@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,
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
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
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
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
@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
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=
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,
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
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
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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1697730
Title:
@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
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
Bugs, which is
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
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
Bugs, which is subscribed to Ubuntu.
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
>
#> 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
** Changed in: systemd (Ubuntu)
Milestone: None => ubuntu-17.10
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1697730
Title:
Long boot time due to systemd-networkd-wait-online.service failure
36 matches
Mail list logo