Update problem and errors


Earlier today I looked at the display for my Vero and found that there was an update available.
When I attempted to get to the My OSMC module the screen went totally black, and I couldn’t progress.
I found I could SSH in, so rebooted it, and got an odd display, and no way of progressing.
I could shutdown via SSH, so did so and re-powered, and got a normal display.
After trying to update via MyOSMC I got an error message at the end of the attempt, so SSH’d in to try to progress and got:

Last login: Tue Jan 23 12:25:13 2018 from Updating APT cache. Please be patient. apt-get update was unsuccessful. If you are planning to install a package, please run apt-get update first and verify it was successful osmc@osmc_VEROH:~$ sudo apt-get update Ign http://ftp.debian.org jessie InRelease Hit http://ftp.debian.org jessie-updates InRelease Hit http://security.debian.org jessie/updates InRelease Hit http://apt.osmc.tv jessie InRelease Hit http://ftp.debian.org jessie Release.gpg Hit http://ftp.debian.org jessie Release Get:1 http://ftp.debian.org jessie-updates/main armhf Packages/DiffIndex [9868 B] Hit http://ftp.debian.org jessie-updates/contrib armhf Packages Get:2 http://ftp.debian.org jessie-updates/non-free armhf Packages/DiffIndex [736 B] Hit http://ftp.debian.org jessie-updates/contrib Translation-en Get:3 http://ftp.debian.org jessie-updates/main Translation-en/DiffIndex [3688 B] Get:4 http://ftp.debian.org jessie-updates/non-free Translation-en/DiffIndex [736 B] Hit http://security.debian.org jessie/updates/main armhf Packages Hit http://security.debian.org jessie/updates/contrib armhf Packages Hit http://security.debian.org jessie/updates/non-free armhf Packages Hit http://security.debian.org jessie/updates/contrib Translation-en Get:5 http://apt.osmc.tv jessie/main armhf Packages/DiffIndex [2023 B] Hit http://security.debian.org jessie/updates/main Translation-en Hit http://security.debian.org jessie/updates/non-free Translation-en Hit http://ftp.debian.org jessie/main armhf Packages Ign http://apt.osmc.tv jessie/main Translation-en Hit http://ftp.debian.org jessie/contrib armhf Packages Hit http://ftp.debian.org jessie/non-free armhf Packages Hit http://ftp.debian.org jessie/contrib Translation-en Hit http://ftp.debian.org jessie/main Translation-en Hit http://ftp.debian.org jessie/non-free Translation-en Fetched 17.1 kB in 11s (1514 B/s) E: dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' to correct the problem.

I then attempted the dpkg :

[code] osmc@osmc_VEROH:~$ sudo dpkg --configure -a
Setting up libwbclient0:armhf (2:4.2.14+dfsg-0+deb8u9) …
Setting up libssl1.0.0:armhf (1.0.1t-1+deb8u7) …
Setting up libkrb5support0:armhf (1.12.1+dfsg-19+deb8u4) …
dpkg: dependency problems prevent configuration of samba-dsdb-modules:
samba-dsdb-modules depends on samba-libs (= 2:4.2.14+dfsg-0+deb8u9); however:
Version of samba-libs:armhf on system is 2:4.2.14+dfsg-0+deb8u8.

dpkg: error processing package samba-dsdb-modules (–configure):
dependency problems - leaving unconfigured
Setting up libicu52:armhf (52.1-8+deb8u6) …
Setting up libk5crypto3:armhf (1.12.1+dfsg-19+deb8u4) …
Setting up libkrb5-3:armhf (1.12.1+dfsg-19+deb8u4) …
Setting up libgssapi-krb5-2:armhf (1.12.1+dfsg-19+deb8u4) …
Setting up libcups2:armhf (1.7.5-11+deb8u2) …
Setting up libcurl3:armhf (7.38.0-4+deb8u8) …
Setting up curl (7.38.0-4+deb8u8) …
Processing triggers for libc-bin (2.19-18+deb8u10) …
/sbin/ldconfig.real: /opt/vero/lib/libOpenVG.so is not a symbolic link

