System does not fully support snapd

snap
1

Hello.
I follow these steps for installing intellij-idea. When I run “sudo snap install intellij-idea-ultimate --classic” after that I see this error message.

error: system does not fully support snapd: cannot mount squashfs image using "squashfs": mount:
/tmp/sanity-mountpoint-574715864: wrong fs type, bad option, bad superblock on /dev/loop1,
missing codepage or helper program, or other error.

“journalctl -u snapd” output.

Dec 20 12:21:09 website.com systemd[1]: Starting Snappy daemon...
Dec 20 12:21:09 website.com snapd[2988]: AppArmor status: apparmor not enabled
Dec 20 12:21:09 website.com snapd[2988]: daemon.go:346: started snapd/2.42.2-1.fc31 (series 16; classic; devmode) fedora/31 (amd64) linux/5.3.7-301.fc31.x86_64.
Dec 20 12:21:09 website.com snapd[2988]: main.go:123: system does not fully support snapd: cannot mount squashfs image using "squashfs": mount: /tmp/sanity-mountpoint-719841518: wrong fs type, bad option, bad superblock >
Dec 20 12:21:09 website.com snapd[2988]: daemon.go:439: adjusting startup timeout by 30s (pessimistic estimate of 30s plus 5s per snap)
Dec 20 12:21:09 website.com snapd[2988]: helpers.go:104: error trying to compare the snap system key: system-key missing on disk
Dec 20 12:21:09 website.com systemd[1]: Started Snappy daemon.
Dec 20 12:21:14 website.com snapd[2988]: daemon.go:540: gracefully waiting for running hooks
Dec 20 12:21:14 website.com snapd[2988]: daemon.go:542: done waiting for running hooks
Dec 20 12:21:14 website.com snapd[2988]: daemon stop requested to wait for socket activation
Dec 20 12:21:14 website.com systemd[1]: snapd.service: Succeeded.
-- Reboot --
Dec 20 12:22:28 website.com systemd[1]: Starting Snappy daemon...
Dec 20 12:22:28 website.com snapd[2840]: AppArmor status: apparmor not enabled
Dec 20 12:22:28 website.com snapd[2840]: patch.go:64: Patching system state level 6 to sublevel 1...
Dec 20 12:22:28 website.com snapd[2840]: patch.go:64: Patching system state level 6 to sublevel 2...
Dec 20 12:22:28 website.com snapd[2840]: daemon.go:346: started snapd/2.42.2-1.fc31 (series 16; classic; devmode) fedora/31 (amd64) linux/5.3.7-301.fc31.x86_64.
Dec 20 12:22:28 website.com snapd[2840]: main.go:123: system does not fully support snapd: cannot mount squashfs image using "squashfs": mount: /tmp/sanity-mountpoint-847327975: wrong fs type, bad option, bad superblock >
Dec 20 12:22:28 website.com snapd[2840]: daemon.go:439: adjusting startup timeout by 30s (pessimistic estimate of 30s plus 5s per snap)
Dec 20 12:22:28 website.com systemd[1]: Started Snappy daemon.
Dec 20 12:22:33 website.com snapd[2840]: daemon.go:540: gracefully waiting for running hooks
Dec 20 12:22:33 website.com snapd[2840]: daemon.go:542: done waiting for running hooks
Dec 20 12:22:33 website.com snapd[2840]: daemon stop requested to wait for socket activation
Dec 20 12:22:33 website.com systemd[1]: snapd.service: Succeeded.
Dec 20 12:23:19 website.com systemd[1]: Starting Snappy daemon...
Dec 20 12:23:19 website.com snapd[3213]: AppArmor status: apparmor not enabled
Dec 20 12:23:19 website.com snapd[3213]: daemon.go:346: started snapd/2.42.2-1.fc31 (series 16; classic; devmode) fedora/31 (amd64) linux/5.3.7-301.fc31.x86_64.
Dec 20 12:23:19 website.com snapd[3213]: main.go:123: system does not fully support snapd: cannot mount squashfs image using "squashfs": mount: /tmp/sanity-mountpoint-739260919: wrong fs type, bad option, bad superblock >
Dec 20 12:23:19 website.com snapd[3213]: daemon.go:439: adjusting startup timeout by 30s (pessimistic estimate of 30s plus 5s per snap)
Dec 20 12:23:19 website.com systemd[1]: Started Snappy daemon.
Dec 20 12:23:24 website.com snapd[3213]: daemon.go:540: gracefully waiting for running hooks
Dec 20 12:23:24 website.com snapd[3213]: daemon.go:542: done waiting for running hooks
Dec 20 12:23:24 website.com snapd[3213]: daemon stop requested to wait for socket activation
Dec 20 12:23:24 website.com systemd[1]: snapd.service: Succeeded.
Dec 20 12:24:44 website.com systemd[1]: Starting Snappy daemon...
Dec 20 12:24:44 website.com snapd[3323]: AppArmor status: apparmor not enabled
Dec 20 12:24:44 website.com snapd[3323]: daemon.go:346: started snapd/2.42.2-1.fc31 (series 16; classic; devmode) fedora/31 (amd64) linux/5.3.7-301.fc31.x86_64.
Dec 20 12:24:44 website.com snapd[3323]: main.go:123: system does not fully support snapd: cannot mount squashfs image using "squashfs": mount: /tmp/sanity-mountpoint-115988691: wrong fs type, bad option, bad superblock >
Dec 20 12:24:44 website.com snapd[3323]: daemon.go:439: adjusting startup timeout by 30s (pessimistic estimate of 30s plus 5s per snap)
Dec 20 12:24:44 website.com systemd[1]: Started Snappy daemon.
Dec 20 12:24:49 website.com snapd[3323]: daemon.go:540: gracefully waiting for running hooks
Dec 20 12:24:49 website.com snapd[3323]: daemon.go:542: done waiting for running hooks
Dec 20 12:24:49 website.com snapd[3323]: daemon stop requested to wait for socket activation
Dec 20 12:24:49 website.com systemd[1]: snapd.service: Succeeded.
Dec 20 12:39:05 website.com systemd[1]: Starting Snappy daemon...
Dec 20 12:39:05 website.com snapd[4011]: AppArmor status: apparmor not enabled
Dec 20 12:39:05 website.com snapd[4011]: daemon.go:346: started snapd/2.42.2-1.fc31 (series 16; classic; devmode) fedora/31 (amd64) linux/5.3.7-301.fc31.x86_64.
Dec 20 12:39:05 website.com snapd[4011]: main.go:123: system does not fully support snapd: cannot mount squashfs image using "squashfs": mount: /tmp/sanity-mountpoint-490419557: wrong fs type, bad option, bad superblock >
Dec 20 12:39:05 website.com snapd[4011]: daemon.go:439: adjusting startup timeout by 30s (pessimistic estimate of 30s plus 5s per snap)
Dec 20 12:39:05 website.com systemd[1]: Started Snappy daemon.
Dec 20 12:39:10 website.com snapd[4011]: daemon.go:540: gracefully waiting for running hooks
Dec 20 12:39:10 website.com snapd[4011]: daemon.go:542: done waiting for running hooks
Dec 20 12:39:10 website.com snapd[4011]: daemon stop requested to wait for socket activation
2

