Raspberry Pi 3 - Browser Client: Difference between revisions
Alpineuser (talk | contribs) |
Alpineuser (talk | contribs) No edit summary |
||
Line 1: | Line 1: | ||
This is a guide for setting up a RAM based RPI3 which is able to run X, and firefox. This tutorial will go through setting up auto login for Alpine, and starting X on boot without user interaction. It is a type of kiosk machine. | This is a guide for setting up a RAM based RPI3 which is able to run X, and firefox. This tutorial will go through setting up auto login for Alpine, and starting X on boot without user interaction. It is a type of kiosk machine. | ||
'''Tested as of 05/2020''' | '''Tested as of 05/2020''' - RPI | ||
'''12/2020''' - x86 | |||
==Overview== | ==Overview== |
Revision as of 04:36, 24 December 2020
This is a guide for setting up a RAM based RPI3 which is able to run X, and firefox. This tutorial will go through setting up auto login for Alpine, and starting X on boot without user interaction. It is a type of kiosk machine.
Tested as of 05/2020 - RPI 12/2020 - x86
Overview
This guide uses the following:
- aarch64 img
- RPI3
- community repo is used.
It is based off of this guide: Raspberry_Pi. Due to the dependencies required to run X and FF, there is very little RAM disk space for the user to operate in, after this tutorial is complete (about 30MB is v3.11). Take this into consideration. It's possible that the RPI4 with its additional RAM, may fare better.
aarch64 is used, because firefox-esr is in the community repo. armhf (as of v3.11) does not have firefox prepackaged in the base or community repo.
See https://pkgs.alpinelinux.org/packages?name=*firefox*&branch=v3.11&arch=aarch64
Note that the aarch64 build is not compatible with all RPI. See Raspberry Pi.
Steps
Base Install
These steps are duplicated from Raspberry_Pi page.
Use fdisk or gdisk to format the SD card. You must have the first partition be a bootable, FAT filesystem. e.g.:
Command (m for help): p Disk /dev/sdb: 59.5 GiB, 63864569856 bytes, 124735488 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x00000000 Device Boot Start End Sectors Size Id Type /dev/sdb1 * 2048 62916607 62914560 30G b W95 FAT32
mkdosfs -F 32 /dev/sdX1
untar onto mounted disk
mount /dev/sdX1 /mnt/folder tar xvf archive.tar -C /mnt/folder/.
If you plan to enable increased RAM (e.g. for RPI4 with 2 or 4GB) or other config settings, do so in a usercfg.txt now.
Again, duplicating the Raspberry Pi page
Insert the SD card into the Raspberry Pi and turn it on Login into the Alpine system as root. Leave the password empty. Type setup-alpine Once the installation is complete, commit the changes by typing lbu commit -d
saving space: busybox instead of chronyd, dropbear instead of openssh
After setup, make sure dropbear is installed
apk add dropbear
Start it:
rc-service dropbear start
Add it to the default runlevel:
rc-update add dropbear
If you need an accurate clock, enable software/ntp here (optional, i don't need a clock for the website I view).
rc-update add swclock boot # enable the software clock rc-update del hwclock boot # disable the hardware clock setup-ntp
Browser Client Install
Enable community repo (/etc/apk/repositories) (uncomment community)
nano /etc/apk/repositories apk update
install firefox and X dependencies:
apk add libx11-dev libxft-dev libxinerama-dev adwaita-gtk2-theme adwaita-icon-theme ttf-dejavu
Note that the fonts/icon theme are required for FF to display correctly. Without these, firefox will load, but text will not render on the browser menus.
the RAM tmp fs remaining can be viewed while installing, with watch df -h
install firefox
apk add firefox-esr
install X
setup-xorg-base
The RPI also requires for X:
apk add xf86-video-fbdev
note: this command can vary if you are using x86. For example, I installed no xf86-video... drivers, and had a libEGL.so missing library error on Xorg, and that was resolved via "apk search libEGL.so" which pointed to mesa-egl. Note that apk search is case sensitive.
At this point, we have about 421MB used up (if NTP was not setup).
Filesystem Size Used Available Use% Mounted on devtmpfs 10.0M 0 10.0M 0% /dev shm 457.9M 0 457.9M 0% /dev/shm /dev/mmcblk0p1 30.0G 259.4M 29.7G 1% /media/mmcblk0p1 tmpfs 457.9M 420.0M 37.9M 92% / tmpfs 91.6M 188.0K 91.4M 0% /run /dev/loop0 24.9M 24.9M 0 100% /.modloop
lbu_commit -d
AutoLogin, Startx automatically on Boot
At this point, you should be able to login as root, and run startx manually. Now, we will add a number of configuration files that allow this to happen without user interaction.
/root/ doesn't save any files, so it's necessary to edit files in /etc/ and lbu_commit -d after all changes. First let's add a file that will call firefox. lbu_commit is alpine local backup. If you want to save folders other than /etc see:https://wiki.alpinelinux.org/wiki/Alpine_local_backup#Include_special_files.2Ffolders_to_the_apkovl also see: /etc/apk/protected_paths.d/lbu.list
create a file named /etc/startup.sh:
#!/bin/ash firefox http://somewebsite.com
We have to edit xinitrc, and the profile configs. Normally, this would be done in the user's directory, but here we will use the globals for simplicity.
mv /etc/X11/xinit/xinitrc /etc/X11/xinit/xinitrc_BAK nano /etc/X11/xinit/xinitrc
In this file put:
/etc/startup.sh
At the end of /etc/profile (leave the existing file) append
startx
And remember to: lbu_commit -d For autologin, alpine uses busybox, which has an alias to /sbin/getty as well as /bin/login. It's possible to navigate to /sbin/ or /bin/ and run /sbin/getty -h to see what settings are available. To have root auto login upon boot, review the existing inittab and edit as needed, according to the config below.
# Set up a couple of getty's #tty1::respawn:/sbin/getty 38400 tty1 tty2::respawn:/sbin/getty 38400 tty2 tty3::respawn:/sbin/getty 38400 tty3 tty4::respawn:/sbin/getty 38400 tty4 tty5::respawn:/sbin/getty 38400 tty5 tty6::respawn:/sbin/getty 38400 tty6 tty1::respawn:/bin/login -f root
Disable Screensaver, and refresh webpage (optional)
As a kiosk, the RPI will need to have the screensaver (DPMS) disabled. Also, my particular application (video streams) required a refresh occasionally. These were managed with xorg.conf, xdotool, and crontab respectively.
Contents of /etc/X11/xorg.conf
# apk add xdotool
# crontab -u root -e * * * * * DISPLAY=:0 /usr/bin/xdotool key F5
Note that xset is not an option here, as it's not included by default. It can be installed from repositories, if needed. That's it. Now reboot, and watch the RPI boot into firefox without user intervention. At this point, you have a functioning minimal OS booting from RAM, with firefox, and ~30MB of available space for further configuration.
Tips/Troubleshooting
Why was this setup used? Why not Awesome, or dwm?
I ran through a few different setups of alpine on the rpi, and found that (dwm | awesome) & firefox required too many dependencies to run on an RPI3 with 512MB in /tmp (running in RAM), or other browsers which used less dependencies were unstable (the application was viewing video streams). Therefore, running firefox direct off X was just barely able to fit into the available space, and was stable. This is one of the reasons aarch64 was used, instead of armhf. RPI4 w/more ram may not have this issue.
If your application doesn't require media (i.e. a static webpage) you may be able to run other browsers, such as midori, falkon, or surf, without stability issues on the RPI.
It is possible that VLC would also fit into the limited space on the RPI. This was not tested.
Width & height of firefox doesn't fit the monitor
Firefox can be called with -height and -width flags, e.g.
firefox -width 480 -height 640 somewebsite.com
Periodic Firefox Crashes due to Low Memory
With the RPI3, I found firefox crashing reliably after a couple days uptime of watching video. On the server I saw notices of memory running out. This may have been a memory leak, and with the small amount of RAM available, it would crash firefox, leaving the screen blank.
The solution was to setup a nightly reboot of the system via cron, and this has kept the system stable since. However, if I was to do this again, I would try an RPI4 with >1GB ram which may obviate the need for a nightly reboot.