<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 14, 2020 at 1:52 AM Stephen Worthington <<a href="mailto:stephen_agent@jsw.gen.nz">stephen_agent@jsw.gen.nz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, 13 Jul 2020 21:47:24 -0700, you wrote:<br>
<br>
>On Mon, Jul 13, 2020, 4:31 PM <a href="mailto:jam@tigger.ws" target="_blank">jam@tigger.ws</a> <<a href="mailto:jam@tigger.ws" target="_blank">jam@tigger.ws</a>> wrote:<br>
><br>
>> [snip]<br>
>><br>
>> > I always do a clean install to a separate partition rather than doing an<br>
>> "in-place" upgrade. Before doing this, I first make full backups (I use<br>
>> tar, personally) of non-recording partitions. If you haven't done this<br>
>> before, you'll probably need to do some re-partitioning to make room for a<br>
>> clean install, which is another reason to make good backups first. The<br>
>> reason to have a new, separate partition is so you can go back and forth to<br>
>> and from your current working environment and the new environment.<br>
>> Especially with the change from SD-DD (schedules direct-direct data) to<br>
>> SD-JSON (schedules direct-json). It took me more than an afternoon to get<br>
>> that sorted out to my liking, so it was important to reboot back to the<br>
>> known working environment. I also do this back & forth to upgrade my remote<br>
>> front ends, too.<br>
>><br>
>> Sorry to wander OT for myth.<br>
>> I have 2 10 or 20 G partitions for root.<br>
>> I alternate each time I install leaving the other to be used if everything<br>
>> fails this install. Also no matter how careful I an I always forget<br>
>> *something* sometimes noticing a week or two later.<br>
>> Many Distros use 1000 as the uid for the first user so leaving home not<br>
>> formated keeps familiar stuff.<br>
>><br>
>> James<br>
>><br>
>I currently have the system/myth on one small physical drive/partition, and<br>
>video0 mapped to a separate physical drive/partition. Both are mechanical<br>
>HDDs. I hope to back up mythconverg, clone video0 to a same-size SSD, do<br>
>a clean install of 18.04/myth 31 on a small ssd, and restore the DB. Then<br>
>everything will work great. I'm dreaming, aren't I?<br>
<br>
It is not a dream, but there are some problems along the way. I have<br>
done this again recently on my mother's MythTV box, and there is still<br>
a nasty grub bug you may encounter.<br>
<br>
First problem: You can not clone a mounted partition, so you can not<br>
clone your boot partition without being booted from somewhere else. I<br>
normally have two bootable partitions on any hard drive or SSD I boot<br>
from, so that I can boot the other partition when I need to do work on<br>
the normal boot partition. This is also very useful when I have a<br>
power failure or crash where the system was not shut down properly. I<br>
can boot to the other boot partition and use it to run "fsck -C -f" on<br>
all the partitions that were mounted at the time. I normally have<br>
lots of partitions, so I have a script to do that, with each drive<br>
checked in parallel. If you do not have another boot partition with<br>
the same level of file system drivers as the normal boot, you will<br>
need to boot from a USB stick or DVD to do the cloning. You can just<br>
use a live install image for Ubuntu. If it does not have gparted<br>
installed already in the image, make an Internet connection and just<br>
do:<br>
<br>
sudo apt install gparted<br>
<br>
to get it. I think gparted is now in the live images as of about<br>
18.04, so you may not need to do that. As long as your router is<br>
providing DHCP addresses, an Ubuntu live image should just connect to<br>
the Internet without having to set anything up. But you can open a<br>
terminal and manually set up your Ethernet (or WiFi) if necessary.<br>
<br>
When you clone a partition using gparted, and I presume also with<br>
other tools, the new partition still has the same UUID as the old one.<br>
So unless you are going to remove the drive that has the old partition<br>
on it completely after you do the cloning, you need to use gparted's<br>
option to change the UUID of the newly cloned partition. You can also<br>
do it using "tune2fs -U". It is very bad to have more than one<br>
partition with the same UUID on a system. It can get very confused<br>
and try to use both copies. If you have labels on the partitions<br>
(both the "partition name" and "file system label" - they are two<br>
different things) you will also need to change them in gparted. When<br>
I do this, I change the UUID on the new partition, and put -old on the<br>
end of the names on the old partition. That is because in fstab, I<br>
mount partitions using the LABEL= option, rather than UUID=. So by<br>
leaving the names on the new partition unchanged, I then do not need<br>
to change fstab. If you do need to change fstab, your live boot image<br>
should have several editors such as nano that you can use, or you can<br>
use apt install to get your favourite. The changes need to be done<br>
before you can boot the new system.<br>
<br>
The next problem is installing grub properly on the new boot SSD. This<br>
web page has the proper method:<br>
<br>
<a href="https://howtoubuntu.org/how-to-repair-restore-reinstall-grub-2-with-a-ubuntu-live-cd" rel="noreferrer" target="_blank">https://howtoubuntu.org/how-to-repair-restore-reinstall-grub-2-with-a-ubuntu-live-cd</a><br>
<br>
If you do not want the old hard drives to be on the new system,<br>
unmount them (if necessary) and shut them down (hdparm -Y /dev/xxxxx)<br>
and unplug them before doing the grub install. You can hot unplug as<br>
long as you have properly unmounted the drives, or you can shut down,<br>
unplug them and reboot your live image.<br>
<br>
When you run grub-install/update-grub to set up grub on the new SSD<br>
drive you can get a nasty bug happen where grub builds its<br>
/boot/grub/grub.cfg file incorrectly. Here is the menu entry in<br>
grub.cfg for booting my MythTV box currently:<br>
<br>
menuentry 'Ubuntu' --class ubuntu --class gnu-linux --class gnu<br>
--class os $menuentry_id_option<br>
'gnulinux-simple-96179365-c3a1-448f-bd51-89ce2074dc54' {<br>
recordfail<br>
savedefault<br>
load_video<br>
gfxmode $linux_gfx_mode<br>
insmod gzio<br>
if [ x$grub_platform = xxen ]; then insmod xzio; insmod<br>
lzopio; fi<br>
insmod part_gpt<br>
insmod ext2<br>
if [ x$feature_platform_search_hint = xy ]; then<br>
search --no-floppy --fs-uuid --set=root<br>
96179365-c3a1-448f-bd51-89ce2074dc54<br>
else<br>
search --no-floppy --fs-uuid --set=root<br>
96179365-c3a1-448f-bd51-89ce2074dc54<br>
fi<br>
linux /boot/vmlinuz-5.3.0-62-generic<br>
root=UUID=96179365-c3a1-448f-bd51-89ce2074dc54 ro iommu=soft quiet<br>
splash $vt_handoff<br>
initrd /boot/initrd.img-5.3.0-62-generic<br>
}<br>
<br>
(my email program has wrapped the long lines)<br>
<br>
There are four places there where the UUID of the boot partition<br>
(96179365-c3a1-448f-bd51-89ce2074dc54) is used. Grub puts the correct<br>
UUID for the new boot partition in the first three of those, but in<br>
the "linux" line, if the bug happens, it puts the UUID of the old boot<br>
partition. This causes the old boot partition to be booted, but I am<br>
not sure if the new partition gets used along the way or not. In any<br>
case, it is not what you want. So after you have done<br>
grub-install/update-grub, before you try rebooting from the new SSD<br>
boot partition, take a look at all the boot menu entries in grub.cfg<br>
on the SSD boot partition. The way I do this on a live image boot is<br>
to start a terminal then:<br>
<br>
sudo su<br>
cd /mnt<br>
mkdir temp<br>
mount /dev/<ssd boot partition> temp<br>
cd /mnt/temp/boot/grub<br>
chmod u+w grub.cfg<br>
nano grub.cfg<br>
<br>
If you find that the bug has hit, then you will need to copy the<br>
correct UUID from one of the three prior entries into the "linux" line<br>
replacing the bad UUID. Check all the menus in grub.cfg.<br>
<br>
When you exit from your editor:<br>
<br>
chmod u-w grub.cfg<br>
cd /mnt<br>
umount temp<br>
exit<br>
<br>
I would suggest taking a look at your existing grub.cfg file on your<br>
hard drive before you start the cloning process, so you are familiar<br>
with what it should look like and where things are:<br>
<br>
less /boot/grub/grub.cfg<br>
<br>
Now reboot, and when the BIOS appears, enter the BIOS config and<br>
change the boot drive to be the new SSD. Everything should now boot<br>
correctly from the new SSD. Once it boots, do any adjustments you<br>
need to fstab so that the old drives' partitions can be mounted.<br>
<br>
You only have to fix grub.cfg once - any later grub-install or<br>
update-grub will work correctly. My theory about this bug is that<br>
update-grub is reading the existing grub.cfg and getting the wrong<br>
UUID from there, so after all the UUIDs in grub.cfg are correct, the<br>
bug does not happen again.<br><br></blockquote><div>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!!! :-) </div></div></div>