DietPi-Software | Chromium: Allow to start kiosk mode as non-root

[fvbakel]

Creating a bug report/issue

Chromium browser does not autostart in kiosk mode on DietPi_VirtualBox-x86_64-Buster. Using the dietpi-software menu I installed option 113, the Cromium browser auto start option.

Other complete desktop environments are working fine on this same Virtualbox image.

Required Information

• DietPi version | cat /boot/dietpi/.version:
  dietpi@dietpi1:~$ cat /boot/dietpi/.version
  G_DIETPI_VERSION_CORE=7
  G_DIETPI_VERSION_SUB=1
  G_DIETPI_VERSION_RC=2
  G_GITBRANCH='master'
  G_GITOWNER='MichaIng'
• Distro version | echo $G_DISTRO_NAME or cat /etc/debian_version
  10.9
• Kernel version | uname -a
Linux dietpi1 4.19.0-16-amd64 #1 SMP Debian 4.19.181-1 (2021-03-19) x86_64 GNU/Linux
• SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3)
  Virtual Machine (x86_64)
• Power supply used | (EG: 5V 1A RAVpower)
  Not applicable
• SDcard used | (EG: SanDisk ultra)
  Not applicable, using vmdk file as virtual disk

Additional Information (if applicable)

• Software title | (EG: Nextcloud)
  Chromium
• Was the software title installed freshly or updated/migrated?
  Fresh install
• Can this issue be replicated on a fresh installation of DietPi?
  Yes
• Bug report ID | echo $G_HW_UUID
  98f1e04a-a5ff-4df7-81f7-5093138bfc1b

Steps to reproduce

1. Download the DietPi_VirtualBox-x86_64-Buster ova file
2. Import the appliance in virtual box
3. Boot up the virtual pi server
4. login as dietpi
5. sudo dietpi-software
6. Browse software, select option 133 Chromium: web browser for desktop or autostart
7. OK
8. Install
9. OK
10. OK
11. Install begins at this point, wait for the install to complete
12. sudo dietpi-config
13. select 9 : AutoStart Options
14. select 11 : Chromium - Dedicated use without desktop
15. Leave the site to dietpi.com, select OK
16. Run as dietpi:1000
17. exit the config
18. After the install is complete: sudo reboot
19. the reboot is done, but there is an error after the reboot. I guess this error is due to the fact that the X server is not installed properly

Note that the host OS for virtiual box is a fresh install of Lununtu 21.04.

Expected behaviour

I expected Chromium to autostart after these steps

Actual behaviour

There is an error after the reboot:

• Chromium does not start in kiosk mode.

Extra details

• Known workaround:
• install Xfce desktop environment first
• Uninstall Xfce, but leave the X.org server
• reinstall the chromium browser autostart

[Joulinar]

Hi,

I guess you would need to select user root if you like to run Chromium on autostart. If I'm not mistaken, this is still a limitation atm. As you can see on your error screen, you have permission denied on /dev/tty0

[fvbakel]

Hi,
Added the log file for the start as the dietpi user.
Xorg.0.log

Tried again, but this time with the auto start as the root user. That indeed does start the chromium browser. Still I think that is not correct behaviour. It should be possible to run as the dietpi user, or any other user with no other priviledges.

[Joulinar]

As I said, this is a limitation at the moment. You can try adding user dietpi into video group usermod -aG video dietpi

[fvbakel]

I also tried with usermod -aG video dietpi , and reboot after that. That does not seem to solve the issue.

[Joulinar]

probably other permissions are required as well. Usually Xorg.0.log will give a hint.

[MichaIng]

Just to rule it out: usermod -aG render dietpi
But yes, there are GPUs/drivers where it is not easily possible to run an X server as non-root user. We'll implement a method for this with next version (based on LightDM autologin).

No need to reboot for testing btw, just execute the launcher directly:

/var/lib/dietpi/dietpi-software/installed/chromium-autostart.sh

And yes, please check /var/log/Xorg.0.log in case.

---

In VirtualBox one can btw change the emulated GPU, which could make a difference. E.g. try VMSVGA or VBoxSVGA.

[fvbakel]

