Bulletproof OSMC Pi & the read-only boot partition

Feature Requests
1

Hi everybody,

as suggested by the nice support orientation page, I am starting a conversation to pick people’s brain before opening a GitHub issue.

I have been using OSMC since the beginning and I had my fare share of time where the Pi got unplugged without a proper shutdown (TV stand with a on/off power strip). And more often that I liked, I got a Pi with a blinking cry for help due to a corrupted partition and re-imaging was necessary.

As I checked the disk layout through SSH, I noticed that the /boot has been separated from the /.
Going full-embedded paranoid, I updated my fstab to mount the /boot in read-only mode and remounted it read-only for the current day. Ever since, I got again days with brutal power off and not once I had a problem rebooting the next day (it was not every time before that but from time to time).

To make this change perfectly transparent, the only thing missing is the deb packages that provide any update to /boot (so mainly grub & kernel packages) require a pre-install command (mount -o remount,rw /boot) and post-install command (mount -o remount,ro /boot) to be able to install unattended.

As of now, I am applying updates and if they fail (like one recently), I need to do the remount myself, call apt and then remount.

I thought it would be a low-impact/high-gain idea as I am sure not 100% of users perfectly stop their Pi (especially when you use it for a video, then do something else and at the end of the day do not remember) and nobody like to pull the SD for a re-imaging or to try a repair on the current FS.

If nobody point out a big gap in this idea (or if some people think it can be beneficial and say so here), I will open eventually a GitHub issue with this idea (default fstab + pre/post for some packages).

Thanks for reading :slight_smile:

1 Like
2

You would also need to ensure that My OSMC’s offline logging can accommodate this, but remounting boot as RW from Python could have security implications.

/boot is rarely written to. I don’t think mounting it RO is going to make it any more robust.

If you’re frequently having to fixup the boot partition, I’d check your card and power supply.

1 Like
3

Hi,

sorry for the very delayed reply, life happened :smiley:

I will try to structure all the items that can easily get mixed up to be sure I paint a clear picture :slight_smile:

1) The power supply

It is well documented that running a RPi require a powerful and stable enough power supply for proper operation. After a few tests with the power from my TV on my RPi1, I have invested into a proper power supply from Element14. Later on when moving to a RPI3, I bought another one at the same time that included also a physical toggle switch (to avoid unwanted boots on power restore).

I agree with you that a quality SDCard (always went with high perf SanDisk) and quality power supply are the foundations of a happy RPi experience.

2) Media center usage

A media center usage assumes being attached to a TV for entertainment. And in this role, there is other devices like a Roku or a TiVo. In both instances (I own a Roku but just assumes for a TiVo), you do not bother with power down procedure when you are done for the day or if there is a power cut. This is why initially I was surprised to se my RPi with OSMC not like sometimes being brutally powered off. Pulling from a past life, I changed the -boot to read-only to make sure that this important part would not suffer from such scenarios. And apart from the extra action when applying a grub or kernel update, it works like a charm (even if I try to more often than not shut it down properly).

3) Integration of the read-only with updates

The main challenge to manually switching to read-only is that apt will fail to install any package that need to write on /boot.

However dpkg (through --pre-invoke/–post-invoke) and apt-get (through -c Dpkg::Pre-Invoke {" " }) can run a command right before and right after processing a package.
Documentation examples:

https://www.hackingarticles.in/linux-for-pentester-apt-privilege-escalation/

I have not looked at debian package creation but I optimistically assumed that it may be possible to include such pre/post command in the deb in order to offer a transparent install on systems that would run /boot in read-only by default (what I am suggesting).

And as a bonus, as the apt command already has to run with elevated privileges, there is no need to create a security breach and just leverage what already is in place.

As the rules are to discuss the topic here before opening a improvement ticket, I am exposing my line of reasoning here. If by chance an experience debian package maker were to also chime in about the type of obscure automation I am suggesting, that would be golden.

4

As mentioned over on GitHub, I’m happy to accept a PR for this. But consideration needs to be made with the My OSMC add-on as well.

5

That is a good point. I totally forgot the Kodi plugin.
I will look into ideas for the plugin and post them here (for review).

That is true that it would not help to protect the OS and loose the configuration UI :smile: