Snap on Arch/Liri OS

Can you try something else (e.g. atom). Also, can you please show.

SNAP_CONFINE_DEBUG=yes /snap/bin/atom
$ SNAP_CONFINE_DEBUG=yes /snap/bin/atom
DEBUG: security tag: snap.atom.atom
DEBUG: executable:   /usr/lib/snapd/snap-exec
DEBUG: confinement:  classic
DEBUG: base snap:    core
DEBUG: skipping sandbox setup, classic confinement in use
DEBUG: creating user data directory: /home/tim/snap/atom/36
DEBUG: loading bpf program for security tag snap.atom.atom
DEBUG: read 64 bytes from /var/lib/snapd/seccomp/bpf//snap.atom.atom.bin
DEBUG: raising privileges to load seccomp profile
DEBUG: dropping privileges after loading seccomp profile
DEBUG: execv(/usr/lib/snapd/snap-exec, /usr/lib/snapd/snap-exec...)
DEBUG:  argv[1] = atom
execv failed: No such file or directory

This looks good so far. Is /usr/lib/snapd/snap-exec present?

@zyga-snapd ._. no it’s not, odd.

Hmm, can you list the files you have in the package please? Did you derive it from the 2.27.5 package that was present in the github release page?

Yeah, I tried to follow your instructions. Here’s the list of files: http://paste.ubuntu.com/25606354/.

Looking at that I don’t see the snap-exec binary. Can you publish your packaging somewhere to compare with the Arch package I made earlier please?

@zyga-snapd sure, I published it here. Thanks :slight_smile:

Having cleaned up all the build files and rerun makepkg, I got some different error messages: http://paste.ubuntu.com/25615596/.
Most interestingly, after rerunning makepkg again, they don’t show up again.

Ha, I thought that was only affecting my machine somehow. I have no idea what is going on, it feels like golang bug or kernel bug. I spent a few hours debugging that and I ended up with a dump of the data that failed to parse as YAML. Instead of the expected content I saw various corrupted data that I could not explain. No idea what the problem was.

Can you tell me which CPU you used? Did you use any virtualization systems? Can you tell me which filesystem you used?

In my experiments the problem reliably went away (as in, subsequent attempts had a chance to succeed) if I removed the source checkout and tried again. When I kept data on disk I got no success. Maybe the page cache was broken somehow?

In general I saw this only on Arch so I’d say it is a kernel-related change as the same hardware was successfully running Fedora and openSUSE.

1 Like

I’d add something to build/install snap-exec at around https://github.com/tim-sueberkrueb/snapd-2.27.6-1-lirios-experiment/blob/master/PKGBUILD#L67

I will provide patches but it’s way too late for that tonight.

@zyga-snapd wow, that sounds like a nasty bug indeed!
My system:

cpu: Intel® Core™ i7-7500U CPU @ 2.70GHz × 4 
kernel: 4.12.13-1-ARCH
os: Liri OS/Arch
filesystem: ext4

I didn’t use any virtualization system(s) nor a container.

I will provide patches but it’s way too late for that tonight.

Yeah, no hurry, thanks a lot!

My system used older 35xx Intel Core i5 (now I envy your shiny machine :slight_smile: ) so I suspect it is more of a kernel bug than a VM or hardware bug.

Looks like it :slight_smile: Let me know if I can somehow help to debug it.

Can you please try the new snapd-git package from AUR?

It’s not AUR yet, there’s just one remaining test that fails on Arch currently. Related PR fixing this is right here: https://github.com/snapcore/snapd/pull/4235

Other than that, can you clone snapd repository and follow instructions from this post Updates to snapd package on Arch ?

Hey @zyga-snapd, @mborzecki thanks for the news/info, I will try (hopefully) this weekend :slight_smile:

That PR is now in. Is there anything else left here, or is it all sorted and we can drop the tracking tags?

Hey, I just got to try building and installing the latest snapd from git on Liri OS and it just works for strictly confined snaps now! This is awesome, thanks a lot!
I still have issues running some classic snaps, however. e.g. vscode and atom won’t launch with the message libselinux.so.1: cannot open shared object file: No such file or directory.

Thanks for feedback. Glad to hear that things work for you now.

As for vscode snap, another user reported this problem right here Installing vscode snap on Arch Linux. I did some digging and IMO the snap does not ship with all dependencies included. I think it’s best if you reach out to the creator of that snap and make them aware of these problems.

1 Like