[mythtv-users] About updating from Ubuntu 24.04 to 26.04

[Stephen Worthington]

On Tue, 5 May 2026 08:34:20 -0400, you wrote:

>I perhaps should have mentioned it in my original post, but what I've 
>outlined in this list is what I had to do for *my* system for the 
>upgrade to work.  Since it is 23 years old, and didn't even start its 
>life on the Ubuntu platform at all, surely there are oddities about my 
>system that the masses wouldn't experience.  I shared my notes because I 
>expect that I'm not the only person on the planet in such a situation.
>
>But anyway...
>
>
>On 5/4/26 8:58 PM, Will Dormann wrote:
>> 4. I noticed that postfix failed to start after upgrade, as it seems to 
>> attempt to start before the network is up.  To fix:
>> sudo systemctl edit postfix.service
>> Add:
>> 
>> [Unit]
>> After=network-online.target
>> Wants=network-online.target
>
>Perhaps related to this timing of my postfix service, I also noticed 
>that the number of hdhomerun recording devices detected by MythTV was 
>inconsistent on each boot.  Sometimes it was zero.  Sometimes it was only 2.
>
>Guessing that it was some sort of race condition on boot, I addressed it by:
>
>sudo systemctl edit mythtv-backend
>
>Add near the top:
>
>[Service]
>ExecStartPre=sleep 10
>
>
>
>There may be a better / deterministic way to address the problem.  But 
>the above worked, and that's good enough for me.

Your fix for postfix looks ok, as I understand that postfix will
automatically see any new network interfaces that appears after it
starts and will reconfigure itself to then use them.  So it only needs
to be started after network-online.target, which is when the network
stack is up and the first network interface is up (normally
localhost).  But in my Ubuntu 24.04, postfix.service does not actually
start postfix, that is done in an instance of postfix at -.service, which
does already have Wants/After=network-online.target.  Run this:

systemctl cat postfix at -.service

to see what yours looks like.

For MythTV, mythbackend does not have the code that postfix does that
makes it see new network interfaces.  It must have all the network
interfaces it uses up and actually working before it gets started.
Your fix is the classic bad fix for this sort of race condition.  It
works until it doesn't.  When something happens during boot that
extends the time taken by part of the boot process, the 10 seconds
delay can be exceeded.  One of the most usual things that will cause
that is to have an automatic fsck process happen during boot.

The correct fix for mythbackend is to wait until the network is
actually up.  What I do is to ping my Ethernet switch and only start
network services after I get a ping reply.  Any device that is
pingable will do, but as you are using HDHomerun devices, pinging one
of them is a good choice.  Also, with HDHomeruns you can detect them
using an hdhomerun_config command and check the results of that.  That
works well as an ExecStartPre command - just wait until they are
detected by the correct hdhomerun_config command which will then
return and allow mythbackend to be started.  There are examples of
these and other ways of doing it in this mailing list's archives.