I have tried all three emulated GPU's in virtual box, including VMSVGA and VBoxSVGA. No improvement with these, I am now using VMSVGA.
I also tried usermod -aG render dietpi, no improvement in that.
The file /var/log/Xorg.0.log is empty.

[MichaIng]

The file /var/log/Xorg.0.log is empty.

Directly after manually calling the script? 🤔
Does the script itself output anything then?

[fvbakel]

Yes, directly after running the script. See console output in the screenshot below:

[Joulinar]

User dietpi is storing the log file on different place. As you can see on the error message it's located on /home/dietpi/.local/...

[MichaIng]

Ah, how could I missed that, of course 😄:

cat /home/dietpi/.local/share/xorg/Xorg.0.log

[fvbakel]

I checked that /home/dietpi/.local/share/xorg/Xorg.0.log file, it is the same as the one I already added to this issue: https://github.com/MichaIng/DietPi/files/6489010/Xorg.0.log

[Joulinar]

That's the error message

[     5.236] (II) LoadModule: "fbdev"
[     5.237] (WW) Warning, couldn't open module fbdev
[     5.237] (EE) Failed to load module "fbdev" (module does not exist, 0)
[     5.237] (II) LoadModule: "vesa"
[     5.237] (WW) Warning, couldn't open module vesa
[     5.237] (EE) Failed to load module "vesa" (module does not exist, 0)
[     5.237] (II) vmware: driver for VMware SVGA: vmware0405, vmware0710
[     5.237] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[     5.237] (EE) 
Fatal server error:
[     5.238] (EE) parse_vt_settings: Cannot open /dev/tty0 (Permission denied)
[     5.238] (EE) 
[     5.239] (EE)

Still permission issues

[fvbakel]

I found a simple solution, that is to bind the Xorg server to vt1 instead of vt0.
I changed in /var/lib/dietpi/dietpi-software/installed/chromium-autostart.sh
The last line from
xinit $FP_CHROMIUM $CHROMIUM_OPTS
to
xinit $FP_CHROMIUM $CHROMIUM_OPTS -- vt1

This seem to solve the issue. The Xorg server is now running with the user dietpi:
ps -ef |grep Xorg
Output
dietpi 1612 1611 0 15:49 tty1 00:00:00 /usr/lib/xorg/Xorg :0 vt1

[MichaIng]

Ah, yes when running the command/script from a different console/TTY as where the X server shall start on, the user needs to be in tty group as well:

usermod -aG tty dietpi

[fvbakel]

I tried with the original /var/lib/dietpi/dietpi-software/installed/chromium-autostart.sh and the sudo usermod -aG tty dietpi.
This does not solve the issue, in this case the autostart still does not work.

[Joulinar]

What is the error message now?

[fvbakel]

I get the following results with the original start command and the sudo usermod -aG tty dietpi in place:

The console screenshot

The log file:
Xorg.0.log

[MichaIng]

[    15.679] (EE) xf86OpenConsole: Cannot open virtual console 2 (Permission denied)

Strange, as the tty group should permit writes to that tty:

ls -l /dev/tty2

Probably read permissions are required. Could you try:

sudo chmod 660 /dev/tty2
/var/lib/dietpi/dietpi-software/installed/chromium-autostart.sh

[fvbakel]

I tried with
sudo chmod 660 /dev/tty2 /var/lib/dietpi/dietpi-software/installed/chromium-autostart.sh' That works and starts Chromium. However after a reboot it does not work. It seems that after a reboot the protection of /dev/tty2` is set back to the original values.

