Our Neo and Micro range of products come pre-installed with our Thinux Embedded Linux operating system.
Thinux is based on Ubuntu Linux. As of the writing of this article, it is based on Ubuntu 20.04.3 LTS. However, there are some significant changes between Ubuntu and Thinux. One is that we include drivers specific to our hardware, that are not be available in upstream repositories. We also include system services that protect the hardware from damage. This might seem strange to folks who are used to using PCs with a BIOS. Processors manufactured by Intel and AMD are usually pretty good at self preservation – they throttle their speeds and turn off some cores when they are close to overheating. In the worst case, they work with the BIOS to abruptly power off the computer rather than burn out. This level of protection is still not available with ARM processors. The uboot bootloader used with ARM systems does not stay in memory once it transfers control to Linux, and thus does not work in the background to protect hardware components from thermal or other damage.
Which is why, when customers contact us to disable or replace Thinux on our ARM based products, we must inform them that this would void their hardware warranty. This policy is in line with what Android based mobile phone manufacturers have in place, when you contact them to unlock bootloaders. You must call or write to us in order to get the system root password, and we must mark your device as warranty void before giving you the password, if your device is ARM based.
The primary change between Thinux and Ubuntu is that the Thinux root file system is mounted read-only. This means that you cannot use apt and other commands to make changes to the OS. If you have the root password, you can make changes to
/var. Even when the user does not have the root password, processes that run with root privilege make changes to
/var. These changes are actually stored not in the
/ partition, but in the
/overlay partition. You can read more about the overlay filesystem on kernel.org.
In order to make changes to
/, you must first remount the
/ filesystem in read-write mode. Here are the commands that you need to issue on a terminal:
su - (please enter the root password) umount -l /etc umount -l /var mount -o rw,remount /
Now you can make changes to
/. After your work is done, you can reboot the system to have the root filesystem back in rw mode.
Let us say you no longer want to use the read-only root feature of Thinux. In order to permanently turn it off, you will need to make the following some changes to
/etc/fstab. First, lazy
umount /etc like we showed you in the previous code segment. Your typical
/etc/fstab file will look like this:
proc /proc proc defaults 0 0 LABEL=thinux / ext4 defaults,ro,noatime 0 1 LABEL=data /overlay data defaults,noatime 0 2 mount_over /etc over defaults,x-systemd.requires-mounts-for=/overlay 0 0 mount_over /var over defaults,x-systemd.requires-mounts-for=/overlay 0 0 mount_over /home over defaults,x-systemd.requires-mounts-for=/overlay 0 0 mount_over /tmp over defaults,x-systemd.requires-mounts-for=/overlay 0 0 /overlay/swapfile swap swap pri=-1,x-systemd.requires-mounts-for=/overlay 0 0
Change it to look like this:
proc /proc proc defaults 0 0 LABEL=thinux / ext4 defaults,rw,noatime 0 1 LABEL=data /overlay data defaults,noatime 0 2 #mount_over /etc over defaults,x-systemd.requires-mounts-for=/overlay 0 0 #mount_over /var over defaults,x-systemd.requires-mounts-for=/overlay 0 0 mount_over /home over defaults,x-systemd.requires-mounts-for=/overlay 0 0 mount_over /tmp over defaults,x-systemd.requires-mounts-for=/overlay 0 0 /overlay/swapfile swap swap pri=-1,x-systemd.requires-mounts-for=/overlay 0 0
So why do we use a read only root filesystem? More than 99% of our customers do not need to install new software on their computers. They use their computers as thin clients or cloud computers – which means they largely use the RDP client, or the web browser, to do their work. The pre-installed software such as LibreOffice are enough for them to get their work done. Now, instead of updating their computers using apt, which updates individual packages, we are able to upgrade their entire root file system in one shot, like a binary blob. This is similar to how other embedded operating systems such as Android or iOS update (except they have apps; we don’t). This allows us to test the updates we release very thoroughly on our own hardware, before we release it, and ensure that all changes and refreshed applications in the update work well with each other. We are also able to prevent the user’s computers from getting dysfunctional because an apt or dpkg upgrade was interrupted in the middle – our update system is able to gracefully handle abrupt poweroffs.