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

[Robert Nelson]

Hey everyone,

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

https://rcn-ee.net/rootfs/bb.org/testing/2017-04-18/stretch-iot/

BBB-blank = eMMC flasher
bone- = run from microSD (Please have v2017.05-rc1 or later in eMMC
thou: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays
)

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.

Regards,

--
Robert Nelson
https://rcn-ee.com/

[William Hermans]

How soon before a stretch console image ?

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYircpHfY57ULrDKJXvOvATeiSAdhpLT7s%3DYdiKuOeBORg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Mark A. Yoder]

Robert:

  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.

--Mark 

[Robert Nelson]

On Wed, Apr 19, 2017 at 1:34 PM, Mark A. Yoder <mark.a...@gmail.com> wrote:
> Robert:
> 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..

[Robert Nelson]

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?

[Mark A. Yoder]

Yup, mode 674 works.

--Mark

[Mark A. Yoder]

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.

--Mark

[William Hermans]

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 ?

--

For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/eaa04298-81a4-4af0-a033-fe369e458cc7%40googlegroups.com.

[William Hermans]

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.

[William Hermans]

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:
        32768

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
/root

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

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
lost+found

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

<no output>

[William Hermans]

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.

[Robert Nelson]

On Wed, Apr 19, 2017 at 2:38 PM, Mark A. Yoder <mark.a...@gmail.com> wrote:
> 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.

Okay give the bone101 package update a shot:

sudo apt update ; sudo apt upgrade

1: backup old example folder:

https://github.com/rcn-ee/repos/blob/master/debian-9-bone101/suite/stretch/debian/preinst#L3-L9

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

https://github.com/rcn-ee/repos/blob/master/debian-9-bone101/suite/stretch/debian/postinst#L51-L58

[Mark A. Yoder]

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.

--Mark

[Robert Nelson]

On Apr 20, 2017 4:34 PM, "Mark A. Yoder" <mark.a...@gmail.com> wrote:

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

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Disable_on-board_devices

Add this to /boot/uEnv.txt

disable_uboot_overlay_audio=1

And reboot.

Regards

[Mark A. Yoder]

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?

--Mark

[Robert Nelson]

On Thu, Apr 20, 2017 at 8:09 PM, Mark A. Yoder <mark.a...@gmail.com> wrote:
> 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. .;)

[Robert Nelson]

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/version.sh
[sudo] password for debian:
git:/opt/scripts/:[2b5b51be63fd8e31721012a3f2dc96f25fe42741]
eeprom:[A335BNLT00C02516BBBK2626]
dogtag:[BeagleBoard.org Debian Image 2017-04-16]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot
2017.05-rc2-00002-gbcecad]
kernel:[4.4.61-ti-r98]
nodejs:[v6.10.2]
debian@beaglebone:~$

u-boot:

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
[disable_uboot_overlay_emmc=1]...
uboot_overlays: uboot loading of
[/lib/firmware/BB-HDMI-TDA998x-00A0.dtbo] disabled by /boot/uEnv.txt
[disable_uboot_overlay_audio=1]...
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 ...

[Mark A. Yoder]

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

--Mark

[William Hermans]

On Fri, Apr 21, 2017 at 10:34 AM, Mark A. Yoder <mark.a...@gmail.com> wrote:

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

--Mark

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.