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.
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…
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.
Hi,
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.
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,
had some perl scripts running from crontab - they were broken - needed to reinstall cpanm .
shared some usb disks with films between the RPI’s - this has stopped working,
will try to share the /media directory instead.
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
I have transmission installed but nothing else
from “top” kodi sits at a some 50 % cpu and on the other osmc ; kodi takes 5%