that’s your problem: your system can’t mount squashfs files.
What’s the output of snap version?

3

my snap version:

snap    2.42.2-1.fc31
snapd   2.42.2-1.fc31
series  16
fedora  31
kernel  5.3.16-300.fc31.x86_64
4

My guess is that the kernel package was updated when you installed snapd, since it pulls in kernel-modules as well, but the host was not rebooted. Can you run rpm -qa kernel\* | sort and post the results?

Also, there’s a known bug with rich dependencies handling, where dnf may install kernel-debug-modules instead of the kernel-modules package. Please make sure you are running the right kernel.

5

after installing kernel-debug-modules I reinstall the snapd and it works. Thank you.

kernel-5.3.16-300.fc31.x86_64
kernel-5.3.7-301.fc31.x86_64
kernel-core-5.3.16-300.fc31.x86_64
kernel-core-5.3.7-301.fc31.x86_64
kernel-headers-5.3.11-300.fc31.x86_64
kernel-modules-5.3.16-300.fc31.x86_64
kernel-modules-5.3.7-301.fc31.x86_64
kernel-modules-extra-5.3.16-300.fc31.x86_64
kernel-modules-extra-5.3.7-301.fc31.x86_64

6

Hi there,

Am facing same problem but still unable to fix it.

Here is the output of rpm -qa kernel* | sort

