[TESTING] Debian Stretch upgrade for OSMC


The upgrade is a two step process - first we bring your system up to date with the latest jessie version of OSMC which will be a normal size update, at the end of this we modify /etc/apt/sources.list to point to the stretch repos.

The system then reboots and automatically triggers another update check to do the migration to stretch. This can be anywhere between 300-500 packages to upgrade. Yesterday (after most of you tested) we added an additional disk space check for this second phase download which will refuse to proceed if you have less than 300MB free on the root filesystem and 30MB free on /boot. (applicable to Pi’s) This is to avoid running out of user (non root reserved) space during the update which may cause Kodi to crash. The first stage update via My OSMC already had this disk space check in place.

If enough space is not available it will display a warning and then reboot back into Kodi. The system will be perfectly usable but you will still effectively be stuck on Jessie until you free up space and check for updates again, then the migration will proceed.


No. No… Cause some services (transmission, samba, etc) is pointed to /media/iomega… When I use fstab, I mount always in /mnt (/media deletes all mountpoint on every reboot)

On one of my reinstallations, I changed this but without notice…

BTW, the update touches all systemd modifications made by me (made-by-hand services are not enabled and transmission user change reverted), but i think it’s normal (I suppose with apt-get upgrade ask permission to revert changes on files, but unattended installation forces to write package-version)


Can you describe exactly how you’re modifying the systemd services ?

The proper way to modify them which won’t be overwritten by updates is to either copy the service unit file from /lib/systemd/system to /etc/systemd/system and modify it there (/etc/systemd/system is the local administrator location for service units that always takes priority over /lib/systemd/system) in which case the package provided unit is always ignored and overridden by your custom unit file, or you can use systemd drop-in’s:


These work like an overlay and let you add or override individual directives in a unit file but still use the package supplied unit file for all other directives. The advantage of this is if you only want to make one change to a unit and would still like package updates to to the unit file to take effect except for your one override.

Along with a unit file foo.service, a “drop-in” directory foo.service.d/ may exist. All files with the suffix “.conf” from this directory will be parsed after the file itself is parsed. This is useful to alter or add configuration settings for a unit, without having to modify unit files. Each drop-in file must have appropriate section headers. Note that for instantiated units, this logic will first look for the instance “.d/” subdirectory and read its “.conf” files, followed by the template “.d/” subdirectory and the “.conf” files there. Also note that settings from the “[Install]” section are not honored in drop-in unit files, and have no effect.

Systemd unit files in /lib/systemd/system are not marked as conffiles so are always overwritten by package updates that contain that file, so you never want to edit them directly.


Yeah, I know…

For example, I’ve got a noip dns updater. The unit is made by me and is on /etc/systemd/system/noip.service… After update, the service was not enabled and I need enable it again.

And the file /etc/systemd/system/multi-user.target.wants/transmission-daemon.service defines the user for transmission. I edited this file for osmc user for transmission, and after update, the file was with USER=debian-transmission again.


That shouldn’t happen. We don’t do anything that would cause that.

I think you’ve got your path muddled up there. You should be copying your version of the unit directly to /etc/systemd/system. The files in /etc/systemd/system/multi-user.target.wants are symlinks to the services in /lib/systemd/system created by systemctl enable so by editing those you would be editing the versions in /lib/systemd/system - which means they will get overwritten on package upgrade…


The upgrade seemed to work fine for me on my Vero 4K.

The curses Package Configuration screen did change size unexpectedly during the upgrade - from full screen to about 60% and in the top left corner.

And the sad face/reboot occurred about 15 seconds after mediacenter first launched, but did not recur.

Also, as reported above, the uninstallation of no-longer-required packages also did not occur:

osmc@vero4k:~$ sudo apt-get dist-upgrade
Reading package lists… Done
Building dependency tree
Reading state information… Done
Calculating upgrade… Done
The following packages were automatically installed and are no longer required:
armv7-libcrossguid-osmc bluez libapt-inst1.5 libasn1-8-heimdal libbind9-90
libdbus-1-dev libdns100 libdpkg-perl libgif4 libgnutls-deb0-28
libhcrypto4-heimdal libhdb9-heimdal libheimbase1-heimdal libhogweed2
libhx509-5-heimdal libicu52 libisc95 libisccc90 libisccfg90
libkrb5-26-heimdal liblwres90 libmicrohttpd10 libmysqlclient18 libnettle4
libntdb1 libplist2 libpng12-0 libpsl0 libroken18-heimdal libssl1.0.0
libwebp5 libwebpdemux1 libwebpmux1 libwind0-heimdal libxtables10 pkg-config
python-dbus-dev python-ntdb
Use ‘sudo apt autoremove’ to remove them.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

The process took about 30 minutes over my least reliable (Powerline) wired connection.

Thanks for this Sam.


Thanks for testing.

This is intentional to avoid problems with those that have built against libs or headers that are already present on the system.

Are you using a 4K TV? We might need to check our scaling works correctly.


No, I’m using a 1080p plasma. And it usually takes an age (4-5 seconds) to switch resolutions, and shows the new resolution as an overlay - that did not happen, it just instantly resized.


Found and fixed:

Turns out its not a critical error, just systemd having a moan but the script ran fine anyway. :slight_smile:


So no more Bluetooth audio?


I just upgraded my sistem (RPi 2). It went quite smoothly except for an error saying the upgrade had trouble installing fail2ban. I removed the package for the time being so it’s all good now!
Thanks a lot for the work you’re putting into this.


Likely for a while, yes. The current method (Pulse) based really isn’t ideal for the long term.


Installed on a Pi2. No problems. Thanks!

Only surprise is that the version still says OSMC 2017.10-1, though the Kodi version is 17.6, compiled 11/23/17.
Linux version is 4.9.29-11…


OSMC Version will only be bumped on final release


I’m missing the scrollbar using the OSMC skin in menu

Music -> Albums

Can’t say, whether it was available before Debian Stretch but if I enable/disable the scrollbars in the menu displayed using the left button there, it does not show any effect.

This inconsistent behaviour can be seen in other sub-menus of Music as well.


Upgraded my two RPI3’s and all seems to work ok , apart from two item,

  1. had some perl scripts running from crontab - they were broken - needed to reinstall cpanm .
  2. shared some usb disks with films between the RPI’s - this has stopped working,
  • will try to share the /media directory instead.
  1. I did the upgrade to see if the temperature dropped on the core ( thats what the perlscrips in 1) was doing)
    I have 70 celsius idling and 50 celcius watching a movie :slight_smile:
    I have transmission installed but nothing else
  • from “top” kodi sits at a some 50 % cpu and on the other osmc ; kodi takes 5%


Please make this version STABLE, no more random reinstall required because the Pi won’t just power on for no reason and no SSH access.


We haven’t had reports of these problems. Please provide debug logs so we can look into this further.


Unfortunately I can’t, I had to reinstall the OS from scratch. The OS was no longer powering on, no IP address or anything.

I would happily provide logs in the future - if I can access the Pi that is.


That doesn’t sound right at all. Remember that this is a testing build however