Good call! I just installed the HWE kernel in focal, rebooted, and everything came back up normal.
Thanks!
Good call! I just installed the HWE kernel in focal, rebooted, and everything came back up normal.
Thanks!
Hey there! There’s no need to rollback. All I had to do was install the HWE kernel per @tomp’s suggestion and I was back up and running. Give it a try.
Good luck!
any good RTFM resources you could point me to ? Ubuntu kernel lifecycle and enablement stack | Ubuntu ?
You already got it but here’s the specific page for Focal:
https://ubuntu.com/kernel/lifecycle#installation-20-04
I did exactly as the guide says except for without the “–install-recommends”. Rebooted and voila!
I’m back up and running. thankyou all. my fault for not paying enough attention to my snap config for prod and pre-prod/test.
Glad those with ZFS 0.8 are back up and running with the Focal HWE kernel.
Those tracking the latest/stable
channel will always get the latest feature release of LXD, and over time (but especially at the boundary of a new LTS release) the minimum requirements for LXD will change.
With the LXD 5.21.0 LTS release as planned, we have now changed the default snap track from latest
to 5.21
. This is to ensure that those installing LXD by way of just doing snap install lxd
wouldn’t end up on the latest/stable
channel but would instead get the latest LTS channel (now set to 5.21/stable
).
We won’t remove support for specific ZFS versions during the lifecycle of an LTS release, so those following a particular LTS track will need to consciously refresh to a different track (i.e latest/stable
or a future LTS track) to get new features.
thankyou this will be a big help
I had to dowgrade from LXD 5.21 to 5.20 because I don’t have the right version of ZFS and I can’t upgrade the kernel right now. When downgrading, it will not start because database has been upgraded from version 69 to 73.
I managed to successfully downgrade LXD and the database with the following steps (use with caution):
snap list lxd --all
Name Version Rev Tracking Publisher Notes
lxd 5.21.1-43998c6 28155 5.20/stable canonical✓ disabled,held
lxd 5.20-f3dd836 27049 5.20/stable canonical✓ held
Revert to 5.20.
snap revert lxd --revision 27049
Stop lxd
snap stop lxd
Backup current database version 73
cp -a /var/snap/lxd/common/lxd/database/global ~/lxd-db-global-backup-20240411-version73
Restore database version 69
rm /var/snap/lxd/common/lxd/database/global/*
cp -a /var/snap/lxd/common/lxd/database/global.bak/* /var/snap/lxd/common/lxd/database/global/
snap start lxd
Thanks for this.
You may also want to hold the snap so it doesn’t auto update again
https://snapcraft.io/docs/managing-updates#pause-or-stop-automatic-updates-2
Another approach from @sdeziel1 is to bind mount a custom zfs loader script into the snap to force it to use the zfs 2.1 tooling even on an older kernel.
See https://github.com/canonical/lxd/issues/13319#issuecomment-2050343836
That is great. Worked for me.
You, good sir, have saved my bacon. I’m on Ubuntu 18.04 still with linux-hwe-5.4 and zfs 0.7.5 and today all my containers stopped working. Thanks to you, all is well again… and my scheduled hardware and software upgrade is hasten…
PS. Don’t forget to run snap refresh --hold lxd
I’ve collated the various Ubuntu ZFS < 2.1 options here:
Hi!
Have you rebooted your system recently to the new kernel version maybe?
Couldn’t you create an issue on https://github.com/canonical/lxd/issues with all the details?
I am running 5.15.0-102-generic and also run docker inside the container, so maybe you will need to set security.nesting=true to replicate?
I also noticed that if I add the mount points while the container is running it looks like it all works, but I get very weird behavior now, like containers using those devices can’t start at all and fail with docker claiming “resource unavailable”.
I will file a bug in github if this helps, but can’t do it straight away
That would be great thank you, just so we don’t lose visibility of it here.
My LXD Cluster crashed after refreshing to LXD 5.21/stable (3fsc2a9).
I am using 20.04 LTS. All network connections dropped and “lxc list” resulted with
LXD unix socket not accessible: Get “http://unix.socket/1.0”: EOF
Tried to
sudo systemctrl restart snap.lxd.daemon.service snap.lxd.daemon.unix.socket
the network bridges were not recreated!
sudo systemctrl status snap.lxd.daemon.service
reviewed that the Dqlite database was not able to sync among the nodes. Similar to the observations in post, the zpool was having issues too.
Eventually, my issues were solved by installing the HWE kernel in Focal Fossa.
After the installation, the LXD daemon ran normally.
Terry
It is really interesting behavior.
I’ll try to play with nesting to see if I can reproduce anything like this.
This would be awesome, because in this case we can collect all the information in one place and to try making a minimal reproducer.
I was compiling the bug report, when I found out that on my host:
$ df -h
df: /mnt/dati: Resource temporarily unavailable
df: /mnt/dati_for_internal: Resource temporarily unavailable
df: /mnt/monitoring_for_internal: Resource temporarily unavailable
Filesystem Size Used Avail Use% Mounted on
tmpfs 1.6G 2.2M 1.6G 1% /run
<…>
Even though the content is actually accessible on the host (!!!)
It’s a bug in the linux kernel, not in LXD:
Last message as of few hours ago claims 5.15.0-104-generic fixes the issue and will be released soon.
Sorry for the noise!
Does not work at all I am stucked…