Forum - xbmc-preload service won't start on boot

Running the latest packages from the following apt sources on a Pi B:

I noticed that my system was not starting Kodi on boot, and eventually going blank. After some research, I discovered that the xbmc-failed-start service was killing all XBMC/Kodi processes and also the splash screen if the Kodi services didn't start successfully after waiting for 200 seconds, which explained why the screen would turn black after a while.

As to why the Kodi processes wouldn't start within 200 seconds, I found that the xbmc-preload service would not run automatically. However, if I started the service manually (start xbmc-preload) while the splash screen was still running reporting "network started", Kodi would start successfully. If I tried to start the service after the xbmc-failed-start service had killed the splash process, Kodi would not start.

The xbmc-preload service has the following dependencies:

Code:

start on started xbian-run and filesystem

stop on xbmc-failed-start

At boot, while the splash screen is running, I can see that the xbian-run service has started. However, I cannot find a way to query the filesystem service, since Upstart can't detect it.

Terminal

~ # status filesystem
status: Unknown job: filesystem

Am I missing a system service or does the package or service have broken dependencies?

Your sources.list is a real adventure Dodgy

Please look into file /etc/init/mountall.conf

This service emits variable filesystem

You can check if variable has been set by

Terminal

root@kmxbilr /etc/init # sudo cat /var/log/upstart/upstart-ev.log | grep filesystem
Mon Aug 7 23:09:39 CEST 2017 21.60 0.31 virtual-filesystems 1.99 0.45 0.15 3/119 945
Mon Aug 7 23:09:39 CEST 2017 21.63 0.31 remote-filesystems 1.99 0.45 0.15 4/118 947
Mon Aug 7 23:09:49 CEST 2017 31.66 0.31 local-filesystems 2.40 0.59 0.20 19/158 1422
Mon Aug 7 23:09:50 CEST 2017 31.89 0.31 filesystem 2.40 0.59 0.20 21/158 1443

(29th Aug, 2017 06:21 AM)Nachteule Wrote: [ -> ]Please look into file /etc/init/mountall.conf

Thanks; that helped me troubleshoot and resolve the issue. Nothing to do with XBian, sorry.

The installation of libplymouth4 from the raspberrypi.org repository upgraded the plymouth package as well, which broke the mountall command. Reverting the plymouth package to the version in the raspbian.org (different than raspberrypi.org) repository fixed the Kodi boot sequence.

(29th Aug, 2017 06:21 AM)Nachteule Wrote: [ -> ]Your sources.list is a real adventure

That's not a direct output of my sources.list file, but a compilation of the URLs from sources.list and the files in the sources.list.d directory.

The raspbian.org and raspberrypi.org repositories come with the normal Raspbian installation. The XBian repository provides the XBian-specific packages. And the I2P repository provides the I2P network software, nothing else. Other than the I2P repository, shouldn't every XBian distribution have these sources?

Ok, understood

But double entries for Raspbian confusing me, and

Code:

deb mirror://apt.xbian.org/mirror.txt stable main __ARCH__

is garbage, you should delete that entry

Set to solved

(29th Aug, 2017 07:36 AM)palswim Wrote: [ -> ]
(29th Aug, 2017 06:21 AM)Nachteule Wrote: [ -> ]Please look into file /etc/init/mountall.conf
Thanks; that helped me troubleshoot and resolve the issue. Nothing to do with XBian, sorry.

Actually, I noticed that the mountall package comes from the XBian source (I would use the "term" tag, but it doesn't preserve spaces):

Code:

~ # apt-cache policy mountall

mountall:

  Installed: 2.54+xbian1

  Candidate: 2.54+xbian1

  Version table:

 *** 2.54+xbian1 0

        500 mirror://apt.xbian.org/mirror.txt/ stable/rpi-jessie armhf Packages

        100 /var/lib/dpkg/status

     2.54 0

        500 http://mirrordirector.raspbian.org/raspbian/ jessie/main armhf Packages

Does the mountall package from XBian use plymouth whereas the mountall from Raspbian does not? In that case, perhaps the XBian package needs to indicate a dependency on plymouth.

(30th Aug, 2017 04:31 PM)palswim Wrote: [ -> ]Does the mountall package from XBian use plymouth whereas the mountall from Raspbian does not? In that case, perhaps the XBian package needs to indicate a dependency on plymouth.

Sorry, don't know what's the difference between XBian version of mountall to the origin. You could look look into sources for figuring out what's the difference

Yes, XBian version has plymouth as dependency:

Terminal

dpkg-deb -I mountall_2.54+xbian1_armhf.deb | grep Depends
Pre-Depends: dpkg (>= 1.15.7.2)
Depends: makedev, udev, plymouth, coreutils (>= 7.1), libc6 (>= 2.9), libdbus-1-3 (>= 1.9.14), libnih-dbus1 (>= 1.0.0), libnih1 (>= 1.0.0), libplymouth4 (>= 0.9.2), libudev1 (>= 183)

(30th Aug, 2017 06:45 PM)Nachteule Wrote: [ -> ]Sorry, don't know what's the difference between XBian version of mountall to the origin. You could look look into sources for figuring out what's the difference

Interesting: in the changelog (mountall-2.54+xbian1/debian/changelog), it lists at the top:

Code:

mountall (2.54+xbian1) UNRELEASED; urgency=medium

  * changes to ignore plymouth, auto ignore errors, ignore /run etc

 -- Matus Kral <matuskral@me.com>  Wed, 30 Dec 2015 06:21:58 +0100

mountall (2.54) unstable; urgency=medium

  * conf/mounted-proc.conf: /proc/slabinfo may not exist, in which case we

    should avoid trying to chmod it and generating spurious errors in the

    log.  LP: #1319724.

 -- Steve Langasek <vorlon@debian.org>  Thu, 15 May 2014 07:54:40 -0700

So, it looks like XBian's mountall command wants to ignore plymouth, but doesn't ignore it enough.

(30th Aug, 2017 03:32 AM)Nachteule Wrote: [ -> ]Set to solved

I wouldn't say we've solved this issue, but the root cause lies with the dependencies of the mountall package, even before the XBian fork. If an XBian developer was trying to eliminate the dependency on plymouth, then he hasn't quite eliminated it completely.