OSMC as immutable OS

I’ve been using Fedora Kinoite, an immutable OS, as my daily driver for more than a year now. It has been a far more stable experience than using mutable Linuxes.

As OSMC is meant to be an appliance OS, I imagine having it be immutable could bring many benefits.

Some pros of immutability (my experience with rpm-ostree):

  • Offline updates are lightning quick.
  • if something breaks in an update, rolling back is super easy.
  • Since messing with the root filesystem is discouraged, tinkering and breakage happens less.
  • all base systems are identical, and if one isn’t, it’s easy to know how it’s different.

Some cons:

  • no online updates, you need to reboot.
  • no dkms support.
  • tinkering and experimenting is more difficult

Bac when I was a newbie user of OSMC, the major reason for going OSMC instead of LE was getting access to a “whole linux” under the nice GUI. I mean I could even “accidently” move libc6.so, true I had to reimage, but I would not use OSMC if I couldn’t fiddle with the OS underneath.

I think i had about 6 Web service running at the same time as i watched a movie on my pi2. I could never install a github project on a immutable OS, on a whim.

But living on the “edge” like that means, I do backups before “Whimming it”. Know your system and know your selling point.

I definitely see your point, but I’d argue that toolboxes / distroboxes takes care of most usual tinkering scenarios. The charm then, is that you don’t need comprehensive backup strategies, and can experiment more freely, in a way, since no amount of tinkering in a toolbox will cause damage to the base OS.

I have Ubuntu, Arch and Fedora, each in separate distroboxes, and I can experiment and do basically everything short of modifying the kernel in the boxes. Accessing each distrobox’ graphical apps, binaries and services from the base system is easy, without disturbing the system itself.

I have about 20 github projects installed on my system, and they work just fine. I just can’t move them to the read-only part of the base system.
Pip adds packages to writable part of system, as does nix and flatpak. They don’t need rebooting between updates.

A recent OSMC update took ~10 minutes of ugly grey-and-blue TUI wait before I could use the system again. With ostree, it would only take as much time as a reboot.

I don’t know how many OSMC users have tinker-ability as a priority, and how many are convinced by my points. But immutable OSMC is an interesting concept, and I’d like us to take it into consideration.

As you said;

Do we have data about what most users consider OSMC’s selling points?


It’s always good to get new feature requests and understand user requirements more.

What device are you using? Unless you’re doing a major distribution upgrade (i.e. from Buster to Bullseye); updates shouldn’t take so long unless you have a slow SD card or a lot of packages (defeating the point of a locked down rootfs) installed. The update screen needs some work and will be improved, but this is not relevant to whether the root filesystem is writable. If updates are taking 10+ minutes and are not major distribution upgrades, your SD card is faulty or you haven’t updated in a long time.

Updates are also dependent on your connection.

I’ve never described OSMC as an appliance OS. You can use LibreELEC for that which is a great OS. OSMC wants to expose the full functionality and expansion capabilities of Debian. If you don’t touch the command line, you will have smooth upgrades. If you touch the command line, you can make mistakes; but changes are generally well tolerated. Update times may be slightly slower than LE – but a couple of minutes occasionally isn’t a big deal.

If we were to have an appliance like approach – for commercial customers that have pressured this, I would look at dm-verity with overlayfs. This would allow APT capabilities but also allow reversion. We could also look at LVM and snapshotting.

There are some features for Vero 4K/4K+ we will introduce for allowing quick restoration of a device’s state.

I don’t plan to change the direction of OSMC for a single user, as I’m sure you can understand. Our objective is to provide a minimal, but expansive Debian base, and it works. I’ve seen many requests and take them seriously - but I rarely see a request to cripple OSMC functionality rather than add functionality.

The only major OSMC updates that need a reboot are usually kernel and bootloader - things you are not touching in your testing on your PC. These updates are frequent on OSMC and not comparable to your headless setup

Thanks for your understanding


Hi, thanks for checking in.

My device is a Vero 4K+, running the latest testing debian version. I last updated 7-20 days ago (exact date is fuzzy). I’m glad to hear that the upgrade screen will see some love. My connection is indeed slow, but doesn’t OSMC download all updates before applying them?

This is just me trying to explain what I mean with Appliance OS, without knowing if there’s an actual definition of the term.
There are a couple robot vacuum cleaners in which it’s relatively easy to get a root shell, exposing a full Linux system. Do I still think of the operating system it runs as an Appliance OS? Absolutely, because it’s a vacuum cleaner, it has a specific application. OSMC (on my Vero4K+) similarly has a specific application (playing media), and it’s necessary to use a remote shell to do more. For non-technical users and for me, it has a specific application.
Now, this was just my perspective, and others are entitled to theirs. Surely, those who use OSMC as a minecraft server, desktop OS or any of the other more general usecases out there may object to calling it an appliance OS.

I don’t see my desktop computer running Fedora Kinoite (immutable) as crippled compared to the normal version of Fedora Workstation, but again, it’s a matter of perspective.
I’m glad to hear there have been discussions about “appliancification”(?), and I respect that you’ve decided not to go down that route in the near future. I’m not the one putting in work, after all.

I truly appreciate both your efforts and engagement. Go OSMC!


Thanks for your understanding. There are already solutions in the market for this.