Thanks Brian, my memory of this whole thing clearly dates back a long time then ;)
I still remember some of the discussions of what we'd expect people to be doing in such cases and whether we'd ever officially support (as in test/validate) upgrade paths other than release to release+1 and LTS to LTS+1. I remember us struggling to really validate those two more common paths so I wonder what's done today to validate the upgrade paths when one release goes EOL and the upgrade path changes to something different for those upgrading from the LTS. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1959993 Title: SRU of LXC 4.0.12 to focal (upstream bugfix release) Status in lxc package in Ubuntu: In Progress Bug description: LXC released 4.0.12 as a bugfix release and is now in jammy. We'd like to line things up in focal. [Impact] The proposed SRU will bump from 4.0.6 all the way to 4.0.12, lining it up with what's currently in jammy. We've been skipping a few of the bugfix releases in focal so far, mostly catching up when we're starting to see problems with the older version. In this case, we've seen a number of issues when running with the HWE kernels as well as autopkgtest issues on foreign architectures (arm64 and s390x), all those will go away with this bump as we've confirmed everything is clean in jammy. Changelog: * Cherry-pick upstream bugfixes (stable-4.0): - 0002-lxc-checkconfig-Fix-bashism.patch - 0003-doc-Fix-reverse-allowlist-denylist.patch * New upstream bugfix release (4.0.12): (https://discuss.linuxcontainers.org/t/lxc-4-0-12-has-been-released/13288) - Fixed CRIU restoration of containers with pre-created veth interfaces - Fixed issue with kernels lacking SMT support - Extended cgroup2 config options in lxc.mount.auto (cgroup2) - lxc-download now relies on HTTPS for validation (avoids GPG issues) * New upstream bugfix release (4.0.11): (https://discuss.linuxcontainers.org/t/lxc-4-0-11-has-been-released/12427) - Core scheduling support (lxc.sched.core) - riscv64 support in lxc.arch - Significantly improved bash completion profile - Greater use of the new VFS mount API (when supported by the kernel) - Fix containers with empty network namespaces - Handle kernels that lack TIOCGPTPEER - Improve CPU bitmask/id handling (handle skipped CPU numbers) - Reworked the tests to run offline * New upstream bugfix release (4.0.10): (https://discuss.linuxcontainers.org/t/lxc-4-0-10-has-been-released/11618) - Fix issues with less common architectures - Support for additional idmap mounts - nft support in lxc-net - Cleaner mount entries for sys:mixed - Switched GPG server to keyserver.ubuntu.com * New upstream bugfix release (4.0.9): (https://discuss.linuxcontainers.org/t/lxc-4-0-9-has-been-released/10999) - Fix incorrect personality setting when running 32bit containers on 64bit * New upstream bugfix release (4.0.8): - Fix CGroup attach against older running containers * New upstream bugfix release (4.0.7): - Testing improvements including fixes from oss-fuzz - Rework of the attach codepath - Cgroup handling rework * Bump to debhelper 12 (allows focal SRUs) * Bump standards to 4.6.0.1 * Add lintian overrides for incorrect bashism detection * Remove bash completion install logic (now done upstream) Just like Ubuntu itself, upstream releases long term support releases, e.g. 4.0, and then periodic point releases including all the accumulated bugfixes. Only the latest upstream release gets full support from the upstream developers, everyone else is expected to first update to it before receiving any kind of support. This should qualify under the minor/micro upstream bugfix release allowance of the SRU policy, letting us SRU this without paperwork for every single change included in this upstream release. [Test Plan] lxc has autopkgtests which will assert that the binaries built in -proposed are functional. [Where problems could occur] This is catching up a fair bit on recent kernel API changes, including cgroup1/cgroup2 support, handling of nftables, riscv64 and core scheduling which were all needed to properly handle the most recent HWE kernels especially as we're getting ready for Ubuntu 22.04's 5.15 to get pushed to focal. We've had all that code running on well over a million of LXD snap users for a few months now without seeing any issues (or more precisely, those issues we found have been all been resolved as of 4.0.12). However what LXD exercises isn't 100% of LXC and it's certainly possible that we missed a corner case in one of those changes. The good news is that this would most likely be triggered by a HWE kernel, so a viable workaround in many cases would be to temporarily go back to the original kernel (5.4) while the issue is sorted out in a follow up SRU. It's also worth noting that LXD CI runs daily tests against over a dozen different kernels coming from various distros which helps us identify such issues quite early on. [Other Info] Unless absolutely required, we're not intending to push for an SRU to impish as it has a reasonably recent LXC (4.0.10) and realistically, folks are quite a bit more likely to wait to upgrade from focal to jammy than jump through EOL releases from focal to impish. Should someone do an upgrade to impish, we've confirmed that the upgrade is resolvable and that they'll just be left with a more recent version of LXC than that in the impish archive, until jammy releases and they upgrade to it. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1959993/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
