September Update: "armv7-udisks-glue-osmc" can not be downloaded

Hi there,

i was trying to update my vero4k in OSMC. It said that it could not download “armv7-udisks-glue-osmc”. After reboot the same messages appeared again and i did a apt-get clean, apt-get update and apt-get -f dist-upgrade over ssh, but there seems to be an issue. Any hints what to do?


Please run grab-logs -A and post the URL.

122 - PuTTY

TBH, nothing jumps out of the logs to indicate what’s happening.

Since it mentions a problem with udisks-glue.service, what’s the output of running

systemctl status udisks-glue.service

If it doesn’t say “active (running)” you could try to restart it:

sudo systemctl restart udisks-glue.service

and check its status again. However, I have a feeling this might just be an irrelevant side issue, in which case I’ll need to call in the experts.

Now that the service is running, what happens if you run sudo apt-get -f dist-upgrade again ?

I think I see what may be happening here.

Edit: should have an update to address this tomorrow.

Still no luck. Another apt-get -f dist-upgrade fails again. The service seems to run anyway. Thanks for your support so far!

Try updating again now - the update has only just gone live a few minutes ago. Remember to run apt-get update first so the new packages are found.

This did it. I had to reboot once again, because right after the update the udisks-glue-service was not running and could not be started manually. But now it seems ok and there are no pending updates shown with apt-get dist-upgrade. Thanks again for your support :slight_smile:

Thanks for the positive feedback - I had a suspicion that in your situation udisks-glue might not start immediately following the upgrade, but would after a reboot.

Previously the attempt to restart udisks-glue in the package postinst script was failing and causing the package to be marked as half installed. This would cause failed dependencies for other packages and result in a sort of circular dependency loop between package installation and service starting that you couldn’t get out of.

I’ve changed it so failing to start udisks-glue immediately during package postinst does not result in a failed package installation and hence doesn’t cause all those knock on effects. I also found we were incorrectly trying to start udisks.service manually during it’s postinst when it is a dbus socket activated service.

sudo systemctl status udisks.service
* udisks.service - Disk Manager (legacy version)
   Loaded: loaded (/lib/systemd/system/udisks.service; static)
   Active: failed (Result: exit-code) since Tue 2017-10-03 14:24:38 CEST; 27s ago
 Docs: man:udisks(7)
  Process: 773 ExecStart=/usr/lib/udisks/udisks-daemon --no-debug (code=exited, status=1/FAILURE)
 Main PID: 773 (code=exited, status=1/FAILURE)

Oct 03 14:24:38 Livingroom systemd[1]: udisks.service: main process exited, code=exited, status=1/FAILURE
Oct 03 14:24:38 Livingroom systemd[1]: Failed to start Disk Manager (legacy version).
Oct 03 14:24:38 Livingroom systemd[1]: Unit udisks.service entered failed state.

Not so much luck for me this time around :slight_smile:
Logs available at

first time in a long time i had so seek support :smiley: mostly cause i dont have time to plow thru the issue myself

So udisks is failing to start even after rebooting ? You might want to head over to this thread, as I suspect your issue is probably the same:

Something to do with polkit not allowing udisks to open its dbus socket, but we haven’t worked out what the cause is.

1 Like

Yepp same issue as the guy with the RPI1, turned on watching status on that thread. Ping me if there is any test you want me to do from that thread.

Sorry but beyond what was already discussed in the other thread I have no idea what the cause may be or what you could try. Nothing related to the udisks/diskmount packages should have changed any policy kit files, and the new packages themselves are not to blame as we have upgraded several test devices including Pi 1’s to them without issues.

Just looking over your log file I see this:

Start-Date: 2017-09-27  06:45:11
Commandline: /usr/bin/unattended-upgrade
Upgrade: git-man:armhf (2.1.4-2.1+deb8u4, 2.1.4-2.1+deb8u5)
End-Date: 2017-09-27  06:45:14

Start-Date: 2017-09-27  06:45:31
Commandline: /usr/bin/unattended-upgrade
Upgrade: git:armhf (2.1.4-2.1+deb8u4, 2.1.4-2.1+deb8u5)
End-Date: 2017-09-27  06:45:35

Start-Date: 2017-10-02  06:34:54
Commandline: /usr/bin/unattended-upgrade
Upgrade: udisks-glue:armhf (1.3.5-1, 9.99-11)
End-Date: 2017-10-02  06:34:57

Start-Date: 2017-10-02  06:35:14
Commandline: /usr/bin/unattended-upgrade
Upgrade: armv7-network-osmc:armhf (1.6.6, 1.6.7)
End-Date: 2017-10-02  06:35:20

Start-Date: 2017-10-02  06:35:37
Commandline: /usr/bin/unattended-upgrade
Upgrade: rbp-bootloader-osmc:armhf (2.3.0-1, 2.4.0-1)
End-Date: 2017-10-02  06:35:40

Start-Date: 2017-10-02  06:35:58
Commandline: /usr/bin/unattended-upgrade
Upgrade: udisks:armhf (1.0.5-1+b1, 9.99-11)
End-Date: 2017-10-02  06:36:00

Start-Date: 2017-10-02  06:36:18
Commandline: /usr/bin/unattended-upgrade
Upgrade: rbp-userland-osmc:armhf (2.4.0-1, 2.5.0-1)
End-Date: 2017-10-02  06:36:20

Start-Date: 2017-10-02  06:36:38
Commandline: /usr/bin/unattended-upgrade
Upgrade: smb-app-osmc:armhf (1.2.0, 1.2.1)
End-Date: 2017-10-02  06:36:52

This seems to be some sort of unattended upgrade system ? Is this the official supported debian one or some roll your own system ?

It appears to be upgrading packages one at a time individually, and it has upgraded udisks-glue to a transition package which would never have happened with a dist-upgrade:

Start-Date: 2017-10-02  06:34:54
Commandline: /usr/bin/unattended-upgrade
Upgrade: udisks-glue:armhf (1.3.5-1, 9.99-11)
End-Date: 2017-10-02  06:34:57

I think this is the root cause of your problem - your unattended upgrade script is basically doing an apt-get upgrade on packages not an apt-get dist-upgrade. Not sure what the solution is though.

Unattended Upgrades takes the smallest number of packages that can be updated in one transaction and does this repeatedly.

So if you don’t have versioned depends on every package or you expect some package to be a particular version; you run in to problems. It’s not much different to holding back packages and updating them one at a time.

We always tell people to use dist-upgrade, not apt-get upgrade.

Do you have /var/lib/polkit-1/localauthority/90-mandatory.d/osmc-diskmount.pkla?

osmc@Livingroom:~$ sudo cat /var/lib/polkit-1/localauthority/90-mandatory.d/osmc-diskmount.pkla
[Disk mounting]

all there

Not sure then unfortunately.
But this is why I don’t recommend the use of the unattended upgrades. As we both know, apt-get upgrade is never a good idea.

Still just blaming unattended upgrades is not a solution since more then just me had this problem :wink: guessing its up to myself to solve the mystery incase you dont want to help me

We have never recommended running apt-get upgrade.

Several of your own posts even warn users against this.

Unattended upgrades does this. I have on numerous occasions warned against using this utility.

I don’t know what the issue is, sorry, but OSMC users updating via the official method are not affected. There’s not much incentive to investigate an issue for something we don’t support and don’t plan to support in the future