[mythtv-users] Upgrade order for MythTV vs Ubuntu

[Stephen Worthington]

On Mon, 13 Jul 2020 21:47:24 -0700, you wrote:

>On Mon, Jul 13, 2020, 4:31 PM jam at tigger.ws <jam at tigger.ws> wrote:
>
>> [snip]
>>
>> > I always do a clean install to a separate partition rather than doing an
>> "in-place" upgrade. Before doing this, I first make full backups (I use
>> tar, personally) of non-recording partitions. If you haven't done this
>> before, you'll probably need to do some re-partitioning to make room for a
>> clean install, which is another reason to make good backups first. The
>> reason to have a new, separate partition is so you can go back and forth to
>> and from your current working environment and the new environment.
>> Especially with the change from SD-DD (schedules direct-direct data) to
>> SD-JSON (schedules direct-json). It took me more than an afternoon to get
>> that sorted out to my liking, so it was important to reboot back to the
>> known working environment. I also do this back & forth to upgrade my remote
>> front ends, too.
>>
>> Sorry to wander OT for myth.
>> I have 2 10 or 20 G partitions for root.
>> I alternate each time I install leaving the other to be used if everything
>> fails this install. Also no matter how careful I an I always forget
>> *something* sometimes noticing a week or two later.
>> Many Distros use 1000 as the uid for the first user so leaving home not
>> formated keeps familiar stuff.
>>
>> James
>>
>I currently have the system/myth on one small physical drive/partition, and
>video0 mapped to a separate physical drive/partition. Both are  mechanical
>HDDs.  I hope to back up mythconverg,  clone video0 to a same-size SSD, do
>a clean install of 18.04/myth 31 on a small ssd, and restore the DB. Then
>everything will work great. I'm dreaming, aren't I?

It is not a dream, but there are some problems along the way.  I have
done this again recently on my mother's MythTV box, and there is still
a nasty grub bug you may encounter.

First problem: You can not clone a mounted partition, so you can not
clone your boot partition without being booted from somewhere else.  I
normally have two bootable partitions on any hard drive or SSD I boot
from, so that I can boot the other partition when I need to do work on
the normal boot partition.  This is also very useful when I have a
power failure or crash where the system was not shut down properly.  I
can boot to the other boot partition and use it to run "fsck -C -f" on
all the partitions that were mounted at the time.  I normally have
lots of partitions, so I have a script to do that, with each drive
checked in parallel.  If you do not have another boot partition with
the same level of file system drivers as the normal boot, you will
need to boot from a USB stick or DVD to do the cloning.  You can just
use a live install image for Ubuntu.  If it does not have gparted
installed already in the image, make an Internet connection and just
do:

sudo apt install gparted

to get it.  I think gparted is now in the live images as of about
18.04, so you may not need to do that.  As long as your router is
providing DHCP addresses, an Ubuntu live image should just connect to
the Internet without having to set anything up.  But you can open a
terminal and manually set up your Ethernet (or WiFi) if necessary.

When you clone a partition using gparted, and I presume also with
other tools, the new partition still has the same UUID as the old one.
So unless you are going to remove the drive that has the old partition
on it completely after you do the cloning, you need to use gparted's
option to change the UUID of the newly cloned partition.  You can also
do it using "tune2fs -U".  It is very bad to have more than one
partition with the same UUID on a system.  It can get very confused
and try to use both copies.  If you have labels on the partitions
(both the "partition name" and "file system label" - they are two
different things) you will also need to change them in gparted.  When
I do this, I change the UUID on the new partition, and put -old on the
end of the names on the old partition.  That is because in fstab, I
mount partitions using the LABEL= option, rather than UUID=.  So by
leaving the names on the new partition unchanged, I then do not need
to change fstab.  If you do need to change fstab, your live boot image
should have several editors such as nano that you can use, or you can
use apt install to get your favourite.  The changes need to be done
before you can boot the new system.

The next problem is installing grub properly on the new boot SSD. This
web page has the proper method:

https://howtoubuntu.org/how-to-repair-restore-reinstall-grub-2-with-a-ubuntu-live-cd

If you do not want the old hard drives to be on the new system,
unmount them (if necessary) and shut them down (hdparm -Y /dev/xxxxx)
and unplug them before doing the grub install.  You can hot unplug as
long as you have properly unmounted the drives, or you can shut down,
unplug them and reboot your live image.

When you run grub-install/update-grub to set up grub on the new SSD
drive you can get a nasty bug happen where grub builds its
/boot/grub/grub.cfg file incorrectly.  Here is the menu entry in
grub.cfg for booting my MythTV box currently:

menuentry 'Ubuntu' --class ubuntu --class gnu-linux --class gnu
--class os $menuentry_id_option
'gnulinux-simple-96179365-c3a1-448f-bd51-89ce2074dc54' {
        recordfail
        savedefault
        load_video
        gfxmode $linux_gfx_mode
        insmod gzio
        if [ x$grub_platform = xxen ]; then insmod xzio; insmod
lzopio; fi
        insmod part_gpt
        insmod ext2
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root
96179365-c3a1-448f-bd51-89ce2074dc54
        else
          search --no-floppy --fs-uuid --set=root
96179365-c3a1-448f-bd51-89ce2074dc54
        fi
        linux   /boot/vmlinuz-5.3.0-62-generic
root=UUID=96179365-c3a1-448f-bd51-89ce2074dc54 ro iommu=soft quiet
splash $vt_handoff
        initrd  /boot/initrd.img-5.3.0-62-generic
}

(my email program has wrapped the long lines)

There are four places there where the UUID of the boot partition
(96179365-c3a1-448f-bd51-89ce2074dc54) is used.  Grub puts the correct
UUID for the new boot partition in the first three of those, but in
the "linux" line, if the bug happens, it puts the UUID of the old boot
partition.  This causes the old boot partition to be booted, but I am
not sure if the new partition gets used along the way or not.  In any
case, it is not what you want.  So after you have done
grub-install/update-grub, before you try rebooting from the new SSD
boot partition, take a look at all the boot menu entries in grub.cfg
on the SSD boot partition.  The way I do this on a live image boot is
to start a terminal then:

sudo su
cd /mnt
mkdir temp
mount /dev/<ssd boot partition> temp
cd /mnt/temp/boot/grub
chmod u+w grub.cfg
nano grub.cfg

If you find that the bug has hit, then you will need to copy the
correct UUID from one of the three prior entries into the "linux" line
replacing the bad UUID.  Check all the menus in grub.cfg.

When you exit from your editor:

chmod u-w grub.cfg
cd /mnt
umount temp
exit

I would suggest taking a look at your existing grub.cfg file on your
hard drive before you start the cloning process, so you are familiar
with what it should look like and where things are:

less /boot/grub/grub.cfg

Now reboot, and when the BIOS appears, enter the BIOS config and
change the boot drive to be the new SSD.  Everything should now boot
correctly from the new SSD.  Once it boots, do any adjustments you
need to fstab so that the old drives' partitions can be mounted.

You only have to fix grub.cfg once - any later grub-install or
update-grub will work correctly.  My theory about this bug is that
update-grub is reading the existing grub.cfg and getting the wrong
UUID from there, so after all the UUIDs in grub.cfg are correct, the
bug does not happen again.