do-release-upgrade from bionic->any disables lxd without snapstore access
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
lxd (Ubuntu) |
Won't Fix
|
Undecided
|
Unassigned | ||
Cosmic |
Won't Fix
|
Undecided
|
Unassigned | ||
Disco |
Won't Fix
|
Undecided
|
Unassigned | ||
Eoan |
Won't Fix
|
Undecided
|
Unassigned | ||
Focal |
Won't Fix
|
Undecided
|
Unassigned | ||
ubuntu-release-upgrader (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Cosmic |
Won't Fix
|
Undecided
|
Unassigned | ||
Disco |
Won't Fix
|
Undecided
|
Unassigned | ||
Eoan |
Won't Fix
|
Undecided
|
Unassigned | ||
Focal |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
[impact]
a bionic system with lxd installed, and configured, when upgraded to cosmic using do-release-upgrade, will attempt to convert the lxd deb into a snap. However, if the snapstore isn't reachable (which is a common situation in enterprise environments, where they use local apt mirrors and firewall internet access, or even are completely air-gapped), the upgrade complains loudly about being unable to access the snapstore, and the only option presented to allow install to continue is to skip or abort lxd upgrade, which states lxd will be unusable after the upgrade.
[test case]
see bug 1831933 for testbed setup (use a libvirt vm with nwfilter blocking api.snapcraft.io)
-create VM using the bionic cloud image
-in the bionic guest:
$ sudo apt update
$ sudo apt dist-upgrade
-note: snapd and lxd should already be installed; verify this
$ dpkg -l |grep -E '^ii (lxd|snapd)'
ii lxd 3.0.3-0ubuntu1~
ii lxd-client 3.0.3-0ubuntu1~
ii snapd 2.39.2+18.04 amd64 Daemon and tooling that enable snap packages
-edit /etc/update-
-reboot, if needed due to kernel upgrade
-upgrade:
$ sudo do-release-upgrade
Once the upgrade reaches the lxd package, it will display:
--
Your system is unable to reach the snap store, please make sure you're
connected to the Internet and update any firewall or proxy settings as
needed so that you can reach the snap store.
You can manually check for connectivity by running "snap info lxd"
Aborting will cause the upgrade to fail and will require it to be re-
attempted once snapd is functional on the system.
Skipping will let the package upgrade continue but the LXD commands will
not be functional until the LXD snap is installed. Skipping is allowed
only when LXD is not activated on the system.
Unable to reach the snap store
--
With the possible choices of:
Retry
Abort
Skip
Retry, of course, will never succeed.
Skip is not allowed if lxd has been configured (i.e. 'lxd init' was run, and /var/lib/lxd is populated). If lxd (and/or lxd-client) are installed but not configured, skip can be chosen to continue the upgrade, and after upgrade is complete, the lxd package will not be installed. If skip is attempted when lxd has been initialized, this is shown:
--
Skipping is not allowed when LXD has been initialized
LXD appears to have been configured on this system. Please stop LXD and
remove local data in /var/lib/lxd/ if you would like to skip installing
the LXD snap and migrating the local data.
--
Abort continues the upgrade remaining packages, after asking if the lxd upgrade failure report should be sent. However, at the end of the remaining package upgrades, the upgrade reports error and exits; it is unclear if the system is in a good fully-upgraded state at this point (besides not having an upgraded lxd, of course).
[regression potential]
TBD
[other info]
this is related to bug 1831933, but much more serious, if lxd really is unusable after the upgrade.
I targeted this bug as affecting cosmic, disco, and eoan, however currently the upgrade from bionic must go through cosmic first. And since the lxd upgrade from b->c fails without snapstore access, and there is no way to install lxd as a deb into cosmic, this bug really is just about upgrading *from* bionic.
This bug is unlikely to be seen by any enterprise customers right now, as most of them stick to LTS releases. However in 2020 once the LTS series 20.04 is released, some enterprise customers whose deployment is firewalled and/or airgapped may start to see this during upgrade.
Changed in lxd (Ubuntu Eoan): | |
importance: | Undecided → High |
Changed in lxd (Ubuntu Cosmic): | |
importance: | Undecided → High |
Changed in lxd (Ubuntu Disco): | |
importance: | Undecided → High |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
tags: | added: rls-ee-incoming |
tags: |
added: rls-ee-notfixing rls-ff-incoming removed: rls-ee-incoming |
Changed in lxd (Ubuntu Focal): | |
status: | New → Won't Fix |
tags: | removed: rls-ff-incoming |
tags: | added: id-5de941ae648ff64e0f8f8e02 |
Changed in lxd (Ubuntu): | |
status: | Confirmed → Won't Fix |
I suspect for lxd, this is likely a WontFix; for cosmic and later, it's provided via snap, and unlikely to go back to a deb.
I targeted this against u-r-u as well, as the 'best' fix for this may be to add a check at the start of the upgrade process, and let the upgrader choose at that point what to do, instead of waiting until mid-upgrade to let them know they need to abort the upgrade.
Additionally, whatever warning/error message is printed, either by lxd package->snap upgrade itself, and/or do-release-upgrade, should mention the snap proxy, as enterprise customers with a firewall setup will likely need to use the snap proxy. /docs.ubuntu. com/snap- store-proxy/ en/
https:/