Fresh install of livepatch doesn't recognize ubuntu xenial

Confirmed that we can't use /etc/os-release directly from a snap as it posts snap-related information only. We instead need to parse /etc/lsb-release

dash-shell.dash
$ cat /etc/os-release
NAME="Ubuntu Core"
VERSION="16"
ID=ubuntu-core
PRETTY_NAME="Ubuntu Core 16"
VERSION_ID="16"
HOME_URL="http://www.snapcraft.io/"
BUG_REPORT_URL="http://bugs.launchpad.net/snappy/"

$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.1 LTS"

Confirmed failure can be observed with the livepatch-client system_test. I did have to tweak system-tests to get them working:

$ git diff
diff --git a/tests/system_test.go b/tests/system_test.go
index 72c8d36..7f34364 100644
--- a/tests/system_test.go
+++ b/tests/system_test.go
@@ -529,7 +529,7 @@ func init() {
        // Create test system
        Vm = SystemTest{Name: "livepatchd-vm", User: "ubuntu", Series: "xenial",
                Arch: "amd64", Flavor: "generic", PackageVersion: TestPackageVersion,
- KernelVersion: "4.4.0-21.37", KernelABI: "4.4.0-21"}
+ KernelVersion: "4.4.0-63.84", KernelABI: "4.4.0-63"}
        Vm.setup()
 }

The 4.4.0-21.37 kernel was failing to boot in the KVM.

The error in /var/log/syslog:
Feb 23 20:49:01 livepatchd-vm snap[1939]: 2017/02/23 20:49:01 Only Ubuntu 16.04 LTS is supported, exiting.
Feb 23 20:49:01 livepatchd-vm systemd[1]: snap.canonical-livepatch.canonical-livepatchd.service: Main process exited, code=exited, status=1/FAILURE
Feb 23 20:49:01 livepatchd-vm systemd[1]: snap.canonical-livepatch.canonical-livepatchd.service: Unit entered failed state.
Feb 23 20:49:01 livepatchd-vm systemd[1]: snap.canonical-livepatch.canonical-livepatchd.service: Failed with result 'exit-code'.
Feb 23 20:49:01 livepatchd-vm systemd[1]: snap.canonical-livepatch.canonical-livepatchd.service: Service hold-off time over, scheduling restart.
Feb 23 20:49:01 livepatchd-vm systemd[1]: Stopped Service for snap application canonical-livepatch.canonical-livepatchd.
Feb 23 20:49:01 livepatchd-vm systemd[1]: snap.canonical-livepatch.canonical-livepatchd.service: Start request repeated too quickly.
Feb 23 20:49:01 livepatchd-vm systemd[1]: Failed to start Service for snap application canonical-livepatch.canonical-livepatchd.

Reason why upgraded systems kept working: https://bugs.launchpad.net/snapd/+bug/1667479

> Confirmed that we can't use /etc/os-release directly from a snap as it posts
> snap-related information only. We instead need to parse /etc/lsb-release

Chad, I'm not sure I follow what you mean with this. Could you explain?

We should fix this in snap-confine by bind mounting distro's /etc/os-release (after resolving the symlink) on top of /etc/os-release in the core snap.

/home/zyga # mount --bind /var/lib/snapd/hostfs/usr/lib/os-release /etc/os-release
/home/zyga # cat /etc/os-release
NAME="Ubuntu"
VERSION="16.04.2 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.2 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
VERSION_CODENAME=xenial
UBUNTU_CODENAME=xenial

(I chatted about this with Zyga, understand Chad's point now)

As a workaround the snap can use the os-release from hostfs directly.

(except your snap can't read that file? drat)

Fix just landed, going through publishing the snap now https://github.com/CanonicalLtd/livepatch-client/pull/8

Publishing initially to --beta channel for testing.

Will rollout the fix to --release just after we confirm an automated snap refresh fixes this without additional interaction on the client

canonical-livepatch snap version 7 revision 21 Fixes this and relies on /etc/lsb-release instead of the lsb_release tool.

Old kernels <= 4.4.0-24 might get hit with a snap mount kernel oops, a reboot of the system resolved this on our end.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1572316

long term please use /etc/os-release.
since we do not ship lsb_release at all in the core snap it is not guaranteed that /etc/lsb-release will stay around ... (i will not remove it without notification though, but please plan to move over once snap-confine will provide a bind mount of the hosts os-release file on classic installs)

ogra, we are using /etc/lsb-release on the base system, not looking specifically in the core snap. So, I'm not sure comment #12 applies does it?

We had a discussion about using the core snaps /etc/lsb-release and decided we didn't want to get hit by this again because, long term, the snap should only be reporting about snap-related configuration and environment. We can rely on etc/lsb-release on the host system right?

Ahh, we will watch for the fix related to binding /etc/os-release from the underlying system in comment #5. When that lands we will change livepatch client to parse this file in the snap.

i dont think your snap can actually see the hosts lsb-release unless it is either "confinement: classic" or snap-confine bind-mounts the right file for you on top of the one in the core snap.

Hmm, our snap is confinement:strict with the following plugs.

        plugs: [ network-bind, network-control, kernel-module-control, system-observe, hardware-observe ]

We are able to manipulate /etc/lsb-release on the host system to cause the snap to claim it doesn't support the underlying system, so I believe hardware-observe is probably mounting that for us.

In a classic system, when running a confinement:strict snap, most of your /etc/ inside the snap is the /etc from the classic system. This includes both /etc/lsb-release and /etc/os-release.

However, /etc/os-release is a symlink to ../usr/lib/os-release, which when inside the snap is the core snap's. We'll be explicitly mounting the "outside" os-release over that symlink to make this kind of thing work.

This will be fixed shortly :-)

This is being fixed in the following PR: https://github.com/snapcore/snapd/pull/2947