[mythtv-users] raspbian buster booting with networked tuners and mythtv-backend
mike.bibbings at gmail.com
Sun Oct 27 12:34:33 UTC 2019
On 27/10/2019 01:42, James Abernathy wrote:
> I’ve had to fix the race conditions with Ubuntu 18.04 and network
> tuners use with mythtv-backend v30. Changing the systemd services
> configuration resolved that. I have not thought about that for some time.
> However, I now have what appears to be similar issues with Raspbian
> Buster on a Raspberry Pi 4 with mythtv-Light and mythtv-backend. There
> are lot’s of Raspbian race conditions related to networking at boot.
> If I build a straight forward FE/BE combo using mythtv-light and
> adding backend, mariadb, etc. I occasionally have no HDHR tuners after
> a boot. I can fix this by systemctl stop/start mythtv-backend. I can
> also fix this with a raspi-config and set the boot/wait on the
> networking option. That’s the same option you need to set so your can
> do NFS mounts in the fstab at boot.
> So at first I thought changing raspi-config was the solution, but I
> kept loosing the lxpanel after a boot. Couldn’t fix it unless I
> turned off the boot/wait on networking.
> Now I’m looking at fixing this like we did on Ubuntu 18.04.
> Has anyone had similar issues on Raspbian
> Jim Abernathy
> jfabernathy at gmail.com <mailto:jfabernathy at gmail.com>
Out of interest what does running "systemd-analyze critical-chain" show ?
On my Pi4 I get:
pi at pi4-20191006:~ $ systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@"
The time the unit takes to start is printed after the "+" character.
└─mariadb.service @17.491s +1.281s
└─dhcpcd.service @5.230s +12.249s
└─systemd-timesyncd.service @4.504s +483ms
└─systemd-tmpfiles-setup.service @4.363s +120ms
└─boot.mount @4.298s +54ms
└─systemd-fsck at dev-disk-by\x2dpartuuid-83c29599\x2d01.service @3.890s +399ms
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mythtv-users