[mythtvnz] Upgrade from 34 to 35 in Ubuntu 20.04

[OpenMedia]

I started prototyping on Ubuntu around 7.04 and Used in-place upgraded
until I switched from 32bit to 64bit builds. That has been the only recent
clean install of the backend, but I performed a full DB recovery and I
still have all my old recordings.

I also tend to minimise my updates as rebuilding the DVB-S card drivers is
frustrating.

> Thanks for the extensive information Stephen.
>
> Yes I did some research regarding PPA just now and see they are now
> automatically disabled . This was something I did not know.
>
> Your suggestion of reinstalling the PPAs is important information.
>
> My cloned backup drive is only connected to perform the backup , and
> after it is verified as being functional , it is disconnected. So
> problems with two identical system drives never occur.
>
> I was aware of the possible direct upgrade paths . I may go to 22.04 and
> test and then to 24.04.
>
> - Paul
>
>
>
> On 2025-04-23 21:04, Stephen Worthington wrote:
>> 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
>>
>> _______________________________________________
>> mythtvnz mailing list
>> mythtvnz at lists.ourshack.com
>> https://lists.ourshack.com/mailman/listinfo/mythtvnz
>> Archiveshttp://www.gossamer-threads.com/lists/mythtv/mythtvnz/_______________________________________________
> mythtvnz mailing list
> mythtvnz at lists.ourshack.com
> https://lists.ourshack.com/mailman/listinfo/mythtvnz
> Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
>