[mythtv-users] Ubuntu 18.04.1 LTS do-release-upgrade with Mythtv

[Stephen Worthington]

On Fri, 26 Oct 2018 12:14:46 -0400, you wrote:

>
>On 10/7/18 11:37 AM, Stephen Worthington wrote:
>> On Sun, 7 Oct 2018 08:02:02 -0400, you wrote:
>>
>>> Has anybody who has a working Ubuntu 16.04.5 system with mythtv backend
>>> V29 been brave enough to run do-release-upgrade and see what happens?
>>>
>>> And No I'm not that brave.
>>>
>>> Jim A
>> Yes, I have just done it and am working through the resulting issues.
>>
>> I was running a combined frontend+backend v29 system on 16.04.5, but
>> without HWE, so it was still on kernel 4.4.  The upgrade to 18.04.1
>> went as normal - no problems in the process.  I had a number of /etc
>> files that were modified and I had to patch my changes into the new
>> versions (or patch the new bits of the new versions into my old
>> files), but that happens every upgrade.  I use MariaDB, having
>> switched to that at the 16.04 upgrade.  That caused no problems.
>>
>> The startup and particularly the shutdown times for 18.04 are faster
>> than for 16.04 - especially if you are using an SSD system drive which
>> can support much more parallel activity than rotating rust.  The work
>> done on systemd in 18.04 looks like it has paid off.
>>
>> The upgrade process did still take several hours, even though I have a
>> fast NVMe SSD and a gigabit connection to a nearby Ubuntu repository.
>> If your MythTV box is busy like mine is, you might like to use my
>> "gaps" Python program to find a large enough gap in your recording
>> schedule to do the upgrade.  It is available on my web server:
>>
>> http://www.jsw.gen.nz/mythtv/gaps
>>
>> and I think you will also need my fixed version of the Utilities.py
>> library from the Wiki (put it in the same directory):
>>
>> http://www.jsw.gen.nz/mythtv/Utilities.py
>>
>> The issues I know about:
>>
>> 1) If you have an old Nvidia card that requires the 304 drivers, do
>> not do the upgrade as the 304 drivers are not available for 18.04 as
>> Nvidia has stopped support for them, which made Ubuntu also delete
>> support for them.
>>
>> 2) If you are using a frontend on the same box, then you will likely
>> need lirc to work, and as installed by the 18.04 lirc package, it is
>> badly broken.  See the recent "Remote control issue after Ubuntu
>> upgrade" and "Blasting to STB,using a MCEUSB" threads here.  I have a
>> script on my web server to fix it so it works:
>>
>> http://www.jsw.gen.nz/mythtv/lirc-ubuntu-18.04-install.sh
>>
>> I have just updated the script for a new problem I discovered today.
>> On my laptop (which I have also just upgraded from 16.04 to 18.04.1),
>> I use a USB tuner with a builtin IR receiver.  I only start
>> mythbackend and mythfrontend when I am using the laptop for TV, and
>> when I am using it for other things, I normally do not plug in the USB
>> tuner.  That caused the new lirc to fill up syslog with error
>> messages.  It turned out that the lirc package now also installs a
>> systemd unit to run irexec in the background using a default config.
>> Having irexec running when lirc does not have an IR receiver available
>> was causing all the spurious error messages.  So that background job
>> needs to be disabled:
>>
>> sudo systemctl stop irexec
>> sudo systemctl disable irexec
>>
>> 3) The ext4 drivers have been updated, so you will no longer be able
>> to run fsck of 18.04 ext3 and ext4 partitions from earlier versions. I
>> have a separate partition I use to boot to do repairs on my main
>> system partition, including doing a full fsck on all my partitions
>> after a power failure, and I had to update that to 18.04 as well.  You
>> can still boot from an 18.04 live DVD to do repairs, but older
>> versions will not work.  So make sure you have what you need for
>> repairs available before you upgrade, just in case.  And you will need
>> a recent version of clonezilla also to properly handle the new ext4
>> updates, if you want to use it to do an image backup of your system
>> after upgrading.
>>
>> 4) The x11vnc VNC server seems to be broken in the new 18.04 version.
>> It crashes whenever I try to use the menu on the MythTV box over a VNC
>> connection.  I am still working my way through this problem - I may
>> have to use a different VNC server.  The recommendation I found on the
>> web to switch my display manager to lightdm did not work - I was
>> already using lightdm as that is the default in Mythbuntu (and Xubuntu
>> I think).
>>
>> 5) The new OpenVPN version had one of its server config lines change
>> syntax, so it failed to run until I fixed that.  If you are using an
>> OpenVPN server, check its log to see if you have a problem like that.
>>
>> 6) logrotate is now being pedantic about the permissions in the
>> /etc/logrotate.d directory.  The files must be 0644 or 0444 or it
>> ignores that file.  The files ignored are listed in the email sent by
>> the daily logrotate cron job.
>>
>> 7) SAMBA/CIFS has been updated to a newer version, which will no
>> longer connect to older (now insecure) versions of the SMB protocol
>> unless you add options to override the SMB protocol version.  I am
>> still running an older version of SAMBA on my OS/2 server box, so I
>> had to add the option ",vers=1.0" to all my mount points in fstab for
>> that box.
>>
>> 8) PHP has been updated to version 7.2.  On one of my boxes (I forget
>> which), PHP 7.0 had not been disabled, and that made mythweb and
>> mythexport not work.  I had to manually disable PHP 7.0:
>>
>> sudo a2dismod php7.0
>>
>> Then I had to do these commands as per several other threads here:
>>
>> sudo cp -a /etc/php/7.0/apache2/conf.d/20-mythweb.ini
>> /etc/php/7.2/apache2/conf.d/20-mythweb.ini
>> sudo a2enmod php7.2
>> sudo systemctl restart apache2
>>
>> I think that after that I could uninstall the PHP 7.0 packages, but I
>> have not tried that yet.
>>
>> 9) The Perl setup has been upgraded, and that made the mythexport Perl
>> .cfi files fail to find their library files which are in the same
>> directory as they are.  I had to modify all the
>> /usr/share/mythtv/mythexport/*.cgi files to add a line:
>>
>> use lib '.';
>>
>> to the use statements at the top of each file.
>>
>> 10) The Python 2 version has been upgraded, and in doing so a module I
>> was using in my "mythsgu" Python program that uses the MythTV API was
>> unable to be found
>> (backports.shutil_get_terminal_size.get_terminal_size).  It must have
>> been split out into a separate package rather than the one it was in
>> for 16.04, so I had to find it in its new package and install that:
>>
>> apt install python-backports-shutil-get-terminal-size
>>
>> 11) The problem I have had since I upgraded to 16.04 where the ALSA
>> output for my SPDIF connection to my DAC keeps getting randomly turned
>> off 1-3 times a day is still present in 18.04.1.  I will have to try
>> and track down the source of that - it is annoying to be watching a TV
>> recording and have the sound disappear and have to do an "alsactl
>> restore" command to get it back again.
>>
>> 12) anacron seems to be running the daily cron jobs at a different
>> time - about an hour earlier than it used to.  I have changed the
>> /etc/crontab settings back to the old times, but I will have to wait
>> until tomorrow to see if that fixes it.  The old times were normally a
>> time when I do not have any recordings happening, or only one
>> recording.  Having the cron jobs run earlier was a problem as the
>> system could be too busy at the time and have recordings fail due to
>> the huge overheads on the database when it is checked and backed up by
>> anacron.
>>
>> 13) On my main MythTV box, but not on my laptop, I am getting several
>> messages (from grub, I think) saying "symbol table not found" and
>> "press any key to continue".  They do not cause any problems - the
>> boot process proceeds normally.  But I will need to look at why they
>> are happening.
>>
>> That is all I can remember at the moment - I will update this thread
>> if I find anything new.
>> _______________________________________________
>
>
>I had some time on this raining day to review in more detail what you 
>found going from 16.04 to 18.04. Some things I noted for my installation:
>
>1.  In my case the backend is built on 16.04 Server version and is still 
>on the 4.4.0-138-generic x86_64. It is up to date with the latest Ubuntu 
>and Mythtv software.
>
>2.  My only tuner is a SiliconDust Homerun HD Quatro, so no driver 
>issues.  Not sure about systemd changes I might need.
>
>3.  I've use "ssh -X jim at mythbuntu" so I can run mythtv-setup on the 
>backend.
>
>4.  The 4 drives on the backend are configured by mdadm to be 2 sets of 
>mirrors.
>
>5.  I have a APC USP to backup the power and shutdown the system if loss 
>of power is more than 30 minutes. So I use the  apcuspd software and 
>cgi-gui.
>
>6.  I also use mythweb to work the tv record schedule.
>
>7.  Since I'm on MariaDB from 16.04 install, I'm hoping the changes I 
>had to do to allow remote FEs will still work and upgrade in place.
>
>So I'm thinking I may not have too big an issue.
>
>Comments?
>
>Jim A

I think you will want to do the anacron fix if you have recordings
happening just after midnight - 07:30 is a much better time to have
the database check and backup jobs being run.  And you will need to do
the PHP fixes for mythweb.

Running network tuners requires that mythbackend only start after the
network access to the tuners is fully up, which requires a systemd fix
that is likely the one you already have in 16.04.  But 18.04 boots
faster and with more parallelism, so if you have not had to do that
fix, it will almost certainly be required in 18.04.

I would suggest doing a web search to see if there are any new
problems with mdadm and RAID in 18.04.  There have been problems in
the past when upgrading them, and I do not use RAID (I do not have the
mdamd package installed even), so I will not have met them.  Nor any
problems with APC software.