Guy Posted July 6, 2020 Posted July 6, 2020 (edited) Armbianmonitor: http://ix.io/2r0a 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, 2020 by pfeerick Added 'solved' tag
Igor Posted July 6, 2020 Posted July 6, 2020 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?
Guy Posted July 6, 2020 Author Posted July 6, 2020 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.
Werner Posted July 6, 2020 Posted July 6, 2020 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...
Werner Posted July 6, 2020 Posted July 6, 2020 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.
Igor Posted July 6, 2020 Posted July 6, 2020 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 ...
Werner Posted July 6, 2020 Posted July 6, 2020 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...
sfx2000 Posted July 11, 2020 Posted July 11, 2020 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...
Guy Posted July 11, 2020 Author Posted July 11, 2020 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
Guy Posted July 14, 2020 Author Posted July 14, 2020 (edited) 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, 2020 by Guy More info
Guy Posted July 25, 2020 Author Posted July 25, 2020 Tested the new image and it is working now. Thanks everyone for your help. Can be closed
Recommended Posts