See above. I’m making a box for my nieces, and while Kiosk Mode and being able to remove most of the options from the menu is helpful, it hasn’t prevented me from finding ways to muck it up when people are playtesting on it. I’d like the peace of mind of knowing that no matter what they accidentally press, when they boot it up, it’ll be as it was aside from like, save files. Any advice?
If it matters, I’m using an Odroid XU4 with Lakka 2.1 and running off a micro SD card.
If you SSH into it, you should be able to change it to read-only by doing this:
chmod 0444 ~/.config/retroarch/retroarch.cfg
That sounds like it’s just what the doctor ordered. I’ll report back, thank you.
Does it look like I did this right? 
After I did that, I rebooted, entered the password to disable kiosk mode, rebooted, and kiosk mode was disabled. I’m not certain if that indicates a failure to make that file read-only or not.
This is odd. The file does appear to be set to read-only, but Lakka can still make changes to the file, which I was hoping to prevent. Is there any way to alter that behavior?
This should probably be an issue report about how kiosk mode + lakka’s overlay filesystem together are not preventing all kinds of configuration changes.
@FloraSKittens Any chance you would be willing to file an Issue with an example or two of the kinds of changes that you can still make with kiosk enabled?
Aside from a proper fix for this issue, you may need to follow the procedure described in the Lakka docs for stopping the RetroArch service before you make retroarch.cfg read-only – assuming you did not do this procedure already. I’m thinking that your permission-modified file is still getting replaced by one with the default permissions again. Here’s the relevant doc: http://www.lakka.tv/doc/Configuring-Lakka/
Before I open an issue, I want to make sure that what I’m reporting is actually an issue and not me misunderstanding how Lakka is supposed to be handling it. To that end, I followed the procedure you linked for editing the .cfg file and went through the process again. I also looked up how to use ls -l to check individual file permissions, and confirmed after rebooting that it remained set to -r–r--r–.
With it set this way, I was able to enter the password to disable kiosk mode, which changed the file, and upon rebooting, kiosk mode was indeed disabled. From there, any settings I changed would also change the file upon reboot, reflected both by timestamp as well as the specific config entry in the file’s text changing. The -r–r--r-- status of the file remained throughout.
The behavior I’m seeing that I don’t want to be seeing is that Lakka can change the config file after it’s been set to -r–r--r–. Ideally, the only way to disable Kiosk mode in this scenario would be to first reset the config file’s permissions via ssh before setting about following the in-GUI procedure. I’m not seasoned enough with Linux or Lakka to know whether this is a bug, or if Lakka is handling the permissions as intended.
As an aside, when you strip the menu down as much as it’ll let you, “disable kiosk mode” happens to be the very first option the cursor lands on when you start it up–does anyone know a way around that? Moving the main menu to the far right or even changing the order of its options around would be viable solutions.
Could you say a bit more about how you think kiosk mode is supposed to work and how it did not meet that expectation? I can’t tell precisely what the problem is from your description.
Kiosk mode puts configuration menus behind a password. From your first post it seemed like that even with kiosk mode enabled, you were able to change some settings via the GUI that persisted between Lakka reboots. It might help to start at this point in your troubleshooting process in case someone wants to reproduce the problem and the steps you have been taking to troubleshoot.
Kiosk mode works as I expect. What doesn’t work as I expect is the result of setting the configuration file to read-only. The confusion may have come when I used disabling kiosk mode as a way to test whether or not the configuration file could be changed while set to read-only. I was hoping it would cause the file to be unchangeable from within Lakka as a whole, for as long as it’s set to -r–r--r–.
@FloraSKittens thank you for clarifying your situation – indeed I was misunderstanding your situation.
I am curious about your request myself, so I took the liberty of contacting the Lakka developers in this issue: https://github.com/libretro/Lakka-LibreELEC/issues/494#issuecomment-399974640
You will see ToKe79 has posted a procedure in that issue which may fulfill your request.
Just guessing, but chmod -w won’t prevent root from writing a file. chattr +i <file> might though.
Example:
Lakka:~/.config/retroarch # cp retroarch.cfg retroarch.dummy
Lakka:~/.config/retroarch # chmod 0000 retroarch.dummy
Lakka:~/.config/retroarch # ls -l retroarch.dummy
---------- 1 root root 56130 Jun 25 21:30 retroarch.dummy
Lakka:~/.config/retroarch # echo example >> retroarch.dummy
Lakka:~/.config/retroarch # tail -1 retroarch.dummy
example
Lakka:~/.config/retroarch # chattr +i retroarch.dummy
Lakka:~/.config/retroarch # lsattr retroarch.dummy
----i---------e---- retroarch.cfg
Lakka:~/.config/retroarch # echo example2 >> retroarch.dummy
-sh: can't create retroarch.dummy: Operation not permitted
@azzid, your suggestion worked perfectly. I stopped retroarch via command line, used chattr +i , and started the process anew. I can no longer disable kiosk mode, even by correctly entering the password, and the config file’s no longer being rewritten on reboot.
For future reference, what’s the chattr command to revert it to its previous state?
To remove the immutable flag just do - instead of +:
chattr -i <file>