kernel-5.3.7-301.fc31.x86_64
kernel-5.4.7-200.fc31.x86_64
kernel-5.4.8-200.fc31.x86_64
kernel-core-5.3.7-301.fc31.x86_64
kernel-core-5.4.7-200.fc31.x86_64
kernel-core-5.4.8-200.fc31.x86_64
kernel-headers-5.4.7-200.fc31.x86_64
kernel-modules-5.3.7-301.fc31.x86_64
kernel-modules-5.4.7-200.fc31.x86_64
kernel-modules-5.4.8-200.fc31.x86_64
kernel-modules-extra-5.3.7-301.fc31.x86_64
kernel-modules-extra-5.4.7-200.fc31.x86_64
kernel-modules-extra-5.4.8-200.fc31.x86_64

And snap version:

snap    2.42.2-1.fc31
snapd   2.42.2-1.fc31
series  16
fedora  31
kernel  5.4.8-200.fc31.x86_64

And the “journalctl -u snapd” output:

Jan 10 11:44:13 localhost.localdomain snapd[2885]: AppArmor status: apparmor not enabled
Jan 10 11:44:13 localhost.localdomain snapd[2885]: patch.go:64: Patching system state level 6 to sublevel 1...
Jan 10 11:44:13 localhost.localdomain snapd[2885]: patch.go:64: Patching system state level 6 to sublevel 2...
Jan 10 11:44:13 localhost.localdomain snapd[2885]: daemon.go:346: started snapd/2.42.2-1.fc31 (series 16; classic; devmode) fedora/31 (amd64) linux/5.4.8-200.fc31.x86_64.
Jan 10 11:44:13 localhost.localdomain snapd[2885]: main.go:123: system does not fully support snapd: cannot mount squashfs image using "squashfs": mount: /tmp/sanity-mountpoint-308347908: wr>
Jan 10 11:44:13 localhost.localdomain snapd[2885]: daemon.go:439: adjusting startup timeout by 30s (pessimistic estimate of 30s plus 5s per snap)
Jan 10 11:44:13 localhost.localdomain systemd[1]: Started Snappy daemon.
Jan 10 11:44:18 localhost.localdomain snapd[2885]: daemon.go:540: gracefully waiting for running hooks
Jan 10 11:44:18 localhost.localdomain snapd[2885]: daemon.go:542: done waiting for running hooks
Jan 10 11:44:18 localhost.localdomain snapd[2885]: daemon stop requested to wait for socket activation
Jan 10 11:44:18 localhost.localdomain systemd[1]: snapd.service: Succeeded.

I tried to install kernel-debug-modules but still no luck.

Any help will be appreciated

8

I got the same messages with using an older 3.10 kernel, on an ARMv7 machine, with ubuntu 18.04.4 LTS filesystem.

SNAP would compain that mount failed, with a permission denied error, even as root!

FIX: My kernel didn’t have LOOPBACK support, recompile it with it, now snap works.

9

I got the same messages with using an the 4.4.0 kernel.

10

reboot!! for me that’s work… try it!

1 Like
11

This simply worked for me sudo apt install libsquashfuse0 squashfuse fuse

12

Reboot works for me too !!!..

13

Hi! I’ve solved the same problem (due to upgrade from Fedora 35 to 36) as follows:

  • I’ve previously installed fuse, squashfuse (and also fuse-lib and squashfuse-lib but I don’t know if they are necessary)
  • I’ve uninstalled snapd and rebooted
  • I’ve reinstalled snapd and rebooted
  • After reboot, everything worked fine.

I’ve made the mistake to install and reinstall without rebooting (restarting services didn’t work for me), so I advice to reboot for each procedure

14

If you’re on Fedora then there’s this bug about dnf acting silly: https://bugzilla.redhat.com/show_bug.cgi?id=1652823 double check if you haven’t installed the debug kernel by an accident.

15

You’re right, I remember I did, I’ll confirm once I’m back home. Sorry for this, I’ve forgot this step, because I’ve tried everything from Google to make it work >.<