I wondered yesterday why I’ve never seen my vero update it self, so I went to the update tab and clicked the manual update, about 120 updates were available and it started installing them.
It got stuck how ever at “Setting up armv7-network-osmc (1.5.9) …” and after it had been stuck there for about 1.5 hour I first tried pulling the ethernet cable and when nothing happened, the power plug.
I know this is a bad thing to do while it’s installing packages, but really had no other options.
So now it wont boot and just stops as you can see on the picture.
From the logs I think I’ve found what went wrong during the update. The package manager expected user input for a connman file, but that was … well pretty difficult to know.
From the logs:
Setting up armv7-network-osmc (1.5.9) ...
Configuration file '/etc/connman.conf'
==> File on system created by you or by a script.
==> File also in package provided by package maintainer.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
The default action is to keep your current version.
*** connman.conf (Y/I/N/O/D/Z) [default=N] ?
You could always as a last resort take out the SD card and re-load the software on it using the installer from Download - OSMC . The Vero can’t be “bricked”.
Maybe someone else can help you in a more technical manner to maybe get in un-stucked however without having to reload the software.
No packages (or newer debian versions) were available, so dist-upgrade didn’t do much.
@shadow
I already did a reinstall of those packages which didn’t get installed in the first update (sudo dpkg --configure -a)
Still tried your suggested command though, but no packages were upgraded or reinstalled.
Going through the logs again, this seems a bit odd.
Setting up vero-image-4.1.7-2-osmc (2) ...
Hmm. There is a symbolic link /lib/modules/4.1.7-2-osmc/build
However, I can not read it: No such file or directory
Therefore, I am deleting /lib/modules/4.1.7-2-osmc/build
Hmm. The package shipped with a symbolic link /lib/modules/4.1.7-2-osmc/source
However, I can not read the target: No such file or directory
Therefore, I am deleting /lib/modules/4.1.7-2-osmc/source
Running depmod.
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 4.1.7-2-osmc /boot/vmlinuz-4.1.7-2-osmc
run-parts: executing /etc/kernel/postinst.d/inform-updater 4.1.7-2-osmc /boot/vmlinuz-4.1.7-2-osmc
run-parts: executing /etc/kernel/postinst.d/process-vmlinuz-vero 4.1.7-2-osmc /boot/vmlinuz-4.1.7-2-osmc
Manual update from SSH
Processing triggers for libc-bin (2.19-18+deb8u1) ...
/sbin/ldconfig.real: /opt/vero/lib/libOpenVG.so is not a symbolic link
Exactly the same problem for me. Seems that OSMC hasn’t updated for months (even though auto update was on). Doing a manual update got it stuck at the exact same point. After a few hours I SSHed in and killed the dpkg process, and now bootup fails at the same point.
After running sudo dpkg --configure -a it found I had conflicts with sshd_config as well as connman.conf (which I guess couldn’t be solved non-interactively by the installer).
Running kodi from the command line results in kodi starting but promptly crashing (although it mostly seems to be complaining about not being able to mount my NFS shares).
I’ll keep poking around a bit more. How do I trigger an OSMC manual update from the command line?
The “Hm” messages are not errors and none of the other ones in your post are, so that’s OK.
Many months ago, @DBMandrake and I reworked the updater to ensure you never receive a prompt like this. However, to get this new updater, you need to be up to date. We now mark ConnMan and SSH files as conffiles and always keep the user’s local version in future.
If you run a full update and dist-upgrade, you should find yourself on the latest version and should be able to update normally in the future
Your SD card can be removed easily at any time if you ever need to.
Reading package lists… Done
Reading package lists… Done
Building dependency tree
Reading state information… Done
Calculating upgrade… The following packages were automatically installed and are no longer required:
armv7-libafpclient-osmc libflac8 libx11-6 libx11-data libxau6 libxcb1 libxdmcp6 vero-image-3.14.14-6-osmc vero-image-3.14.37-3-osmc
Use ‘apt-get autoremove’ to remove them.
Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
I also tried sudo apt-get update && sudo apt-get install vero-mediacenter-osmc --reinstall which came recommended on another thread to reinstall OSMC, but no joy.
I’m starting to wonder if there is some issue with the SD card.
dmesg always reports [ 4.741616] FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
even after a clean reboot.
I think it may just be time to backup the kodi settings and do a resinstall.
fsck is reporting about a difference between the boot sector and its backup.
I’m given the options
Copy original to backup
Copy backup to original
Tried the second one first, but both options leaves the filesystem unchanged.
osmc@osmc:~$ sudo fsck /dev/mmcblk0p1
fsck from util-linux 2.25.2
fsck.fat 3.0.27 (2014-11-12)
0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
1) Remove dirty bit
2) No action
? 2
There are differences between boot sector and its backup.
This is mostly harmless. Differences: (offset:original/backup)
65:01/00
1) Copy original to backup
2) Copy backup to original
3) No action
? 1
Leaving filesystem unchanged.
/dev/mmcblk0p1: 16 files, 53981/489976 clusters
After another few hours of trying force reinstalling a number of packages with no joy, I bit the bullet, backed up the Kodi settings and reinstalled the SD card from scratch. Everything now working fine.
Not sure what went wrong here, perhaps the gap between updates was just too far.
Great, thanks. How did you re-flash the vero?
I tried using dd and the .img, but that method doesn’t seem to work. Atleast I got “bad superblock” while trying to mount the root partition afterwards.
