When installing snaps I get the following error:

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

 

It worked about a mouth ago but now whenever I build the images and try to install a snap I get that error.

 

Steps to reproduce:

1. Build Nanopi Duo2 image with kvm and squashfs

2. Connect to device and install snapd 'sudo apt install snapd'

3. Install snap to test it 'sudo snap install hello-world'

 

Expectation:

Snaps work as this is the same process that I did before to use snaps on armbian image for this device

 

Result: Getting the error

 

I have tried multiple sd cards, multiple nanopi duo2 devices and both 18.04 and 20.04 images.

Edited August 15, 20206 yr by pfeerick
Added 'solved' tag

28 minutes ago, Guy said:

It worked about a mouth ago but now whenever I build the images and try to install a snap I get that error

 

Worked after this?

21 minutes ago, Igor said:

 

Worked after this?

Not sure, is there easy way to build image with kvm and squashfs with the code before the merge ? this way I will test it.

1 hour ago, Guy said:

Not sure, is there easy way to build image with kvm and squashfs with the code before the merge ? this way I will test it.

You could checkout at a specific commit which should be the one before the one Igor mentioned

Try that: https://stackoverflow.com/questions/7539130/go-to-particular-revision

 

Behavior confirmed with sunxi-current Focal on OrangePi One. I will play a little around with kernel options...

So far from what I found is that the cause may be SElinux. The snap module is not present in semodule -l for unknown reason.

 

Confirmed. Disabling SElinux allows snaps to be installed.

Oddly enough because SElinux was NOT in enforcing but in permissive mode...

 

 

Aight its getting more and more odd. sunxi64 Focal does not seem to have selinux installed at all while sunxi has. It is present in both kernel configs though.

Selinux - also my primary suspect in this case - should in theory be disabled in userspace / on target by default. Perhaps this is not enough or not working properly ...

snap SHOULD work with SElinux and vice versa but it seems that the policy for it is missing in SElinux and I could not find where to get that from...

Not a big fan of Snaps on embedded devices... old versions tend to stick around, and will fill up your file system...

 

Trying hard to avoid the whole Mint/Ubuntu SNAP discussion here...

On 7/6/2020 at 11:35 AM, Igor said:

 

Worked after this?

Before it is working, after cannot connect to serial

U-Boot SPL 2020.04-armbian (Jul 11 2020 - 16:51:48 +0300)
DRAM: 512 MiB
Trying to boot from MMC1


U-Boot 2020.04-armbian (Jul 11 2020 - 16:51:48 +0300) Allwinner Technology

CPU:   Allwinner H3 (SUN8I 1680)
Model: FriendlyARM NanoPi DUO 2
DRAM:  512 MiB
MMC:   mmc@1c0f000: 0
Loading Environment from FAT... Unable to use mmc 0:1... In:    serial
Out:   serial
Err:   serial
Net:   No ethernet found.
starting USB...
No working controllers found
Autoboot in 1 seconds, press <Space> to stop
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
3789 bytes read in 3 ms (1.2 MiB/s)
## Executing script at 43100000
U-boot loaded from SD
Boot script loaded from mmc
190 bytes read in 3 ms (61.5 KiB/s)
13628911 bytes read in 1035 ms (12.6 MiB/s)
6118624 bytes read in 467 ms (12.5 MiB/s)
Found mainline kernel configuration
29102 bytes read in 9 ms (3.1 MiB/s)
504 bytes read in 9 ms (54.7 KiB/s)
Applying kernel provided DT overlay sun8i-h3-usbhost0.dtbo
504 bytes read in 9 ms (54.7 KiB/s)
Applying kernel provided DT overlay sun8i-h3-usbhost2.dtbo
504 bytes read in 9 ms (54.7 KiB/s)
Applying kernel provided DT overlay sun8i-h3-usbhost3.dtbo
4185 bytes read in 9 ms (454.1 KiB/s)
Applying kernel provided DT fixup script (sun8i-h3-fixup.scr)
## Executing script at 44000000
## Loading init Ramdisk from Legacy Image at 43300000 ...
   Image Name:   uInitrd
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    13628847 Bytes = 13 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 43000000
   Booting using the fdt blob at 0x43000000
   Loading Ramdisk to 49300000, end 49fff5af ... OK
   Loading Device Tree to 49290000, end 492fffff ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

and it just stop after booting the kernel

 

On 7/6/2020 at 12:06 PM, Werner said:

You could checkout at a specific commit which should be the one before the one Igor mentioned

Try that: https://stackoverflow.com/questions/7539130/go-to-particular-revision

 

Behavior confirmed with sunxi-current Focal on OrangePi One. I will play a little around with kernel options...

 

Thanks man

 

Forgot to emphasize that the serial is working in the last versions too.

So it is working before the one that I checked  and in the last one available, it is not working only specifically in that one.

 

So the serial does not hold me back from testing new staff, but I don't know the specific commit that the serial was fixed so I can't check if that commit was the first place that the snap bug was introduced.

Edited July 14, 20206 yr by Guy
More info

Tested the new image and it is working now.

 

Thanks everyone for your help.

 

Can be closed