Errors were encountered while processing:
Now I still have a normal display of OSMC, but am not sure what I should try




Well main question is still what went wrong and in which state your system is. But you could first try to purge all samba packages and the do a dist-upgrade.

  1. dpkg -l | grep samba to find all samba packages
  2. sudo apt-get purge <NAME OF THE PACKAGE>
  3. sudo apt-get update
  4. sudo apt-get dist-upgrade

Be aware this removes all samba configurations that you might have done.



This can often be fixed with sudo apt-get install -f. You can then re-try the sudo dpkg --configure -a.



Thanks to both of you. I’ll try that later, and report back



I ran the commands, and achieved an error-free state.
I then tried to update via MyOsmc - after a while of downloading and updating I got to an unusable system (screen was blank, and couldn’t SSH in), so I rebooted - still no joy, it didn’t seem to be booting at all.
Then I tried an SD card with a 2015 version OSMC, which was OK, so I tried to do a complete new install from scratch on the original card:

  • using the Windows installer I got an error in writing the card
  • downloading directly the latest version available and using USBit to write the card got me a non-booting card
  • I repeated the operation (download and write) with the same result
  • I downloaded the 2017.10.1 version and wrote the card, and it booted and completed the install.
    @fzinken @dillthedog :
    I think I may have had several different errors happening, but wonder if there is something I can do to help you find oddities with the vero1 stuff - or should I just live with what I have working at the moment?


For me that sounds like a broken SD Card.
Suggest to test with H2Testw



OK, I tested the (blanked/cleared) card with H2Testw, all 8G, and it came out clear.
I again loaded the same image which had, before, failed, and this time the card booted sucessfully and was duly configured after the initial instal.
Next I attempted to update it, especially as MyOSMC reported it as being a Nov 2017 install. The update process went well as far as installing the new files and configuring them - but I ended with a black screen and the light which indicates the boot process failed on.
I tried a power-off and then - still no boot occurring.
I reverted to my working card - and had to re-insert it a couple of times before it booted properly.
I think I must have a couple of problems:

  1. the vero doesn’t always see the cards properly (these haven’t been used much, having only been used in the vero from new)
  2. there is something in the update process which renders the card unbootable (this has happened several times now)


Which means that the card image was ok but there is/was an electrical connectivity issue between Vero and the SD card.

An iffy Vero-SD connection might also be the reason why the update on a freshly-installed image once again borked the system. If the problem remains across several different SD cards, that would tend to suggest that the Vero is the source of your woes.



I didn’t want even to think that possibility.
I did get a friend to replace SD connectors on RPis with the older style connector - would this be a possible solution (I haven’t been inside the casing)?



Doesn’t sound like a hardware problem. Is there a reason you’re using the November and not December images? IIRC, there’s a UBoot issue in November that would cause booting problems; particularly across updates

If you hold the vero1-bootloader-osmc package back with APT this will also let you update from an older version




AFAICR I used the december version (was the latest in the downloads), which was then identified as Nov 2017. Since that, I cleared the SD card and installed again (from the same file on my server PC) - and now MyOSMC says I have 2017.12-1 !!
I’ll remember your tip about holding the boot package - thanks


Unbootable Vero

This isn’t necessary anymore.

GCC6.3 in Stretch broke UBoot for Vero 1 due to some packing differences.

Vero 1s hardware and bootloader is static now, so we no longer need to make the bootloader updatable via OSMC’s APT infrastructure.

Instead, we can build it once when we build the installer; and use these artifacts.




I’m not certain i know how to take that -

  1. has it already been built into the installer in suitable form?
  2. I haven’t been using the installer for Windows on the download page as I’ve been getting errors. Instead I’ve downloaded the (as it was) latest file, written to SD card on PC, and then finished the install on vero.


Yes – the target installer (i.e. the image); not the Windows installer. I’m saying that we only need to build the bootloader when the installer is built now.

As an aside, the Windows installer was recently updated to solve some Windows 10 issues.

All should be fine from here on.




Thanks for all your effort