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

1 Like
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 >.<

16

this worked for me on Chromebook linux dev env, thanks!

1 Like