Debian Testing, un-root athon!!! (2017-04-18)

Hey everyone,

As we try to move more things from "root" -> "debian" please give
this image a shot:

BBB-blank = eMMC flasher
bone- = run from microSD (Please have v2017.05-rc1 or later in eMMC

Cloud9 to run as debian:

add 'User=debian' to the end of /lib/systemd/system/cloud9.service

and reboot..

bonescript, config-pin, adafruit_bbio all "should" work as "debian"
user.. export/unexport gpio, pwm's.. (led needs a udev rule)

Please test and find the corner cases so we can add them to the
current udev rule list.


How soon before a stretch console image ?

It looks like all the files in /var/lib/cloud9/examples are owned by root:cloud9ide and are mode 664. They need to be mode 665, or maybe 667.

Mode 667 would let people easily edit the files and experiment. Though it would also let people mess up the files.

How about we have a parallel directory to examples that serves as a backup. They could all me mode 665 and the examples files would be 667.


The debian user is part of the cloud9ide group, so the 664 should
work, or do you think it should be 674? so the cloud9ide group can
execute the file..


The other issue, that whole directory get's extracted from the bone101
package, so any changes to the package will wipe out that dir.

Unless we move the examples to github and just create a local git clone?


Yup, mode 674 works.


The big picture is: I’d like to use these in a workshop and the the participants play all they want. Once we are done I want to run one command to reset everything.

I can’t count on having internet, so a local git repo sounds like a good idea.


How about using a chroot ? Basically you keep a chroot image where ever you want, mount it where ever you want, and just wipe it out for a fresh start when you need to get back to pristine. I am trying to think what would be the smartest way to do this as you wouldn’t necessarily want to spend a long time trying to get all this done. Then it may also make better sense to run this chroot from a tmpfs. So perhaps you copy the content of the cloud9 directory, into an img file. make a zram tmpfs, then just mount it over the top of the original cloud9 directory, and extract the img contents into that ramdisk ?

By the way Mark my last comment was directed at you. But one thing I forgot to mention is that once you unmount the tmpfs directory I mention above, the original directory would be there still. So you’d want to take steps to keep from overwriting files there. I mean you could technically just revert the directory from the img file I suppose, but that would be a minor hassle at best. Also, using the zram tmpfs method i mentioned above would not require chroot at all.

Just a quick worklog to give an idea of how you set this up and how it works. Of course, you may want todo things a little differently. It depends on if you want to keep the cloud9 directory “updated” Meaning over time maybe updates have updated the files, so perhaps one could make a fresh img file very time the cloud9 directory is mounted for use. Perhaps that part could be done in memory, but keep in mind once the board loses power, that stored “data” will also be lost. Which is why I think the best way to go about things would be to store the directory structure we don’t care about in memory.

Also keep in mind that this is just an example, and the files I’m demonstrating with have nothing to do with cloud9. The overall concept however should be solid. As such, you may need to double check permissions etc. But if you use dd to create your image, directory structure along with file permissions should remain intact.

Load the zram kernel module:
root@wgd:~# modprobe zram zram_num_devices=1

Test to make sure driver module loaded:

root@wgd:~# lsmod |grep zram
zram 25049 0
zsmalloc 13745 1 zram
lz4_compress 3334 1 zram

Notice here that zram is using the lz4 compression algorithm. This can be changed.

Set the zram memory constraints:
root@wgd:~# echo ‘256M’ > /sys/block/zram0/disksize
root@wgd:~# echo ‘128M’ > /sys/block/zram0/mem_limit

Make a file system on our ramdisk:
root@wgd:~# mkfs.ext4 /dev/zram0
mke2fs 1.43 (17-May-2016)
Discarding device blocks: done
Creating filesystem with 65536 4k blocks and 65536 inodes
Filesystem UUID: 2a08c7dd-234f-497a-a89b-fe4ecbb78c3f
Superblock backups stored on blocks:

Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

List directory contents( note" ‘testfile’ is empty ):
root@wgd:~# ls
git testfile

Get our current working directory:
root@wgd:~# pwd

Find our ramdisk device:
root@wgd:~# ls /dev |grep zram*

Mount our ramdisk at /root/ ( root’s home directory ):
root@wgd:~# mount /dev/zram0 /root

The interesting part here is that we’re still seeing our original file structure:
root@wgd:~# ls
git testfile

But once we change directory . . . The new structure shows up:
root@wgd:~# cd /root/
root@wgd:~# ls

Create a new test file, and test:
root@wgd:~# touch testfile
root@wgd:~# ls
lost+found testfile
root@wgd:~# echo “Hello World” > testfile
root@wgd:~# cat testfile
Hello World

Unmount the ramdisk( note: one must change out of the mountpoint before unmounting ):
root@wgd:~# cd …
root@wgd:/# umount /root/

Change back into our root home directory and retest:
root@wgd:/# cd ~
root@wgd:~# ls
git testfile
root@wgd:~# cat testfile

Sorry, I get into thinking about some things, and forget the minor details of other things. So, dd will not work directly on a directory per se. Technically dd can be used on single files, but that’s a rather difficult way of going about things. To clarify: Using dd on a single directory, that directory would have to be on it’s own block device. e.g. You’d need to mount the cloud9 directory form it’s own /dev/sdX device. However, you could also use tar( whcih might be easier ) with I think it’s the -P flag option to preserve permissions. Double check that, I’m going form pure memory.

Okay give the bone101 package update a shot:

sudo apt update ; sudo apt upgrade

1: backup old example folder:

2: init example folder as a git repo, so it's initial state is always set:


I’m having trouble with config-pin:

$ config-pin -a P9_30 spi # Data out
$ config-pin -a P9_31 spi # Clock
P9_31 pinmux file not found!
P9_31 overlay not found
Loading cape-universala overlay
bash: line 0: echo: write error: File exists
Error loading device tree overlay file: cape-universala

P9_30 configures but P9_31 doesn’t. I’m running as debian.


Don’t use the -a option, the overlay is setup to auto load.

Those pins are the audio side of HDMI…

Add this to /boot/uEnv.txt


And reboot.


Well, I disabled the audio as described and I still get:

debian@Bone:~$ config-pin P9_31 spi
P9_31 pinmux file not found!
cape-universala overlay not found
debian@Bone:~$ config-pin -q P9_31
P9_31 pinmux file not found!
cape-universala overlay not found
run “config-pin overlay cape-universala” to load the cape
debian@Bone:~$ config-pin -q P9_32
Pin is not modifyable: P9_32 VADC
debian@Bone:~$ config-pin -q P9_28
P9_28 pinmux file not found!
cape-universala overlay not found

Could the P9_31 and P9_28 enteries be missing from the overlay?


Yuck! Thanks Mark, i'll test that tomorrow morning, it should have worked. .:wink:


debian@beaglebone:~$ config-pin -q P9.28
P9_28 Mode: default Direction: in Value: 0

debian@beaglebone:~$ config-pin -q P9.31
P9_31 Mode: default Direction: in Value: 0

debian@beaglebone:~$ config-pin -l P9.31
default gpio gpio_pu gpio_pd pwm spi pruout pruin

debian@beaglebone:~$ config-pin -l P9.28
default gpio gpio_pu gpio_pd pwm spi pwm2 pruout pruin

debian@beaglebone:~$ config-pin P9.28 pruin

debian@beaglebone:~$ config-pin P9.31 pruin

debian@beaglebone:~$ config-pin -q P9.31
P9_31 Mode: pruin

debian@beaglebone:~$ config-pin -q P9.28
P9_28 Mode: pruin

debian@beaglebone:~$ sudo /opt/scripts/tools/
[sudo] password for debian:
dogtag:[ Debian Image 2017-04-16]


Running uname_boot ...
loading /boot/vmlinuz-4.4.61-ti-r98 ...
8606904 bytes read in 557 ms (14.7 MiB/s)
uboot_overlays: [uboot_base_dtb=am335x-boneblack-uboot.dtb] ...
uboot_overlays: Switching too: dtb=am335x-boneblack-uboot.dtb ...
loading /boot/dtbs/4.4.61-ti-r98/am335x-boneblack-uboot.dtb ...
53128 bytes read in 78 ms (665 KiB/s)
uboot_overlays: [fdt_buffer=0x60000] ...
uboot_overlays: loading /lib/firmware/AM335X-20-00A0.dtbo ...
378 bytes read in 210 ms (1000 Bytes/s)
uboot_overlays: uboot loading of
[/lib/firmware/BB-BONE-eMMC1-01-00A0.dtbo] disabled by /boot/uEnv.txt
uboot_overlays: uboot loading of
[/lib/firmware/BB-HDMI-TDA998x-00A0.dtbo] disabled by /boot/uEnv.txt
uboot_overlays: loading /lib/firmware/BB-NHDMI-TDA998x-00A0.dtbo ...
2243 bytes read in 594 ms (2.9 KiB/s)
uboot_overlays: loading /lib/firmware/BB-ADC-00A0.dtbo ...
695 bytes read in 712 ms (0 Bytes/s)
uboot_overlays: loading /lib/firmware/univ-bbb-xVx-00A0.dtbo ...
73819 bytes read in 584 ms (123 KiB/s)
loading /boot/initrd.img-4.4.61-ti-r98 ...
6152958 bytes read in 405 ms (14.5 MiB/s)
debug: [console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1
root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait console=tty0
coherent_pool=1M net.ifnames=0 quiet cape_universal=enable] ...
debug: [bootz 0x82000000 0x88080000:5de2fe 88000000] ...
## Flattened Device Tree blob at 88000000
   Booting using the fdt blob at 0x88000000
   Loading Ramdisk to 8fa21000, end 8ffff2fe ... OK
   reserving fdt memory region: addr=88000000 size=77000
   Loading Device Tree to 8f9a7000, end 8fa20fff ... OK

Starting kernel ...


Hmmmm… so why does config-pin work for you and not for me?


Hmmmm.... so why does config-pin work for you and not for me?


Hi Mark,

Did yo utry loading the same overlay at boot that Robert's loading through
uboot overlays ?

uboot_overlays: loading /lib/firmware/univ-bbb-xVx-00A0.dtbo ...
73819 bytes read in 584 ms (123 KiB/s)

As for the other problem you had previously. If you have not figured that
out. universala was not getting loaded because another overlay had been
loaded prior that was using some, or very unlikely, all the same pins.