Snap Core doesn't mount as / while running snaps

snapd
1

Hi,

I am trying to enable snapd on a new Yocto derived distro - IoT Reference OS Kit for Intel Architecture by referencing the meta-snappy project. Now snaps can be installed from the Store, but some snaps fail to run due to the required system libraries such as libapparmor.so.1 are missing. It looks to me those libraries are provided by the Core snap, which should be mounted as / while running the snaps, but it’s not the case in my porting. I understand it’s not the supported configuration, but I’d be very appreciated if anyone could educate me how the snapd works and any pointers on how to debug. Thanks in advance.

Best regards,
Tonny

2

Can you tell us which snaps don’t work? I will try to reproduce this problem then.

3

do you have a more exact error message ?

4

Take the docker snap for example: the snap can be installed with no any error message, the journalctl -u snapd outputs as below:

Apr 26 13:45:00 intel-corei7-64 /usr/lib/snapd/snapd[457]: api.go:913: Installing snap "docker" revision unset
Apr 26 13:45:00 intel-corei7-64 snapd[457]: 2017/04/26 13:45:00.898706 api.go:913: Installing snap "docker" revision unset
Apr 26 13:45:02 intel-corei7-64 /usr/lib/snapd/snapd[457]: taskrunner.go:367: DEBUG: Running task 41 on Do: Download snap "docker" (88) from channel "stable"
Apr 26 13:45:02 intel-corei7-64 /usr/lib/snapd/snapd[457]: daemon.go:176: DEBUG: uid=0;@ POST /v2/snaps/docker 1.53732162s 202
Apr 26 13:45:02 intel-corei7-64 /usr/lib/snapd/snapd[457]: store.go:1281: DEBUG: Available deltas returned by store: []
Apr 26 13:45:58 intel-corei7-64 /usr/lib/snapd/snapd[457]: taskrunner.go:367: DEBUG: Running task 42 on Do: Fetch and check assertions for snap "docker" (88)
Apr 26 13:46:02 intel-corei7-64 /usr/lib/snapd/snapd[457]: taskrunner.go:367: DEBUG: Running task 43 on Do: Mount snap "docker" (88)
Apr 26 13:46:03 intel-corei7-64 /usr/lib/snapd/snapd[457]: taskrunner.go:367: DEBUG: Running task 44 on Do: Copy snap "docker" data
Apr 26 13:46:03 intel-corei7-64 /usr/lib/snapd/snapd[457]: taskrunner.go:367: DEBUG: Running task 45 on Do: Setup snap "docker" (88) security profiles
Apr 26 13:46:03 intel-corei7-64 /usr/lib/snapd/snapd[457]: taskrunner.go:367: DEBUG: Running task 46 on Do: Make snap "docker" (88) available to the system
Apr 26 13:46:04 intel-corei7-64 /usr/lib/snapd/snapd[457]: taskrunner.go:367: DEBUG: Running task 47 on Do: Set automatic aliases for snap "docker"
Apr 26 13:46:04 intel-corei7-64 /usr/lib/snapd/snapd[457]: taskrunner.go:367: DEBUG: Running task 48 on Do: Setup snap "docker" aliases
Apr 26 13:46:05 intel-corei7-64 /usr/lib/snapd/snapd[457]: taskrunner.go:367: DEBUG: Running task 49 on Do: Start snap "docker" (88) services
Apr 26 13:46:05 intel-corei7-64 /usr/lib/snapd/snapd[457]: taskrunner.go:367: DEBUG: Running task 50 on Do: Run configure hook of "docker" snap if present
Apr 26 13:46:06 intel-corei7-64 /usr/lib/snapd/snapd[457]: daemon.go:176: DEBUG: uid=0;@ GET /v2/snaps?snaps=docker 4.844957ms 200

but it fails to run as it can not find the loader ld-linux-x86-64.so.2, which is located at /snap/core/current/lib64/, and should be mounted as / while running the snap:

root@intel-corei7-64:~# snap run docker
/snap/docker/88/bin/docker-wrapper: line 14: /snap/docker/88/bin/docker: No such file or directory

From the shell of the hello-world snap, it looks like the Core snap is not mounted as /

root@intel-corei7-64:~# hello-world.sh
Launching a shell inside the default app confinement. Navigate to your
app-specific directories with:

  $ cd $SNAP
  $ cd $SNAP_DATA
  $ cd $SNAP_USER_DATA

bash-4.3# mount
/dev/disk/by-partuuid/12345678-9abc-def0-0fed-cba987654321 on /var/lib/snapd/hostfs type ext4 (rw,relatime,data=ordered)
tmpfs on /var/lib/snapd/hostfs/run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /var/lib/snapd/hostfs/run/user/0 type tmpfs (rw,nosuid,nodev,relatime,size=193652k,mode=700)
tmpfs on /var/lib/snapd/hostfs/run/snapd/ns type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /var/lib/snapd/hostfs/tmp type tmpfs (rw,nosuid,nodev)
tmpfs on /var/lib/snapd/hostfs/var/volatile type tmpfs (rw,relatime)
/dev/loop0 on /var/lib/snapd/hostfs/snap/core/1577 type squashfs (ro,nodev,relatime)
/dev/loop1 on /var/lib/snapd/hostfs/snap/hello-world/27 type squashfs (ro,nodev,relatime)
/dev/disk/by-partuuid/12345678-9abc-def0-0fed-cba987654321 on / type ext4 (rw,relatime,data=ordered)

I guess the Core snap should be mounted as / in the last statement of the above paragraph? So which part of the snapd should I check? Any pointers would be very appreciated.

5

right; and it never is unless you run an actual UbuntuCore 16 image. snaps are run with core as /, this is handled by the snap-confine tool during snap execution. the mount output is completely unrelated here, this is all handled via namespaces …

also, the hello-world snap obviously runs fine on your setup, else you would not be able to execute hello-world.sh at all. this looks more like an issue with the docker snap.

6

It kind of smells like re-exec kicking in. What is your /etc/os-release file?

7

If it is really the re-execution feature you can try to add the right os identifier in https://github.com/morphis/meta-snappy/blob/master/recipes-support/snapd/files/0005-cmd-add-poky-to-the-list-of-distros-which-don-t-supp.patch instead of the poky one used there.

I am currently building the intel-iot-refkit myself to see how I can help here a bit more.

8

Ok, re-execution seems to be really the problem here. /etc/os-release has the the following content on an image build with the intel-iot-refkit:

ID="refkit"
NAME="IoT Reference OS Kit for Intel(r) Architecture"
VERSION="refkit.0"
VERSION_ID="refkit.0"
PRETTY_NAME="IoT Reference OS Kit for Intel(r) Architecture refkit.0"
BUILD_ID="20170427184152"

What my short experiment shows is that we need to do some additional work in meta-snappy to support the recent golang toolchain addition in oe-core instead of shipping our own one. Will put that on my TODO list. @tonny.tzeng is that something you already did changes for to meta-snppay? If yes, a PR would be very welcome :slight_smile: