Archlinux. I installed snapd from the AUR. squashfs-tools was installed as a dependency, but I explicitly installed squashfuse for good measure. I have rebooted since I installed snapd and since the last kernel update was installed.
$ uname -r && pacman -Q linux
5.3.7-arch1-1-ARCH
linux 5.3.7.arch1-1
$ snap --version
snap 2.42-2
snapd 2.42-2
series 16
arch -
kernel 5.3.7-arch1-1-ARCH
$ snap changes
ID Status Spawn Ready Summary
1 Done yesterday at 23:52 PDT yesterday at 23:52 PDT Initialize system state
$ grep squashfs /proc/filesystems
squashfs
SELinux is not installed.
$ /usr/bin/sestatus
-bash: /usr/bin/sestatus: No such file or directory
When attempting to install any snap, I am met with this error:
$ sudo snap install hello_world
error: system does not fully support snapd: cannot mount squashfs image using "squashfs": mount:
/tmp/sanity-mountpoint-408355398: mount failed: Operation not permitted.
$ sudo su root
# snap install hello_world
error: system does not fully support snapd: cannot mount squashfs image using "squashfs": mount:
/tmp/sanity-mountpoint-408355398: mount failed: Operation not permitted.
There are no new messages in dmesg that are interesting. journalctl -xe shows nothing relevant except sudo logging the attempt.
In IRC I was asked to try this, to no avail:
snap download hello-world && mkdir test && sudo mount -o squashfs hello-world*.snap test/
A possibly related forum post is here, but in my case I seem to have no interesting log output.
$ sudo journalctl -u snapd
-- Logs begin at Mon 2019-08-12 19:01:02 PDT, end at Tue 2019-10-22 13:33:48 PDT. --
Oct 21 23:52:07 iris systemd[1]: Starting Snappy daemon...
Oct 21 23:52:07 iris snapd[2489509]: AppArmor status: apparmor not enabled
Oct 21 23:52:07 iris snapd[2489509]: daemon.go:346: started snapd/2.42-2 (series 16; classic; devmode) arch/ (amd64) linux/5.3.5-arch1-1-ARCH.
Oct 21 23:52:07 iris snapd[2489509]: main.go:123: system does not fully support snapd: cannot mount squashfs image using "squashfs": mount: /tmp/sanity-mountpoint-003757754:>
Oct 21 23:52:07 iris snapd[2489509]: daemon.go:439: adjusting startup timeout by 30s (pessimistic estimate of 30s plus 5s per snap)
Oct 21 23:52:07 iris snapd[2489509]: helpers.go:104: error trying to compare the snap system key: system-key missing on disk
Oct 21 23:52:07 iris systemd[1]: Started Snappy daemon.
Oct 21 23:52:12 iris snapd[2489509]: daemon.go:540: gracefully waiting for running hooks
Oct 21 23:52:12 iris snapd[2489509]: daemon.go:542: done waiting for running hooks
Oct 21 23:52:12 iris snapd[2489509]: daemon stop requested to wait for socket activation
Oct 21 23:52:12 iris systemd[1]: snapd.service: Succeeded.
Oct 21 23:52:39 iris systemd[1]: Starting Snappy daemon...
Oct 21 23:52:39 iris snapd[2491116]: AppArmor status: apparmor not enabled
Oct 21 23:52:39 iris snapd[2491116]: patch.go:64: Patching system state level 6 to sublevel 1...
Oct 21 23:52:39 iris snapd[2491116]: patch.go:64: Patching system state level 6 to sublevel 2...
Oct 21 23:52:39 iris snapd[2491116]: daemon.go:346: started snapd/2.42-2 (series 16; classic; devmode) arch/ (amd64) linux/5.3.5-arch1-1-ARCH.
Oct 21 23:52:39 iris snapd[2491116]: main.go:123: system does not fully support snapd: cannot mount squashfs image using "squashfs": mount: /tmp/sanity-mountpoint-862431413:>
Oct 21 23:52:39 iris snapd[2491116]: daemon.go:439: adjusting startup timeout by 30s (pessimistic estimate of 30s plus 5s per snap)
Itās not really clear what is going on there. On the one hand, a mount by the user is successful, on the other snapd running as root gets EPERM. The difference is snapd trying to mount at a location under /tmp, but I donāt think it matters. Just for the record, can you post the output of snap debug sandbox-features?
Then can you add the following to snapd service overrides file?
2797385: libmount: LOOP: [0x555d00479460]: not found; create a new loop device
2797385: loopdev: CXT: [0x7ffc4d1aa5d0]: initialize context
2797385: loopdev: CXT: [0x7ffc4d1aa5d0]: init: ignore ioctls
2797385: libmount: LOOP: [0x555d00479460]: enabling AUTOCLEAR flag
2797385: loopdev: CXT: [0x7ffc4d1aa5d0]: find_unused requested
2797385: loopdev: CXT: [0x7ffc4d1aa5d0]: using loop scan
2797385: loopdev: ITER: [0x7ffc4d1aa760]: initialize
2797385: loopdev: ITER: [0x7ffc4d1aa760]: next
2797385: loopdev: ITER: [0x7ffc4d1aa760]: next: default check
2797385: loopdev: CXT: [0x7ffc4d1aa5d0]: loop0 name assigned
2797385: loopdev: ITER: [0x7ffc4d1aa760]: /dev/loop0 does not exist
2797385: loopdev: CXT: [0x7ffc4d1aa5d0]: loop1 name assigned
2797385: loopdev: ITER: [0x7ffc4d1aa760]: /dev/loop1 does not exist
...
2797385: loopdev: CXT: [0x7ffc4d1aa5d0]: loop7 name assigned
2797385: loopdev: ITER: [0x7ffc4d1aa760]: /dev/loop7 does not exist
2797385: loopdev: ITER: [0x7ffc4d1aa760]: next: scanning /dev
2797385: loopdev: ITER: scan dir: /dev/
...
2797385: loopdev: CXT: [0x7ffc4d1aa5d0]: find_unused by scan [rc=1]
...
2797385: libmount: CXT: [0x555d00479460]: mount: preparing failed
2797385: libmount: CXT: [0x555d00479460]: excode: rc=1 message="mount failed: Operation not
permitted" mount: /tmp/sanity-mountpoint-326453316: mount failed: Operation not permitted.
Which indicates that loopdev cannot for some reason access /dev/loop-control and goes into /dev/scanning mode. The difference is, in the loop-control mode mount would do LOOP_CTL_GET_FREE which allocates a new device when none are free. In the /dev scanning mode, it does not create new devices, but instead tries to use the existing ones, by trying some pre-determined set of device names.
This does not explain why mount invoked by snapd cannot access /dev/loop-control. On my vanilla Arch, with the default systemd setup and the service unit that came from the package, it can.
Looking at util-linux all it does is a simple stat on /dev/loop-control:
I would guess thereās some limitation applied in your local system configuration. Maybe check if PrivateDevices isnāt set by systemd on snapd.service.
Edit: and double check that the loop module can actually by loaded into the kernel.
systemctl status snapd
ā snapd.service - Snap Daemon
Loaded: loaded (/lib/systemd/system/snapd.service; enabled; vendor preset:>
Active: active (running) since Mon 2020-07-27 11:21:17 CEST; 2s ago
TriggeredBy: ā snapd.socket
Main PID: 733 (snapd)
Tasks: 8 (limit: 19660)
Memory: 38.1M
CGroup: /system.slice/snapd.service
āā733 /usr/lib/snapd/snapd
But after try to install:
snap install hello-world
error: system does not fully support snapd: cannot mount squashfs image using
"squashfs": mount: /tmp/sanity-mountpoint-396324705: mount failed:
Operation not permitted.
Become:
systemctl status snapd
ā snapd.service - Snap Daemon
Loaded: loaded (/lib/systemd/system/snapd.service; enabled; vendor preset:>
Active: inactive (dead) since Mon 2020-07-27 11:22:24 CEST; 23s ago
TriggeredBy: ā snapd.socket
Process: 761 ExecStart=/usr/lib/snapd/snapd (code=exited, status=42)
Main PID: 761 (code=exited, status=42)
Is the squashfs module loaded? Have you rebooted after a kernel update? Note that Arch only keeps a single version of each kernel variant (linux, linux-lts and so on), so itās easy to end up in a situation where the new kernel is on disk but youāre still running the old one. AFAICT the current kernel 5.12.13 already, yours seems to be 5.12.12.
