ARM6-variant Discussion

[dhhdev]

So... after working for some time. Getting annoyed at my Raspian Lite still having a Display Manager. I took the challenge, and made something only using matchbox-window-manager, unclutter, midori and xorg/xinit/xtools.

And - I'm controlling it all with Init.d:

#! /bin/sh
# Author: Daniel H. Hemmingsen <dhh@v5.dk>

### BEGIN INIT INFO
# Provides:          fullpageos
# Required-Start:    $remote_fs $syslog
# Required-Stop:     $remote_fs $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: FullPageOS start/stop init.d script.
# Description:       FullPageOS start/stop init.d script. Handles all the stuff needed to boot up FullPageOS. Midori is the browser, unclutter hides the mouse and matchbox-window-manager is the Window Manager.
### END INIT INFO

case "$1" in
  start)
    echo "Starting X Display in the background..."
    X :0 &
    sleep 2
    export DISPLAY=:0

    echo "Disabling annoying default X behaviour..."
    xset s off
    xset -dpms
    xset s noblank

    echo "Starting Unclutter in the background..."
    /usr/bin/unclutter &

    echo "Starting Matchbox Window Manager in the background..."
    /usr/bin/matchbox-window-manager &

    echo "Starting Midori..."
    /usr/bin/midori -e Fullscreen -a https://google.com
    ;;
  stop)
    echo "Stopping Unclutter"
    killall unclutter

    echo "Stopping Matchbox Window Manager"
    killall matchbox-window-manager

    echo "Stopping Midori"
    killall midori

    echo "Stopping Xorg"
    killall Xorg
    ;;
  *)
    echo "Usage: /etc/init.d/fullpageos {start|stop}"
    exit 1
    ;;
esac

exit 0

So now, I can simply do service fullpageos start/stop. I haven't installed the webserver yet, since this was just testing the actual FullPageOS. (Where we get content from in the browser, is something different. But simply installing this like we already do; would be a-ok.)

On my old Raspberry Pi. I could get some pretty low RAM usage. (Remember, no webserver yet. But should be fine.)

pi@raspberrypi:~ $ free -h
             total       used       free     shared    buffers     cached
Mem:          434M       192M       242M       4.9M        10M       108M
-/+ buffers/cache:        73M       361M
Swap:          99M         0B        99M

Of course, this is not done yet. I would check for $network in the script and check for if the lighttpd server is up, etc.

But what do you guys think, at least for older devices only running on ARM6? I would be happy to hear your thoughts.

[guysoft]

Is there anything you need done on my end so this could work as a variant?
Is having a switch to disable chromium install enough?

[dhhdev]

The best would be if a variant could simply overwrite everything, including chroot_script. Because, I don't see any reason to actually make flags - instead people could just simply use the already there templates. (in src/)
If that's not desired, a way to simply import a list of stuff somebody would like to install instead. (A list or something.) Would be awesome. At least that's my thoughts at the moment.

[dhhdev]

To clarify:

I.e., src/variants/arm6-lite/ would have following files:

filesystem (etc)
config
chroot_script

Just like out in the root of src. And with the ./build simply checking for the second variant argument like it already does it. But then just use stuff inside that variant folder only. (If present.)

[dhhdev]

Actually, having a variant/default as the main folder for the default build. Would make most sense. And just having the second argument by default being default. Just some thoughts here. Who knows, there might be some drastic versions/variants later on. And having them all by a single folder, not depending on anything but their own folder. (Besides the src/build file.) Might be the best solution in the long run.

This is of course just a discussion in the end. It's just my thoughts. 👍

[guysoft]

@dhhdev Currently a variant would not overwrite anything in chroot_script because there is stuff you do want that is identical across variants, for example the vnc support, the webserver setup, handling the ld preloads because otherwise things break, etc. The main chroot_script however should include switches that let you disable stuff which can be optional in a variant.

I released RC2 today and I think it fixes all problems. Once that is released we can start changing the architecture if we think its required. I don't want to change it right away.

[dhhdev]

@guysoft That's great. I'm a "drastic" guy by heart, and love stuff that just works with minimal configuration. I got a Raspberry Pi 3 Model A home from work just now. I just walked in the door after 9+ hours at the office today. So now I can test on both ARM6 and ARM11. (ARM8, which Raspberry Pi 2 has - should be more like ARM11. So I don't see problems arising there, the big jump is from ARM6 to ARM7.)

When I say lite I mean it by the way. I tested some stuff out. I got a Midori Kiosk Mode working with only "4" packages. (sudo apt-get install midori x11-xserver-utils matchbox Xorg) And made a temporary hacky-hack solution with init.d. (As in the script, doesn't really clean up other than just killing everything, concept - but works.) It uses roughly 200 MB of RAM that way. It could be great for ARM6 I reckon.

Why init.d? Simple, one file.

sudo systemctl enable fullpageos.service
sudo service fullpageos <start|stop|restart>

I'm looking forward to be hacking on something for ARM6 this weekend. Cheers! 👍 (And maybe some ARM11, refining stuff.) I love this project. Keep it up!

[guysoft]

You are using systemd commands with an init.d file, might be better to use a systemd file.

Here is an example:
https://github.com/guysoft/FullPageOS/blob/devel/src/filesystem/root_init/etc/systemd/system/clear_lighttpd_cache.service

Easier to read and more modern.
You place them in that folder, and then enable with:

systemctl enable clear_lighttpd_cache.service

[dhhdev]

@guysoft True, but it's actually supported behaviour from back when people moved from init.d to systemd on many systems. In the end, it wouldn't require much - less or more really. But it might look a bit more clean. Preferences I guess. 👍 After all, I was just testing around. 😄

[guysoft]

@dhhdev Hey, check out this commit:
6f47e51

Now you can create a variant that would use your scripts. And disable chromium install using FULLPAGEOS_INCLUDE_CHROMIUM=no in the config file on that variant. And make a script that would replace this with the start command:

sudo -u pi sed -i 's@%BROWSER_START_SCRIPT%@/home/pi/scripts/start_chromium_browser@g' /home/pi/scripts/run_onepageos

You can see an example here:
https://github.com/guysoft/FullPageOS/tree/devel/src/variants/example
Here is a slightly more advanced example:
https://github.com/guysoft/OctoPi/tree/armbian/src/variants/armbian

[guysoft]

Hey, it seems like Armv6 is supported in the latest Raspbian, so CustomPiOS works, its just slow as hell, So closing

[carson-katri]

How would I use this script? Just install the components and copy the init.d script?

[carson-katri]

I'm using Raspbian Stretch LITE on a zero

[guysoft]

Just flash the image. I'm not supporting it for a zero though, its too slow.

[guysoft]

Fixed, it works now, tested, its slow as hell and takes 5-10 minutes to boot. Might work as a digital picture frame.