[mythtv-users] upgrading from mythbuntu 14.04/0.27 to 0.28 vs. mythbuntu 16.04 install

[Stephen Worthington]

On Sat, 26 Nov 2016 22:19:39 +0000, you wrote:

>I have about 500GB of recorded TV on my mythbuntu 14.04 backend on version 0.27 of mythtv. I’m ready to upgrade to 0.28.
>
>I’m trying to pick the best way.
>
>I know I can use MCC and change the repository from 0.27 to 0.28 and do an upgrade in place (making sure I have a current backup of the database).  I could then do a "do release upgrade" and bring the OS to 16.04.
>
>Is that better than doing a fresh install of mythbuntu 16.04.1??  I’m worrying about restoring the 0.27 database backup to 0.28 after I install 16.04 from scratch?  I have my recording on 2 separate disk that will not be erased by a fresh install.
>
>Thoughts on how to do this right?
>
>Jim A

The 0.27 to 0.28 change is relatively painless.  I recommend doing
that first, then running like that for a while before contemplating
the 14.04 to 16.04 upgrade, which is a lot more complicated.  All you
really need to worry about with 0.27 to 0.28 is to make sure you have
a good backup before you start, so you can change back again if
necessary. And, of course, leaving yourself enough time to change back
again before your next recording time, if there are serious problems.
By a good backup, I mean both a database backup (copied to a different
partition), and a full backup of the boot/system partition(s).  I use
a clonezilla live image boot to make image backups of my boot
partition.  It is faster, simpler and safer to just restore an image
backup of your system if the upgrade fails than to mess around with
uninstalling 0.28 and reinstalling 0.27.

To do the 14.04 to 16.04.1 upgrade, I would recommend that you have
two bootable partitions so you can keep your old 14.04 running on one
partition while experimenting with 16.04.1 on the other partition.
There are plenty of problems you can run into, mostly related to the
change to using systemd.  If your setup is quite simple (no external
access to MythTV from other boxes, no network tuners), then the
upgrade could be straightforward.  But if you run other frontends or
have network tuners, then you will have problems and will need extra
time to play around with things until they are really right.  If you
do not have an spare boot partition to do this with, and have not
fitted an SSD boot drive, then now is a good time to do that - SSD
prices are very reasonable now.  That would allow you to have the old
system running from your old boot drive and test things on the new SSD
install.

To do the upgrade, the choice of upgrading in place or a new install
really depends on the history and complexity of your setup.  I chose
in the end to upgrade in place, but I did it by copying my 14.04 setup
to my new SSD using gparted, and upgrading the copy.  I have two boot
partitions on my SSD so I was able to run 14.04 from there initially,
while I tried out 16.04 on the other partition, and waited for 16.04.1
to be released.  When 16.04.1 came along, I did the upgrade of the
14.04 SSD partition.

While testing with the new 16.04 boot partition, I discovered just how
much customisation I had on my system, which lead me to choose to do
the upgrade-in-place option.  In the past, upgrading in place has
failed sometimes, leaving me with no alternative but to start again
with a new install, but this time it worked reasonably well, barring
all the complications introduced by the systemd change.

To clone using gparted, I recommend doing it using a CD or USB boot of
the 16.04.1 live image.  If I remember correctly, gparted is not
installed on the image, so your network needs to be set up so that it
will give a DHCP address to the live image boot to allow the "apt
install gparted" command to work from the live boot.  Or you can use a
boot image such as the clonezilla one that has gparted pre-installed.
To support SSDs properly, it is best to use a recent version, based on
16.04, if possible, which will have the latest gparted.  Older
versions may not recognise some SSDs, especially NVMe ones.

Warning: If you clone a boot partition, you *must* change the new
partition's UUID, or grub will boot from both partitions at once,
getting some things from the new partition and some from the old.
Gparted has the ability to change the UUID when you do the cloning.
And you can meet up with a grub bug where it will put the old UUID in
the /boot/grub/grub.cfg file in the config for the new partition.  So
when you run update-grub after cloning the partition (or it gets run
automatically), you need to manually check the new grub.cfg file
entries for the new partition and edit them if necessary.  Change any
UUID values in the new partition's section that reference the old
partition so that they are all the same and the correct value for the
new partition.  I think you only have to do this once and the bug does
not occur again after that - it seems that grub copies things from old
grub installs it finds and that is how this bug happens.  So once it
has a grub.cfg in place for itself on the new install, it does not
copy from older configs and the bug does not happen again.

Some more information about your current system setup would help in
advising how to proceed and what the possible problems may be.  In
particular, what tuners are you using?  Do you have a way of using a
different boot partition?  Are you using external frontends, or just
one combined backend/frontend box with no external access?  Do you use
SQL commands from the command line?  Is the MythTV box also serving
other functions (eg nameserver, mail server, web server)?  Do you have
any familiarity with systemd, or will you be learning about it from
scratch?