LXD 5.21.1 LTS has been released

Good call! I just installed the HWE kernel in focal, rebooted, and everything came back up normal.

Thanks!

1 Like

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!

1 Like

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!

1 Like

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.

2 Likes

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.

1 Like

thankyou this will be a big help

1 Like

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):

  1. Check revision of 5.20 version.
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
  1. Revert to 5.20.
    snap revert lxd --revision 27049

  2. Stop lxd
    snap stop lxd

  3. Backup current database version 73
    cp -a /var/snap/lxd/common/lxd/database/global ~/lxd-db-global-backup-20240411-version73

  4. 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/
  1. Start LXD
    snap start lxd
2 Likes

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.

1 Like

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

1 Like

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?

1 Like

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

1 Like

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!

2 Likes

Does not work at all I am stucked…