[mythtv-users] Upgrade order for MythTV vs Ubuntu

DryHeat122 dryheat122 at gmail.com
Wed Jul 15 03:28:17 UTC 2020


On Tue, Jul 14, 2020 at 1:52 AM Stephen Worthington <
stephen_agent at jsw.gen.nz> wrote:

> 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.
>
> Wow thanks for the detailed advice!  I will hang onto it for reference but
I think maybe I was unclear in my earlier message.  Right now I have two
physical drives, one 256gb for the OS and user software, and a 1 TB mapped
to /dev/video0 for storing recordings.  I only plan to clone the 1 TB.
Planning to use clonezilla to do it to avoid the problems you mentioned
with mounted disks, etc.  Then I will do a fresh install of Ubuntu and Myth
on a new 256gb SSD and restore mythconverg.  It will never work!!! :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20200714/535bba03/attachment.htm>


More information about the mythtv-users mailing list