[TESTING] Debian Stretch upgrade for OSMC


Vero 4K
Just upgraded by method advised.
No issues to report.
Files over NFS from NAS OK
YouTube Addon OK
BBC iPlayer OK
TvHeadend DVB-T USB Dongle OK, but no DVB-T2

Upgraded without issues
Files over NFS from NAS OK
YouTube Addon OK
BBC iPlayer OK
TvHeadend DVB-T/T2 USB Dongle OK

Not sure if this is an OS/Drivers or a Kodi problem
Would be good if the issue over drivers for your DVB-T/T2 Stick could get into the next update as well!
Still no DVB-T2 showing in tvheadend on Vero 4K.

Thanks for all the hard work.


Hi Sam,

To try this:

Login via the command line6
Edit the file /etc/apt/sources.list
Add the following line: deb http://apt.osmc.tv jessie-devel main
Check for updates via My OSMC -> Updater.

It found an update. Installed, black screen. Again blue screen waiting for a connection to the OSMC update server. After a minute or so the message, “No internet connection”.

Now rebooting and trying again.

Update have been downloaded, would you like to exit and install the updates now?


Installing packages.

0% - 100%


Sad face
Restarts automatically
Starts normal

Mysql database connection works

Check for updates again

There are no updates available

After updating, you may wish to edit /etc/apt/sources.list again. Change stretch-devel to stretch to revert back to OSMC’s stable update channel

I think you mean jessie-devel to stretch? You stated,

“NB: jessie-devel instead of stretch-devel is intentional.”

Ahh in the sources it is now stretch-devel. Changed.


Will post here if there are any issues.

Kind regards,



Thanks for the report. I suspect it might be useful if people could say which devices have been tested.

You mean MySQL server on your device or elsewhere?


Device is a Vero 4K.

Connection is to a MySQL database running on a Synology docker for the videodatabase and musicdatabase in advancedsettings.xml.

Also the CIFS shares to the Synology come up just fine. I configured this in systemd/system.


Hi. Everything goes ok except:

  1. NFS Server

nfs-kernel-server tries to go up before mounting media, despite the systemd policies

  1. OpenVPN

openvpn server starts ok (in systemctl and logs) but I cannot connect until restart server

I think it’s a systemd problem (dependencies with old configurations) and both services were installed by me “manually” without OSMC help.

All about OSMC works ok with stretch

Thank you Sam and team!


Have updated 2 of my systems, both via My OSMC.

Pi0 - WiFi connection, Standard install: Update process took a loooong time (didn’t actually time it but was 1 hour+), but all went smoothly and everything seems to be working OK.

Pi2 - Ethernet connection, Standard install + TVH: Update process was quicker, although still took a while. Again, all went smoothly and everything seems OK, although I’ve not done much testing of TVH as it is for backup/testing purposes on this system and doesn’t get used much.

I have noticed that on both of these systems dmesg shows the following:

systemd[1]: [/lib/systemd/system/connman-wait-for-network.service:9] Invalid escape sequences in line, correcting: "/bin/bash -c “if grep -q nfsroot /proc/cmdline; then exit 0; fi; count=60; while [ $count -gt 0 ]; do if connmanctl state | grep -iq ‘ready|online’; then break; fi; sleep 1; let count-=1; done; exit 0"”

I will be updating another system later tonight that is far more complex with lots extras installed, will report how that goes.


Hey – it’s been a while since we heard from you. Hope all is well.

We are aware of this and will look in to this. Thanks for confirming that you also experience this problem.

Keep us posted


Was OpenVPN installed via apt-get?

Can you elaborate on this one?
I assume you’re sharing a drive.

UDisks is likely starting after nfs-kernel-server. I believe that in Jessie nfs-kernel-server was still an init.d script. It should now be a systemd unit, but this would indeed change ordering and timing.

Have you made changes to the ordering of nfs-kernel-server manually? Out of the box, nfs-kernel-server’s systemd unit won’t be aware of udisks, and as a result, not know that it should be waiting. Some disks may also take some time to spin up, and they may not necessarily be present, so this will require some thought.



