[mythtvnz] Upgrade from 34 to 35 in Ubuntu 20.04

[Stephen Worthington]

On Wed, 23 Apr 2025 16:46:44 +1200, you wrote:

There is no direct path to upgrade from 20.04 to 24.04.  You would
need to do the 20.04 to 22.04 upgrade and then the 22.04 to 24.04
upgrade.  Plenty of people have done that, but there are always little
glitches along the way.  My current main MythTV system has been
continuously upgraded from 10.04 to 24.04.

>So do you disable the MythTV PPA before upgrading the OS?

That is not necessary - the upgrade process automatically disables all
repositories except the standard Ubuntu ones.

>I also use the Mythbuntu Control Panel and its PPA

Your old PPAs are effectively commented out, so you used to be able to
just uncomment them and change the version.  But for the 22.04 to
24.04 upgrade, the format of the repository files has changed and it
is better to install the repositories again using the full install
procedure.  As well, the way the keys for authenticating repositories
are stored has been changed.  The old keys still worked in 22.04, but
the new method of storage is required in 24.04, and a full install
sets that up properly.

>My problems on my main Ubuntu (i.e. not the Mythbox) in the past were 
>probably due to enabled PPAs

Doubtful, as the Ubuntu upgrade process has been automatically
disabling non-Ubuntu repositories the whole time I have been using it.
But if you failed to re-enable your PPAs after the upgrade AND change
their versions, then you would have been in whole pile of trouble.

>Second question is is there any MythTV setup required after the upgrade 
>or is it ready to go?

If you are upgrading the MythTV version at the same time, the database
schema will need to be upgraded as usual.  But since you are on MythTV
v34 and that is a supported version on Ubuntu 24.04, you would not
need to do the MythTV version upgrade at the same time as the Ubuntu
upgrade and it should just run normally.

>I might give it a shot . My Mythbox has a second system SSD that I clone 
>the main SSD onto as a backup at regular intervals . So if I run into 
>problems I'll just switch to the backup.

I always do a Clonezilla backup of my system drive before any Ubuntu
version upgrade.  I have twice had to reinstall the backup due to
problems with the upgrade, so I always leave enough time before my
next recording time so that I can do that if necessary.  Fortunately
Ubuntu upgrades are much faster now that the system is running on an
NVMe SSD.

I am surprised that having a full clone on another partition in the
same system does not cause you problems.  Grub has a nasty habit of
finding the same UUIDs and so on and booting from a mixture of the
correct partition and the clone.  This bug has not been fixed although
it has been around for at least 10 years.  Probably because it would
be pretty difficult to fix.  So does your cloning software
automatically change all the IDs so the systems do not actually match?
If so, then you had better not be using the UUID to identify the boot
partition in /etc/fstab.  The default install methods use the UUID. If
you have booted from the clone and everything worked, you may not have
actually been running on the clone!

>-Paul