Some context: I’m hacking my DIY embassy to enable kiosk mode on a Raspberry Pi that is connected to a 7" LCD touchscreen. Instead of using the provided kiosk.sh script (which opens Firefox to the embassy web UI), I’ve written my own startup script that runs a custom Tkinter GUI (Python) using the same window manager (matchbox). The application is a simple dashboard, right now only for Bitcoin Core, but it can also switch between the dashboard, Firefox, and xterm.
I’ve got a lot of the above already figured out, but my real question has to do with making sure my custom changes persist across OS updates. I’ve been testing in a VM and here’s what I’ve learned:
For the files I add and change in /home/start9/ to persist through a reboot, I need to copy these changes to /media/embassy/embassyfs/current/home/start9/. I have a backup function in my .bash_aliases that takes care of this with some rsyncs.
For apt installations to persist through a reboot (for example, for my dashboard: python3-tk, python3-pil, etc.), I need to chroot to /media/embassy/embassyfs/current/ and then perform my sudo apt install _____ commands there. I was doing this manually, which required moving and restoring the /etc/resolv.conf file in order for the chroot to have internet access. But I have since discovered the /usr/lib/embassy/scripts/chroot-and-upgrade script which is much simpler. This script also keeps files that have been added to the embassyfs/current directory.
I have not yet figured out how to get the above changes (files and installs) to persist through an OS update. After an update, the /media/embassy/embassyfs/current/home/start9/ (and thus also /home/start9/) directory is reset to how it was on a fresh install. Right now, I have to rsync the home directory from embassyfs/next to both embassyfs/current and $HOME and redo the chroot to perform all installs. I suppose I could put all of the above in my own script (restore-after-update) and run it myself after I update, but I was just wondering if there is something I’m missing that could make it so that all these changes persist automatically. I’d also just like to know more about this method of managing the filesystem. I’d appreciate any info or resources, if any exist. I’ve perused the Github repo but haven’t seen anything like a guide or basic explanation on this.
(Yes, I know DIY hacks are not supported and there’s no guarantee I won’t break something. That’s why I’ve been doing it all in a VM for now.)
“I suppose I could put all of the above in my own script (restore-after-update) and run it myself after I update”
If you follow this path, then postinit.sh might be helpful as it persists after a major update such as from EmbassyOS to StartOS.
How to setup
After SSH’ing into your StartOS make and edit the file with this:
sudo su -
vim /media/embassy/config/postinit.sh
Here is what I have in mine as an example:
#!/bin/bash
# Last updated: 2023-05-21
# Note: This script was not overwritten when upgrading from EmbassyOS to StartOS - 2023-05-21
# =======================================
# StartOS post boot script for automation
# =======================================
#
# After SSH'ed into your StartOS create this file with following:
#
# sudo su -
# vim /media/embassy/config/postinit.sh
# Fix for laptop lid causing ~80%+ CPU usage when closed
# ======================================================
# Append LidSwitch config within /etc/systemd/logind.conf
echo -e "\nHandleLidSwitch=ignore\nHandleLidSwitchExternalPower=ignore\nHandleLidSwitchDocked=ignore\nLidSwitchIgnoreInhibited=off" >> /etc/systemd/logind.conf
# Restart systemd-logind.service
systemctl restart systemd-logind.service
# Use 'top' to check that systemd-logind is not using ~80%+ CPU time when laptop lid is closed.
# Put other automation below this
# ======================================================
Thank you for this post! I have already leaned a few things I wanted to know like how to install with apt and have that persist after a reboot! Thanks!
Interesting! The /media/embassy/config/postinit.sh (and preinit.sh) scripts look very useful. I wasn’t aware of them.
It looks like they are called every time the OS starts (although I could be mistaken). I’ll have to make sure the script can reliably determine whether an update occured before attempting rsyncs and apt installs. Thanks for the idea.
Btw, check out the persist-apt-install script, which makes use of the chroot-and-upgrade script. I think it is meant to be used like this: sudo /usr/lib/embassy/scripts/persist-apt-install package-1 package-2 ...