Closed basak closed 3 months ago
LXD 4.0.x is currently in security maintenance mode only. It won't be getting updates to support newer guest containers I'm afraid. Please can you switch to the latest LTS which is 5.21/stable.
Its could be an issue with cgroupv2 not being present on the host, which the newer image expects.
It won't be getting updates to support newer guest containers I'm afraid.
In that case, any chance we can predict the failure and refuse to launch such an image please, rather than fail in unpredictable ways afterwards?
Please can you switch to the latest LTS which is 5.21/stable.
I can do that, but I'm trying to use lxd to implement stable builds for git-ubuntu users, and I can't control what lxd they are running or change it. Is there any way I can detect that it's not going to work in advance, please, so I can give the user a useful error message?
In that case, any chance we can predict the failure and refuse to launch such an image please, rather than fail in unpredictable ways afterwards?
That would require feature development which is no longer occurring for the 4.0.x series.
We plan one more release to update the default remotes to the new image server and then its critical security fixes only.
I can do that, but I'm trying to use lxd to implement stable builds for git-ubuntu users, and I can't control what lxd they are running or change it. Is there any way I can detect that it's not going to work in advance, please, so I can give the user a useful error message?
Because containers share the host kernel and the cgroup layout, its a function of the host + container guest as to whether they function together. The big change was the switch to unified cgroups (cgroupv2) that mean running newer guests on older hosts upset some systemd services because they heavily rely on cgroups.
Does ubuntu:focal
work for you on a Focal host with LXD 4.0?
Does ubuntu:focal work for you on a Focal host with LXD 4.0?
Yes that works fine. But it doesn't solve the general case of wanting to use lxd in defaults on (eg) an LTS release with the Ubuntu development release in a container to do builds.
I'll file a separate issue for the general case - thanks.
Required information
Issue description
When I boot
images:debian/sid
(image fingerprint67e221357f18
), networking does not run in the guest. I see local link IPv6 addresses but no IPv4 address configured. I assume it's supposed to work with networkd since/etc/systemd/network/eth0.network
exists, but systemd-networkd is not running.I tried the same thing on a 24.04 host with lxd snap 6.1-0d4d89b and it works fine, so I assume this is an issue either with the older lxd or the older host OS.
A brief description of the problem. Should include what you were attempting to do, what you did, what happened and what you expected to see happen.
Steps to reproduce
security.nesting=true
(I'm using this because I'm also trying to use Oracular containers on this host system.lxc launch images:67e221357f18 ns
lxc exec ns bash
ip a
, wait a while, retry, etc.Expected results: IPv4 configured. Actual results: IPv4 is not configured.
NOTE: taking other actions inside the container seems to result in socket activation of systemd-networkd, and that fixes things. So does waiting about five minutes. In my test,
systemd status systemd-networkd
reports that the service started 6m43s after I started the instance. My issue is that automated use expects networking in the container to come up promptly with no further action.Information to attach
dmesg
)lxc info NAME --show-log
)lxc config show NAME --expanded
)The only relevant line seems to be:
I've skipped the following since it's trivially reproducible on a fresh Focal VM.
lxc monitor
while reproducing the issue)