[mythtv-users] Recommended Linux Distro post CentOS

[Stephen Worthington]

On Wed, 16 Dec 2020 10:08:10 +0000, you wrote:

>On 16/12/2020 03:47, David King wrote:
>> On 12/15/20 10:11 PM, Jeremy D. Eiden wrote:
>>>
>>> On 12/15/20 8:05 PM, James Linder wrote:
>>>>
>>>>> On 16 Dec 2020, at 7:07 am, Mike Perkins <mikep at randomtraveller.org.uk> wrote:
>>>>>
>>>>>> Ben <bkamen at benjammin.net> wrote:
>>>>>>> I'm wondering who is using what for their home servers for MythTV (and Plex) on the same box.
>>>>>> Can't speak for the non-Myth stuff, but my backend and frontends all run Devuan now - what 
>>>>>> Debian would be if they'd not succumbed to the dark side of systemd.
>>>>> I have tried Devuan and it would indeed, be suitable for myth front and backends.
>>>>>
>>>>> However...
>>>>>
>>>>> Despite telling you during installation that "everything is your choice" the default install 
>>>>> desktop is effectively forced to be xfce, whereas I prefer LXDE.
>>>>>
>>>>> The "debootstrap" code was seriously borked when I tried it, and you could not install the same 
>>>>> version in, for example, a VM as the version you were running, only the 'next' version. WTF? 
>>>>> That killed using it for a KVM server stone dead.
>>>>>
>>>>> As I also run LTSP here, and debootstrap is used for the clients, that was a no-no too. I 
>>>>> understand that the 'new' version of LTSP will work properly, haven't tried that on Devuan lately.
>>>> I am not trolling, or standing in a copper vase full of water on a mountain top during a 
>>>> thunderstorm saying all gods are bastards (Terry Pratchette) but why the angst about systemd?
>>>> I find it to be different
>>>> Not particually hard to learn
>>>> Quite nice in principal, being all-in-one-place and consistant
>>>> (My RockPi 4 does xxx on boot, ah systemd stuff)
>>>> James
>>>> PS well 2 places, /etc/systemd /usr/lib/systemd
>>>> PPS and yup in context of mythtv
>>>
>>> Here is my issue with it - when it fails, it fails in really stupid ways that can be hard to 
>>> figure out and fix.
>>>
>>> For example, say you have a second non-system disk that you store recordings or random things on 
>>> (to keep the MythTV link).  Nothing on the OS or even the users truly depend on, and it's mounted 
>>> under /mnt or /media.
>>>
>>> Disk fail?  You remove it to copy the data onto another computer? Systemd will prevent the whole 
>>> system from booting. It'll just hang forever.  You need to boot a usb stick or figure out how to 
>>> you systemrescue to comment out the offending disk in fstab and reboot the system.  Assuming you 
>>> figure out that the disk failed.
>>>
>>> Systemrescue (or whatever it's called) isn't as intuitive as one might think - and if you don't 
>>> have a computer to search the right commands on, you are toast.
>> 
>> Google finds this at https://wiki.archlinux.org/index.php/fstab. This article is also cited as a 
>> solution on multiple other web sites:
>> 
>> External devices that are to be mounted when present but ignored if absent may require 
>> the|nofail|option. This prevents errors being reported at boot. For example:
>> 
>> /etc/fstab
>> 
>> /dev/sdg1        /media/backup    jfs    nofail,x-systemd.device-timeout=1ms    0  2
>> 
>> The|nofail|option is best combined with the|x-systemd.device-timeout|option. This is because the 
>> default device timeout is 90 seconds, so a disconnected external device with only|nofail|will make 
>> your boot take 90 seconds longer, unless you reconfigure the timeout as shown. Make sure not to set 
>> the timeout to 0, as this translates to infinite timeout.
>> 
>I have to point out that your fstab entry has the rather sensible /dev/<device> attachment point, 
>whereas the usual definitions are installed with a UUID= option instead.
>
>Sometimes when making up a test install I will go through and fix all those back to the (commented 
>out) /dev options but most of my boxes are left as default. This makes changing anything more of a 
>task than simply moving a HDD from one host to another.

There is a much better option these days - label the partitions and
use the LABEL= option in fstab.  That makes it easy to move drives
around between PCs, and to work out which drive is which when you have
lots of them (my MythTV box has 16 hard drives and an NVMe SSD).  You
can then also use /dev/disk/by-label/<partition label> when you need
to do fsck, for example.

And the /dev/<device> names are not sensible to use at all.  If you
plug in USB hard drives, that often shifts those names for any drives
on a secondary controller on the motherboard as the USB controller
gets enumerated by the kernel before the secondary SATA controller.
There are probably motherboards out there where at least one USB
controller is enumerated before the main SATA controller.

>Then there's the insane relabelling of NIC interfaces, which are *always* different each time. I 
>always forget and wonder why my new host has booted up with no network, and then have to go in and 
>manually edit /etc/network/interfaces.

Yes, I always manually set up the interface names to be eth0, eth1,
... again as one of the first jobs I do on a new install.  Except that
the way I have been doing that with udev rules is currently being
obsoleted as apparently it also suffers from race conditions.  So I am
expecting to find it will be broken on the next upgrade of Ubuntu.

>...and heaven help you if you have more than one NIC! it *always* chooses the one that doesn't have 
>a cable in, and often doesn't even have a stanza in interfaces.

Yes, it is best to make sure the first Ethernet port is tied down
before installing a second one.  One useful trick is to enable the
systemd option for an early debug root console:

systemctl enable debug-shell.service

or "systemd.debug-shell=1" on the kernel command line.  If you do that
when you are changing things to tie down the Ethernet ports, if you
get it wrong and lose the network connection or even do something that
makes boot up take ages or fail (90 seconds timeout per hard drive,
for example), then you can just do Ctrl-Alt-F9 and edit things and
reboot - much easier than having to boot from a live image or PXE to
fix it.

>£0.02