OSMC update process details

The Wiki needs an FAQ entry on how the update process for OSMC works. Much of what I’m writing in this post could be way off, simply because I’m not sure I understand the details.

By reading here, I see posts about backing up before update, the possibility that a bad update could brick the device, etc. Some of this would be difficult for non-technical users to understand, like where do you place the backup so that it is safe (SMB browsing being broken doesn’t help here), what is the backup for (it appears to be just Kodi user settings, but misses some important files that people here change, like Lircmap.xml), and some is downright scary (like the bricking part).

I’m pretty experienced with the Debian update system, and I can’t see how an update could ever “brick” the device. Sure, it could make it not boot, or it could make some hardware not function, but then all you have to do is boot off the old kernel, and at least you’d have SSH available, even if Kodi, etc., isn’t working right. From there, you could roll back to older versions of packages (either through restore from backup, or apt and forcing a specific version), and everything should just work again.

So, it really looks like the only missing step is a way to select a different kernel at boot time (like in normal grub installs), and then either a minimal graphic recovery system, or a text-based one. You could even leave a cache of the last known good versions of crucial packages (like the vero3-* and mediacenter-* packages), so that a downgrade/revert doesn’t even need a working network. Now, it might require that the user get a USB keyboard plugged in if the default remote is hosed, but that’s not too much of a hardship for most people.

On the other hand, if an update re-images the system, then that’s doing it completely the wrong way, since then every little change a user has made that isn’t part of Kodi (adding apps through My OSMC, tweaked network config, lircd changes, anything using apt-get, etc.) has to be re-done.

I’ve dealt with this sort of “update via image” in VMware ESXi, and it doesn’t take me long to create a script that I run after an image upgrade that puts back all the config changes that the system designers forgot that people might want change. At least with that, the new image only wipes the boot device, which is usually quite small. Here, it will nuke everything, including the extra 12GB on the Vero 4K that are available to the user. If imaging is the way to go for upgrades, then it should be a partition image that is only as big as necessary (maybe 4GB), leaving the rest of the NAND available and untouched for a user to create and mount partitions.

And, again, for less technical people, that means that even one little custom change that they managed to work through after hours of reading this forum and other Internet sources becomes not worth doing. And, if they can’t keep the setup they want, maybe they drop OSMC/Vero for something else, and warn other people not to buy.

OSMC uses the normal APT mechanism that you’re already familiar with. No “update via image” occurs.

Generally speaking, “bricking” of the system usually occurs as a result of an SD card fallure or filesystem corruption due to power-supply issues. Of course, there are edge cases, but these two comprise the majority of issues where a system won’t boot. While more technicaly adept people might see a challenge in fixing such a problem, by far the easiest solution is a fresh reinstall.

OSMC keeps one previous kernel version and .deb packages are usually still available in the APT cache.

1 Like


Thanks for the post. I appreciate your concerns about OSMC’s update system and wanted to clarify a few things.

The update system will slightly vary from device to device. For example, with our impending PC release, you will see that we use GRUB. On Raspberry Pi, there is a binary blob to kick off the boot process; and on Vero devices, there is an open source U-Boot solution for booting.

I’m not sure where you’ve read that – it’s very hard to brick the Vero 4K unless you overwrite specific portions of the eMMC. This cannot be done via any APT process however. And to clarify: by brick, we do mean a reinstall of OSMC from scratch.

OSMC is a Debian derivative and follows Debian policy. In short: this means that you can update via OSMC or apt-get dist-upgrade. apt-get upgrade can cause problems, but Debian policy officially advises against this since 2009. It won’t break your device, but it may earn you a reinstallation. You’d of course be able to boot, lift files and the like, but things may not entirely work as expected.

Backups are always better on another device. Otherwise they aren’t really to be considered backups.

SMB browsing is not broken. It is deprecated for security reasons. We do not want any OSMC device to participate in the proliferation of the next WannaCry-like attack.

If you have a legacy device, or an unpatched server, you can select SMBv1 in Kodi and still browse SMB shares however.

You won’t brick your device from any APT operations, but you may need to reinstall it if you make significant changes. For example, if you install a full X11 desktop, you will rightly notice that the default boot behaviour may change. There are 50,000 packages in Debian Stretch’s repository, and we can’t provide support for every permutation and use case. But you will always be able to get OSMC and Vero 4K back to a usable state if worst comes to worst.

OSMC’s update system is transactional, with full dependency handling. It does not fully rewrite the root filesystem on update and changes are honoured across updates where appropriate (conffiles).

OSMC already has a built in recovery system.

You have CTRL + Shift for emergencies. I believe the two behaviours here are documented in the Wiki. You will indeed need a keyboard.

Other distributions are more locked down in their nature, and as such prevent this. We don’t feel this is the correct solution.

OSMC provides an extremely flexible system and you should enjoy it, particularly as you have experience with Debian. As always – should you run in to any problems, let us know here and we will be happy to help.


You can also edit /etc/osmc/prefs.d/update_preferences to keep all kernels on update.

I was under the impression that this only works with GUI-based updates. As I recall, command-line updates will only keep one previous version.


dist-upgrade used to cause problems – if you were flipping between kernels and it wasn’t considered the ‘active one’. But this was resolved in June:

You actually made those changes available to resolve that :slight_smile:

We may want to consult the file in that script to prevent autoremoval, but if they flip it back to autoremoval, it will be a tricky one…


You rumbled me. It’s a fair cop, guv’nor. :slight_smile:

I’ll take a look.