[mythtv-users] upgrading from mythbuntu 14.04/0.27 to 0.28 vs. mythbuntu 16.04 install
Stephen Worthington
stephen_agent at jsw.gen.nz
Sun Nov 27 15:40:56 UTC 2016
On Sun, 27 Nov 2016 12:29:33 +0000, you wrote:
>
>
>On 11/26/2016 08:56 PM, Stephen Worthington wrote:
>> 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?
>Here's some of the additional info about my setup as you requested:
>1. In my production mythtv system I use a HDHomeRun Connect as the first
>2 tuners and a PCIe Hauppauge HVR-2250 for my 3rd and 4th tuner. When I
>build test mythtv systems, I just shutdown the production and let the
>test system use the HDHomeRun Connect.
>2. My production system is Core i5 system with Mybuntu 14.04(64bit)
>installed on an SSD(/dev/sdc) with EFI boot. My media drives are
>balanced between 2 Hard Drives (/dev/sda1 and /dev/sdb1. Keeping the
>UUIDs staight is a pain, if you reformat, but I will not be in this
>case. Currently mythtv 0.27.
>3. The production mythtv box is dedicated and while it's can be a
>frontend, it's mostly a backend for every other device in the house.
>4. I only use SQL to fix permissions of the mythtv user. It never seems
>to get installed correctly so there is a GRANT ALL command I have to use
>on any fresh install.
>5. Mythtv box is dedicated.
>6. I don't know what systemd is except as a new and improved init system.
>
>I think that covers the questions you asked.
>
>Basically I've always started with mythbuntu and built a list of things
>to fix during the install. I document this so I can repeat it when
>required. I'll do the same for this upgrade once I get it right. My
>current doc is at: http://mythtvinstall.blogspot.com/
>
>That might give you insight into the level I'm familiar with on mythtv
>installs.
>
>Thanks,
>
>Jim A
Ok, because you have network tuners and other frontends, that means
that the default systemd file for mythbackend is broken for you, and
you will need to apply a fix. The HVR-2250, I think, is also a tuner
that has a slow firmware upload, so you will likely need the fix to
make mythbackend wait until the tuners are up before starting. I have
a similar setup on my test MythTV box, so I will list all the fixes
that I remember doing to make 16.04 work properly for this setup.
1) Create a new set of rules for udev that produce systemd events for
the tuners. Create a new file in /etc/udev/rules.d. I have called
mine 99-mythbackend.rules. Put this in it:
#
# Create systemd device units for capture devices
#
SUBSYSTEM=="video4linux", TAG+="systemd"
SUBSYSTEM=="dvb", TAG+="systemd"
SUBSYSTEM=="firewire", TAG+="systemd"
The file should be "chown root:root" and "chmod a=r,u=rw".
2) Create a new directory /etc/systemd/system/mythtv-backend.service.d
where you put an override file for systemd to override some of the
settings from the package installed file
(/lib/systemd/system/mythtv-backend.service) that controls mythbackend
startup and shutdown.
The new mythtv-backend.service.d directory should be "chown root:root"
and "chmod a=rx,u=rwx".
3) Create a new .conf file in the new mythtv-backend.service.d
directory. I have called mine mythtv-backend-override.conf. This is
what I think you will need, presuming that the HVR-2250 creates two
devices on /dev/dvb0 and dev/dvb1:
[Unit]
Wants=dev-dvb-adapter0-frontend0.device
After=dev-dvb-adapter0-frontend0.device
Wants=dev-dvb-adapter1-frontend0.device
After=dev-dvb-adapter1-frontend0.device
After=NetworkManager-wait-online.service
The final After line tells systemd to wait until NetworkManager has
the network fully up and running, instead of just the localhost
interface being up. That allows mythbackend to find the external IP
address it is configured for, otherwise it will immediately shut down
again. It also means that mythbackend will be able to talk to the
HDHR tuners, which it does immediately after startup. If it can not
talk to them then, it will mark them as failed and not try to use them
after that.
The .conf file should be "chown root:root" and "chmod a=r,u=rw".
4) Check if the NetworkManager-wait-online.service is enabled:
systemctl status NetworkManager-wait-online.service
Here is what I get from that command:
root at lith:~# systemctl status NetworkManager-wait-online.service
? NetworkManager-wait-online.service - Network Manager Wait Online
Loaded: loaded
(/lib/systemd/system/NetworkManager-wait-online.service; enabled;
vendor preset: enabled)
Active: active (exited) since Sun 2016-11-27 17:34:27 NZDT; 10h ago
Docs: man:nm-online(1)
Process: 926 ExecStart=/usr/bin/nm-online -s -q --timeout=30
(code=exited, status=0/SUCCESS)
Main PID: 926 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/NetworkManager-wait-online.service
Nov 27 17:34:11 lith systemd[1]: Starting Network Manager Wait
Online...
Nov 27 17:34:27 lith systemd[1]: Started Network Manager Wait Online.
See the "enabled" on the third line. If that is not present, then you
need to enable the service:
systemctl enable NetworkManager-wait-online.service
I believe it is not enabled by default in new 16.04 installs.
5) Optional. In 16.04, the naming of the Ethernet adapters has
changed to a new scheme. You can just live with that new scheme, and
use the NetworkManager GUI to put your IP address settings and so on
on the adapter. But if you have the settings in the
/etc/network/interfaces file, the old 14.04 settings will fail as they
will have the wrong adapter name. I hate the new names, as I am used
to using eth0, so I always put in config to change the names of my
Ethernet adapters to what I want them to be. Here is what I have for
my test PC, which has three Ethernet ports at the moment:
# Asus P5K-E motherboard
SUBSYSTEM=="net", ACTION=="add",
ATTR{address}=="00:1f:c6:24:64:ce",KERNEL=="enp2s0", NAME="eth0"
SUBSYSTEM=="net", ACTION=="add",
ATTR{address}=="00:07:e9:11:c5:95",KERNEL=="enp6s2", NAME="eth1"
SUBSYSTEM=="net", ACTION=="add",
ATTR{address}=="00:1b:21:25:13:96",KERNEL=="enp4s0", NAME="eth2"
Note that is three lines - each line is long enough to get wrapped in
emails.
That goes in my /etc/udev/rules.d/20-network.rules file, which is
"chown root:root" and "chmod a=r,u=rw".
You get the names and MAC addresses needed for the above from an
ifconfig command.
After doing all that config on a new 16.04 install or upgrade, you
need to reboot to make it work.
If you hate using UUIDs in your fstab files, these days it is now
possible to label the partitions and replace your UUID= IDs with
LABEL= instead. Use gparted to label each partition with a unique
name, then change fstab to match. Here is some of my test PC fstab,
as an example:
#UUID=4cdea8a6-5646-4a7a-8391-a5b1f4ed28c2 / ext4
errors=remount-ro 0 1
LABEL=Ubuntu16.04-2 / ext4
errors=remount-ro 0 1
# swap was on /dev/sdb7 during installation
UUID=e7612859-ea33-4acb-9b70-b674dbc626b2 none swap
sw 0 0
LABEL=data /mnt/data ext4
relatime,errors=remount-ro 0 2
LABEL=gt70-rec1 /mnt/gt70-rec1
jfs relatime,errors=remount-ro 0 2
LABEL=gt70-rec2 /mnt/gt70-rec2
jfs relatime,errors=remount-ro 0 2
The long lines will be wrapped by the email. I have not yet gotten
around to labeling my swap partition, but I think that now even swap
partitions can be identified by label instead of UUID.
Since you do not use SQL, there is no need to change from MySQL to
MariaDB. I have made that change as the MySQL V5.7 installed by 16.04
now uses the editline library for its command line tools, instead of
readline. That makes it difficult to pull up and re-use old SQL
commands, instead of having to re-type them completely.
More information about the mythtv-users
mailing list