I’ve reinstalled OSMC (2018.12-1) on my raspberry pi 3 B+ and then installed couchpotato and sickchill using this how-to.
The next step was to mount my external 2TB HDD through fstab:
/dev/mmcblk0p1 /boot vfat defaults,noatime,noauto,x-systemd.automount $
# rootfs is not mounted in fstab as we do it via initramfs. Uncomment for remou$
#/dev/mmcblk0p2 / ext4 defaults,noatime 0 0
UUID=E63054C530549DFD /mnt/clouddrive ntfs-3g defaults,permissions,nofail
After reboot, the system starts up and I’m able to log in through ssh, but Kodi crashes with the sad face and keeps trying to start up again unsuccessfully.
udisks-glue[339]: Failed to automount /dev/sda1: Error mounting: mount exited with exit code 1: helper failed with:
udisks-glue[339]: mount: only root can mount UUID=E63054C530549DFD on /mnt/clouddrive
DBus: Error org.freedesktop.DBus.Error.ServiceUnknown - The name org.freedesktop.UPower was not provided by any .service files
Can someone take a look and help me resolve this?
Please let me know if I can provide any additional information.
I would remove the fstab entry (or comment it out for now), reboot and allow the drive to be auto-mounted to /media. If it still fails, I suspect the issue is with the drive itself; does it have its own psu?
If the kodi starts, it may as I suspect an issue with fstab entry; which can be resolved once this has been confirmed.
I did as instructed and the issue remains - Kodi keeps crashing.
The drive doesn’t have it’s own psu. I’ve been using it like this for almost 2 years now.
udisks-glue[309]: Successfully automounted /dev/sda1 at /media/My Passport
udisks-glue[309]: Device file /dev/sda1 mounted at /media/My Passport
And there is a new error now:
mediacenter[288]: *** Error in `/usr/lib/kodi/kodi.bin’: double free or corruption (out): 0x03096280 ***
mediacenter[288]: * failed to open vchiq instance
If its been working fine for 2 years and now its not, I suspect it may be the sdcard; 2 years is good life span. I suggestion trying a fresh install on a new sd card.
Another consideration is a failing powersupply, these can deteriorate over time as well.
I’ve been using the same drive, power supply and rpi for roughly 2 years, but had one SD card (Samsung Evo+ 32GB) corrupted 5 months ago.
Since then, I’m using the official OSMC SD card and I would expect that it’s still early for it to be corrupted.
You also mentioned that the failing power supply could cause this issue, so I’m wondering how can I rule out one of the two possible reasons.
Is there a way to check/scan the SD card for corruption?
Funny that you mention Win 32 Disk imager since I have used it to create 2 backup images.
I created the second one 4 days ago just before I did apt-get dist-upgrade.
The upgrade did something to samba server and my Nextcloud instance reported issues about samba not being available, so I decided to restore the backup and not touch anything
That’s where the problem started.
After restoring the image, OSMC couldn’t boot giving bunch of file system errors. It tried to repair them automatically, but still couldn’t boot because of too many errors remaining. If it is relevant, I guess I can restore the image again and give you exact error messages?
I generated SHA256 hash of the image, restored it to SD card, created another image from SD card and then generated SHA256 hash. To my surprise, the hashes were different.
After that, I wasn’t sure if backup images were properly created or is this some issue with Win 10 adding something to the SD Card after restoring the image thus causing different hash.
I’ve tried with the other backup image with same results.
As the last resort, I’ve created USB bootable Ubuntu and restored the latest image using DD and that didn’t work also.
I gave up and started fresh OSMC intallation only to encounter this Kodi crashing issue.
It won’t be a big issue to format the SD card in order to test it with h2testw.
One way to see if the power supply is failing you is to under-clock your pi to 1ghz and see if the problem goes away. If it does then it is time for a new PSU. The 3 B+ is much more demanding (/sensitive?) than earlier models. You may have to combine the under-clock with a fresh install as power related crashes can corrupt the information on the SD card.
The way to debug a problem like this is to start with an unmodified fresh installation. So no couchpotato or sickchill and no packages like ufw. Then, one step at a time you make one – and only one – change and see if it still works.
It’s a slow, laborious approach but introducing multiple variables into the system all at once is always going to be very difficult to debug. Even though there might be a combination of factors causing the problem, with the single-step method you’ll at least get a better insight as to what’s happening.
You have the basic idea, but rebooting 3 times between changes is wrong. After the fresh install, run at least a day. And then after each new change wait another day. 3 reboots doesn’t really prove anything for stability.
I guess I can leave it running for a day after the fresh install since there is not much I can do with it.
All my media is on the USB HDD.
P.S.
I just did another fresh install, went through the initial setup and restarted the pi.
This time Kodi didn’t crash, but the skin is the default one even though I set it up to Kodi’s default skin (Estuary).