So:
'sudo chmod 660 /dev/tty2
ls -l /dev/tty2
crw-rw---- 1 root tty 4, 2 May 16 19:00 /dev/tty2
sudo reboot'
After the reboot
`ls -l /dev/tty2
crw--w---- 1 root tty 4, 2 May 16 19:04 /dev/tty2'

[MichaIng]

Jep that makes sense, those device files are freshly created on boot, so changing them is not permanent. Interesting the read permissions are required.

The following will apply it automatically on boot:

echo 'SUBSYSTEM=="tty", KERNEL=="tty[0-9]*", MODE="0660"' > /etc/udev/rules.d/99-tty-group-write-permissions.rules

[Joulinar]

would it not make more sense to run the kiosk as user root for the time being and wait until next release where you will have finished the new feature (based on LightDM autologin)? I mean it's just another 2 weeks. Just to make some pressure 😜

[MichaIng]

Okay, so while autologin to desktops (default desktop sessions) works well with #4390, in case of Chromium we have a wrapper script that includes xinit itself. We'd need to extract the essential parts and make a /usr/share/xsessions/chromium-kiosk.desktop entry from it, which can be started by LightDM automatically. Probably you can help me to extract or simplify the script and we might be able to get rid of it completely:

#!/bin/bash
# Autostart run script for Kiosk mode, based on @AYapejian https://github.com/MichaIng/DietPi/issues/1737#issue-318697621
# - Please see /root/.chromium-browser.init (and /etc/chromium.d/custom_flags) for additional egl/gl init options
# Command line switches https://peter.sh/experiments/chromium-command-line-switches/
# --test-type gets rid of some of the chromium warnings that you may or may not care about in kiosk on a LAN
# --pull-to-refresh=1
# --ash-host-window-bounds="400,300"
# Resolution to use for kiosk mode, should ideally match current system resolution
RES_X=$(sed -n '/^[[:blank:]]*SOFTWARE_CHROMIUM_RES_X=/{s/^[^=]*=//p;q}' /boot/dietpi.txt)
RES_Y=$(sed -n '/^[[:blank:]]*SOFTWARE_CHROMIUM_RES_Y=/{s/^[^=]*=//p;q}' /boot/dietpi.txt)
CHROMIUM_OPTS="--kiosk --test-type --window-size=$RES_X,$RES_Y --start-fullscreen --start-maximized --window-position=0,0"
# If you want tablet mode, uncomment the next line.
#CHROMIUM_OPTS+=' --force-tablet-mode --tablet-ui'
# Add URL for first run:
URL=$(sed -n '/^[[:blank:]]*SOFTWARE_CHROMIUM_AUTOSTART_URL=/{s/^[^=]*=//p;q}' /boot/dietpi.txt)
CHROMIUM_OPTS+=" --homepage $URL"
# Find absolute filepath location of Chromium binary.
FP_CHROMIUM=$(command -v chromium)
if [[ ! $FP_CHROMIUM ]]; then
	# Assume RPi
	FP_CHROMIUM="$(command -v chromium-browser)"
fi
xinit $FP_CHROMIUM $CHROMIUM_OPTS

Actually I tested to skip all flags, aside of --kiosk $URL, and it works pretty well, even better:

• In my tests, Chromium with --kiosk always opens in fullscreen mode. The defined window size can either make it too small or too large (parts of the website outside of screen), skipping it makes it suite perfectly fine.
• --start-fullscreen --start-maximized have no effect, which makes sense as its not a window on a desktop but itself the only content of the whole X server screen.
• --window-position=0,0 makes a little border appear at the bottom and right. Without defining a window size, there is a tiny border around it, moving it to 0,0 makes it not being centered anymore. At that point I did see that indeed with a matching window size it could be made slightly larger, but to me it doesn't seem to be worth the effort, especially when this means that two dietpi.txt settings need to be manually set and adjusted when the screen resolution changes.
• --homepage actually defines the URL of new tabs, while appending the URL without this option starts Chromium with this URL, practically both the same in kiosk mode.
• --test-type is part of the default flags we already set, so it is doubled here.

But we might want to add other flags: #2938 #3389

• --noerrdialogs
• --disable-component-update
• --disable-translate seems to have been removed: https://groups.google.com/a/chromium.org/g/chromium-reviews/c/nOgks4a7_uI
  • Alternative to test: --disable-features=TranslateUI

[Joulinar]

I guess following was addressed to @fvbakel

Probably you can help me to extract or simplify the script

[fvbakel]

Hi, I am willing to test some of these settings on my virtual box. However, it will somewhere later this week. Kind regards, Frank Op do 20 mei 2021 00:09 schreef Joulinar ***@***.***>:

…

I guess following was addressed to @fvbakel <https://github.com/fvbakel> Probably you can help me to extract or simplify the script — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4379 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEYYVDQRKGPK5D7VBCDHG43TOQZJZANCNFSM446X6YZA> .

[MichaIng]

Thanks. It was not addressed to anyone specific, but just that we should generally review and test the flags and whether we finally need an extra script or whether we put everything into /usr/share/xsessions/chromium-kiosk.desktop (and dietpi-login for root) directly.

[MichaIng]

By chance I found that using startx and having systemd-logind enabled works very well as non-root user. Need to further test on ARMs, but non-root users seem to get all required permissions that way, even for desktops.

Did a lot of cleanup and changed our autostart script accordingly: f5dedc3

This is how it can be tested:

apt install libpam-systemd
systemctl unmask systemd-logind
systemctl start systemd-logind

Then in a new session as non-root user:

startx /usr/bin/chromium

On RPi it needs to be:

startx /usr/bin/chromium-browser

[bruzzz]

Hi,

I ve just tested it on a RPi and on the first try it did not work. In the logfile " /home//.local/share/xorg/Xorg.0.log" I saw errors similar to:
[ 1657.144] (EE) open /dev/fb0: Permission denied
Inverstigating this further I found a hint here to add the user to the group video:
sudo usermod -aG video <non-root-user>

I also copied the file ~/.chromium-browser.init from root to the non-root-user in order to adapt the flags of chromium.

After doing that and a reboot, it works like a charm....

You probably should add this step to the dietpi-autostart tool (when configuring a non-root-user).

[MichaIng]

Which RPi model and which Debian/Raspbian version was this? And in case Chromium was installed already, did you try to reinstall it (to have systemd-logind enabled, e.g.)?

[bruzzz]

DietPi v8.2.2 
Device model : RPi 4 Model B (aarch64)

Distributor ID: Debian
Description:    Debian GNU/Linux 11 (bullseye)
Release:        11
Codename:       bullseye

I just did an upgarde from v7.4.2 to v8.2.2 and from buster to bullseye yesterday according to this howto. And reinstalled chromium after that as well.

Btw. on the upgrade to 8.2.2 I needed to do a little manual fix:

### update DietPi from v7.4.2 to v8.2.2 ###

[ INFO ] DietPi-Patch | Patching to DietPi v8.2...
[FAILED] DietPi-Patch | mv /etc/chromium.d/custom_flags /etc/chromium-browser/customizations/dietpi
root@enoceanPi:/tmp/DietPi-Patch# ls -lha /etc/chromium.d/
total 28K
drwxr-xr-x  2 root root 4.0K Aug  1  2021 .
drwxr-xr-x 67 root root 4.0K Mar 12 15:35 ..
-rw-r--r--  1 root root   80 Feb  4  2021 README
-rw-r--r--  1 root root  292 Feb  4  2021 apikeys
-rw-r--r--  1 root root  255 Aug  1  2021 custom_flags
-rw-r--r--  1 root root  609 Feb  4  2021 default-flags
-rw-r--r--  1 root root  299 Feb  4  2021 extensions
root@enoceanPi:/tmp/DietPi-Patch# mkdir -p /etc/chromium-browser/customizations
root@enoceanPi:/tmp/DietPi-Patch# exit
exit
[  OK  ] DietPi-Patch | mv /etc/chromium.d/custom_flags /etc/chromium-browser/customizations/dietpi
[  OK  ] DietPi-Patch | rm -R /etc/chromium.d
[  OK  ] DietPi-Patch | Patched to DietPi v8.2
[ INFO ] DietPi-Update | APT autopurge, please wait...
[  OK  ] DietPi-Update | APT autopurge
[  OK  ] DietPi-Update | Incremental patching to v8.2.2 completed
[ INFO ] DietPi-Update | Checking for available live patches
[ INFO ] DietPi-Update | No live patches are currently available

 DietPi-Update
─────────────────────────────────────────────────────
 Phase: Completed

But after that I needed to copy the moved flags file back to its former location otherwise chromium was failing to start because of that file missing. But it's a different topic and I didn't look into that further yet (the manual copy was a quick workaround, which was fine for the moment).

[MichaIng]

When doing the distro upgrade, did you follow our guide and either rebooted or ran /boot/dietpi/func/dietpi-obtain_hw_model before doing the dietpi-update? Because the patch you fixed manually should run on Buster only, /etc/chromium-browser is not used on Bullseye.

[bruzzz]

As I wrote above, I followed the howto (it looks the same as your link is pointing to). But I did dietpi-update before the distro upgrade. So the issue mentioned above was on buster. Thanks for the hint!

But as I said, it was just a side note (nothing to do with this thread actually).

I think the user missed to be added to group 'video' is still a bug in dietpi-autostart (when configuring chromium to be started as non-root-user in kiosk mode).

[MichaIng]

Please try to reinstall Chromium now after the update to Bullseye, and you can remove rm -R /etc/chromium-browser then as it is obsolete on Bullseye. When I tested on RPi, with startx Chromium started without the need to be in video group, since permissions to start the X server were granted via systemd-logind and PAM. What I am not sure about is whether I tested this with legacy framebuffer driver as well (which you currently use).

---

You did dietpi-update before the distro upgrade and /etc/chromium-browser/customizations was missing? I just verified that this directory is directly shipped by the chromium-browser package (on Buster), so it must exist unless you removed it manually 🤔. However, doesn't matter now on Bullseye where it has been aligned with the Debian package to use /etc/chromium.d instead.

[bruzzz]

I did reinstall cromium already and thanks for the hint that it's safe tor remove the folder /etc/chromium-browser.

You did dietpi-update before the distro upgrade and /etc/chromium-browser/customizations was missing?
Yes, exactly.

Regarding the driver: To be hornest, I didn't spend time to look into that yet. I'm using this 52pi display and I didn't install / configure anything specific (except the configuration in /boot/config.txt as refered in the wiki. It was actually working fine out-of-the-box. So not sure, if there is any other driver I can / shall use instead.

[MichaIng]

You could try it with KMS. From what I see those configs do not prevent or force a specific display stack:

G_CONFIG_INJECT 'dtoverlay=vc4-f?kms-v3d' 'dtoverlay=vc4-kms-v3d' /boot/config.txt
reboot

With this, output to the display is not done via framebuffer device /dev/fb0 but via DRI device /dev/dri/card0 which should provide better performance and is the default on Raspberry Pi OS since Bullseye as well. Probably this is required for startx as non-root without being member of video group.

[bruzzz]

Thank you very much for the hint! I just removed the user from the video group and tested it. It works fine that way!

However, there seems to be another issue in the autostart script. I don't know, if it was there earlier already (I didn't notice it before), but when doing the latest test I saw following on the boot screen (tried to find, whether it was logged in some file as well but without success):
/var/lib/dietpi/dietpi-software/installed/chromium-autostart.sh: 24: [: kiosk: unexpected operator

kiosk is the name of my user. And the this is the linee in question:
[ "$USER" == 'root' ] || STARTX='startx'

A quick search on web pointed me to this article. So I tried a quick test by changing the first line of that script file from #!/bin/dash to #!/bin/bash and that seems to work. But according to post 381 in the mentioned article, another fix might be to replacing == by =.

Any idea on that? Is there maybe someting else wrong with some config?

[MichaIng]

Ah, good find. It didn't cause any issue since startx works as root user as well. But let me fix it. Replacing == with = is the intended fix, since we want to use the lighter/faster dash here: d35076a

Okay, so this find and #5342 means we should definitely enable KMS with Chromium automatically.

[bruzzz]

Maybe one more thing worth mentioning it: in syslog I noticed this error:
systemd[1]: Starting User Manager for UID 1001...
systemd[525]: gpgconf: error running '/usr/lib/gnupg/scdaemon': probably not installed
which maybe related to autologin.

Or maybe not related to autologin... It's actually repeated for every user.

Not sure, if it's the right way, but I resolved it by installing scdaemon

[MichaIng]

The question is whether is causes any issues. I guess it is as of startx X session environment setup. A common console autologin does not cause such error... Although based on this RPi forum thread it does for an SSH session 🤔: https://forums.raspberrypi.com/viewtopic.php?p=1936099

I however never saw this error on any of my many systems and test systems, strange. Would be interesting to know whether you see it as well on SSH login, or autologin without Chromium startup, or indeed on Chromium start only.