Closed T-X closed 6 years ago
So what doesn't really make sense to me here is how did the metadata_csum feature get enabled on this volume in the first place?
LXD storage volumes are created by LXD which would have used the same version of e2fsprogs as is now used to check the volume and so that volume shouldn't have been able to get the metadata_csum feature in the first place.
Did you manually alter that volume in some way or reformatted it using the e2fsprogs from your system?
Hi @stgraber and thanks for your quick reply! Ah, you are right, I indeed needed to recreate a thin-pool because it got into an ugly state after its metadata partition was filled up, with no spare bytes in the volume group and after my attempts to repair it. And I did the recreation manually... and yes, I was using the mkfs.ext4 from the host which was version 1.43 from e2fsprogs in Debian Stretch back then. Right, that's where the metadata_csum feature slipped in...
I could create a new LVM thin-pool a second time, this time via the according LXD storage commands. and could copy all data over again. I'm wondering though, if at some point in time, e2fsprogs needs to be updated in snap-core anyway, would it make sense to do it in the near future? (And maybe with calling mkfs.ext4 with an option like "-O ^metadata_csum" for some backwards compatibility for now?)
So far, any Ubuntu >= 17.10 and any Debian >= Stretch (stable) all use an e2fsprogs >= 1.43 already, right?
Or is a newer e2fsprogs/e2fsck already part of a newer snapd release? Should I bother the Debian maintainers to update the snapd package, at least in Stretch-Backports?
Snaps that are based on core16 (Ubuntu 16.04) get e2fsprogs 1.42.13 and will only be getting bugfixes on top of that, no major release bump. Snaps that are based on core18 (Ubuntu 18.04) get e2fsprogs 1.44.4.
This has nothing to do with the snapd package, so there's really no point in bugging the snapd packagers for this. It's about what base operating system was selected for the particular snap.
LXD will switch to an 18.04 base at some point. The actual logistics of the change and re-validation of the snap for every LXD feature on every Linux distribution takes quite a bit of time and isn't something we're going to rush.
Closing as there's really no LXD bug here, this was caused by manual user intervention outside of LXD's control, leading to this issue.
Ok, thanks for the detailed explanation, @stgraber! Very helpful to understand how snaps work.
I solved the issue now by recreating the storage volume via LXD. And copying the partition contents over.
Required information
Issue description
When trying to resize a storage volume by setting the "size" parameter via "lxc storage volume edit", I'm getting the error message "Config parsing error: Failed to run: e2fsck -f -y /dev/aux/custom_data.media: e2fsck 1.42.13 (17-May-2015)".
Steps to reproduce
Information to attach
It seems that the e2fsck provided by snap-core is too old. And LXC seems to use the old version provided by snap-core instead of the newer one provided by Debian. A bug and request to update (or remove) e2fsck in (/from) snap-core was filed here:
https://bugs.launchpad.net/snapd/+bug/1802528