I may have just found something that doesn’t work. I have a2dp-app-osmc installed on the Pi2 to connect to a BT speaker I can use round the house. Was working earlier today, but after upgrading to stretch there is no option to set the Audio output device to Bluetooth, only options are HDMI, Analogue, or HDMI and Analogue. (which, I notice, are not how they used to be named). I know that a2dp is also still testing so it not working with another test is understandable, but might be something to look into.


The current implementation of A2DP is being scrapped as it isn’t sustainable for the long term.



Hey, it HAS been a while. Been pretty chaotic recently, and moving house last month didn’t help, but things are calming down now. Hope you are good.

Back to topic

Fair enough. It’s not something I use very often, just occasionally when out in the garden or when I want music in the bath. :smiley:

I have now updated the next system again via My OSMC.
Pi3 - Ethernet connection, customised install with TVH (with 2 DVB-T tuners and 1 DVB-T2), MySQL server (now MariaDB???), Samba, FTP server (app store version but with some customisation), nfs-kernel-server, ffmpeg (from deb-multimedia), deluge… probably other stuff too, but I can’t think of anything else right now:

Update process completed smoothly. Quick check so far and MySQL/MariaDB, Samba, nfs and ffmpeg are all working fine.

TVH has lost my DVB-T tuners, but I suspect that is a firmware loading issue that sometimes happens with them and just requires unplugging and replugging, will test in a bit when I can be bothered to reach them.

FTP server was not working as expected, have checked and my customised vsftpd.conf has been overwritten by the standard one (not surprising). Putting my customised version back and restarting vsftpd has fixed it.

Deluge has started, but all my torrents have ‘Error: Missing or invalid torrent data!’. I notice that the deluge version has gone from 1.3.10 under jessie to 1.3.13 under stretch and a ‘Force Re-check’ seems to be fixing the torrent, will let them all re-check and then try restarting, hopefully all will be OK.

Everything else seems to be working well. Will update if I find any other issues. I have 4 more systems (2xPi3, Pi1, Pi0w) that I can test on, but will have to update them via CLI as they are installed at my parents house and I don’t fancy the 2.5 hour drive just to get physical access to them.


What version were you on before? Big FW changes in 2017.10.

@DBMandrake – maybe we should mark vsftpd.conf as conffile?

Upstream issue unfortunately, as we don’t package or tinker with Deluge.

It’s good to hear from people with more exotic OSMC setups. Let us know how it all goes and if there’s anything we can help with.



System was up to date before the upgrade. Have tested and I was correct about the tuners not showing up due to a firmware issue. It has been an ongoing minor annoyance with this TV stick, only happens occasionally (maybe 1 in every 15-20 restarts) but on restarting the system, sometimes the firmware won’t load and then the stick needs to be totally powered down and restarted (which, with it being connected to a powered hub, means more that just restarting the system) to get it working again. I would think it is just coincidence that it has happened as I’ve upgraded the system.

As for deluge, torrents have all re-checked and deluge is working fine after a reboot.:+1:


I updated my 4K, where my MySQL database lives, and found after the upgrade that while the database worked, it was ‘read only’. Playing status didn’t update, removing a dup movie didn’t work.

If you see this, check your .kodi/temp/kodi.log for:

#1728 - Cannot load from mysql.proc. The table is probably corrupted

If you see this, just run

$ sudo mysql_upgrade -u<username> -p<password>

and that should take care of the problem.


Yes. It’s a rcurrent problem with systemd implementation for openvpn. In jessie, I need to install a backported package (2.4.0) because the stable version (2.3.8) was incompatible with systemd. However, sometimes works well on reboot and sometimes need to restart openvpn-server@server service. I need more testing on it.

The scenery is simple. I’m sharing one USB drive. My whole system is on sdcard and I have a ext4 usb drive attached to raspi.

When system boots at first time:

