Closed wsw70 closed 8 years ago
lxdbr0 is a new bridge that's being introduced, it has nothing to do with lxcbr0 and so doesn't get controlled by /etc/default/lxc-net.
That being said, the lxd-bridge init script should have started fine on your system, the "Permission denied" up there is a bit worrying. I wonder if it's because some kernel modules are failing to load dynamically or something on your system or something.
I'll try a clean Ubuntu 15.10 VM with the PPA later to see if I can reproduce it.
In the mean time, you can turn off lxdbr0 in /etc/default/lxd-bridge which should fix things for you.
I ran into a very similar problem, complete with the "RTNETLINK answers: Permission denied" error message. Some vigorous googling revealed that this might be due to IPv6. The top hit, an openstack post, recommends enabling ipv6 via sysctl's; for some reason, I had already made these sysctl.conf entries this before getting the error message:
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
I removed these sysctl entries, and while I now no longer have working outside networking (that's why I disabled IPv6 in the first place), I now have a working lxdbr0
interface and lxc list
doesn't hang anymore. I suppose that might have been the thing that triggered the hang for me.
@stgraber Thank you - editing /etc/default/lxd-bridge
fixed the issue. I did not realize that lxdbr0
is a new bridge (the names are somehow similar :))
@antifuchs I also have IPv6 disabled (with the same commands as you do). The solution/workaround by @stgraber fixed the issue for me, without the need to re-enable IPv6.
Thanks for the confirmation, @wsw70! Sounds like we've found the environmental factor that causes this. I found an alternative that works for me: Just disable IPv6 on the physical network interfaces themselves, not on default
, or all
(or lo
, no idea why I did that).
Either solution works on my machine & I can now use lxc commands again (-:
@antifuchs oh, that's very interesting, I will do some tests with ipv6 disabled and adapt our scripts to cope with that.
@stgraber sorry, I may not have been clear enough: I had IPv6 disabled as well and did not need to modify this setting (= I keep IPv6 disabled) when applying your fix.
@wsw70 yes, that's what I would expect. But what @antifuchs said suggests that if you wanted to actually use lxdbr0, that wouldn't work with IPv6 disabled, which is a bug.
Required information
There are two containers bridged to my own bridges (br1 and br2).
lxdbr0
is no tused (though it appears in one log, see bottom of this report)Issue description
After an update of lxd and lxc yesterday (from the standard Ubuntu repository)
lxd
fails to start. It needs to be manually restarted viaservice lxd stop ; service lxd stop
- everything comes back to normal after this step. Before the update the exact same configuration was working perfectly.Steps to reproduce
lxd
does not work, no containers are mounted, syslog info attached below# service lxd stop ; service lxd stop
Information to attach
dmesg
boot portion:dmesg
portion upon manual restart of lxdThe containers start fine after
lxd
restart. I can attach the log if neded.Not sure how to do that on a running client / server?
/var/log/syslog
After reboot, the log is full of lines as follows:
Upon restart of
lxd
journalctl -xe
shows the following errors after boot:I do not understand how
lxdbr0
comes into the picture as it is disabled in /etc/default/lxc-net