osmc@osmc:~$ sudo service nfs-kernel-server status
● nfs-server.service - NFS server and services
   Loaded: loaded (/lib/systemd/system/nfs-server.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Wed 2017-11-29 20:45:09 CET; 2min 57s ago
  Process: 331 ExecStartPre=/usr/sbin/exportfs -r (code=exited, status=1/FAILURE)

nov 29 20:45:09 osmc systemd[1]: Starting NFS server and services...
nov 29 20:45:09 osmc exportfs[331]: exportfs: Failed to stat /media/iomega: No such file or directory
nov 29 20:45:09 osmc systemd[1]: nfs-server.service: Control process exited, code=exited status=1
nov 29 20:45:09 osmc systemd[1]: Failed to start NFS server and services.
nov 29 20:45:09 osmc systemd[1]: nfs-server.service: Unit entered failed state.
nov 29 20:45:09 osmc systemd[1]: nfs-server.service: Failed with result 'exit-code'.

Just simply start de service with system booted and everything works ok.

osmc@osmc:~$ sudo service nfs-kernel-server start
osmc@osmc:~$ sudo service nfs-kernel-server status
● nfs-server.service - NFS server and services
   Loaded: loaded (/lib/systemd/system/nfs-server.service; enabled; vendor preset: enabled)
   Active: active (exited) since Wed 2017-11-29 20:48:09 CET; 1s ago
  Process: 1338 ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS (code=exited, status=0/SUCCESS)
  Process: 1336 ExecStartPre=/usr/sbin/exportfs -r (code=exited, status=0/SUCCESS)
 Main PID: 1338 (code=exited, status=0/SUCCESS)

nov 29 20:48:09 osmc systemd[1]: Starting NFS server and services...
nov 29 20:48:09 osmc systemd[1]: Started NFS server and services.

Yes, it seems nfs starts before usb disk drive is mounted. But, at dependencies I see requires proc-fs-nfsd.mount, which I think depends on udisks, but no!

osmc@osmc:~$ sudo systemctl list-dependencies nfs-kernel-server
● ├─auth-rpcgss-module.service
● ├─nfs-config.service
● ├─nfs-idmapd.service
● ├─nfs-mountd.service
● ├─proc-fs-nfsd.mount
● ├─rpc-svcgssd.service
● ├─rpcbind.socket
● ├─system.slice
● └─network.target
osmc@osmc:~$ sudo systemctl list-dependencies nfs-mountd
● ├─nfs-config.service
● ├─nfs-server.service
● ├─proc-fs-nfsd.mount
● └─system.slice
osmc@osmc:~$ sudo systemctl list-dependencies proc-fs-nfsd.mount 
● └─system.slice

However, if I see the systemd unit for nfs-kernel-server, it explicits “After= local-fs.target”, but in journalctl -xa, I see the service starts up after udisks.service but before udisks-glue.service (Is udisks-glue which finally mount the drives?)

I’ll try to put After= udisks-glue.service, and I’ll post the results.


Ok… I’ve analyzed journalctl and nfs-server (and nfs-kernel-server… i don’t know why I have two similar services) starts after udisks-glue succesfully terminated, but the unit is not automounted yet…

Here is all journalctl until boot finish


If you are just relying on udisks to mount your disks then nfs server will not wait for this to happen. Waiting on the udisks service will not help you because the service having started does not mean the disk is mounted yet.

This has always been the case that it can’t be relied upon but the timing of the startup of nfserver may have changed in stretch.

You probably have two options:

  1. Mount your drive in fstab to ensure that it is mounted before nfs-server - mounting it here will give it dependencies that will force nfs server to wait. For example on my system I have:

UUID=09bf0117-fb6e-4fe9-8dcb-7c99f30bd8fd /mnt/USBMEDIA ext4 defaults,noatime,auto,nofail,x-systemd.mount-timeout=60 0 0

for my USB media drive which is also shared by nfs server. nofail ensures that if the drive is not connected that after a 90 timeout and error the system will continue to boot rather than drop to a systemd emergency shell.

  1. Make /media your nfs server export rather than a specific subdirectory below it. /media always exists so nfs server should be happy to start, as soon as a directory appears below it after automounting the clients will see it. This will only work if you are happy for all automounted drives to be shared with the same nfs permissions of course. If not, use individual fstab mounts as above under /mnt and individual exports.

Help automount at boot NFS share external HDD

Yup. This works after you have re-configured your clients.


yes. I’m declaring this disk on fsta… What thaaa… I didn’t look there!!! Yes, my fstab is empty now!!

Thanks DBMandrake! Never take anything for granted!!!


Are you saying the upgrade wiped your fstab file ? As far as I know we don’t touch a users fstab file during any upgrades.