[mythtv-users] kernels

Thu Oct 22 16:12:04 UTC 2020

On Thu, 22 Oct 2020 11:05:06 -0400, you wrote:

>On Wed, Oct 21, 2020 at 10:49 PM Stephen Worthington <
>stephen_agent at jsw.gen.nz> wrote:
>
>> On Wed, 21 Oct 2020 13:11:03 -0400, you wrote:
>>
>> >this morning I find I can only boot on the older kernel: 5.4.0-51, but not
>> >5.4.0-52, after a couple hard restarts, I get "initramfs unpacking failed
>> >decoding failed"
>> >"kernel panic   not syncing   no working unit found"
>> >"try passing init=option to kernel"
>> >"see linux documentation/admin/guide/init.rst for guidance"
>> >
>> >Questions are: 1)Do I leave it running 24/7?
>> >
>> >                         2)Do I reconfigure grub, as in "
>> >
>> https://www.systutorials.com/how-to-make-grub2-boot-to-older-kernel-version-in-ubuntu-20-04/
>> >"?
>> >
>> >                          3)Or, is there a way to repair the uncooperative
>> >kernel?
>> >
>> >TIA  Daryl    Ubuntu 20.04 mythtv 31 fixes.
>> >P.S. this time it isn't because of my mucking around, a couple of times
>> >over the past ten days I found the box stuck on the boot logo and a hard
>> >reboot worked, so I would guess a slow deprecation?
>>
>> I would use the Synaptic package manager to just manually uninstall
>> the bad kernel's packages.  If you do not have synaptic installed, do
>> this to install it:
>>
>> sudo apt-get install synaptic apt-xapian-index
>> sudo update-apt-xapian-index -vf
>>
>> The apt-xapian-index package is the "Quick index" feature for Synaptic
>> - it is vital to have for searching for the right kernel packages to
>> remove.
>>
>> Then when you run Synaptic, put this in the small "Quick search" field
>> at the top:
>>
>> linux-kernel-5.4.0-52
>>
>> then click on the "Status" button at the bottom left, and then on the
>> "Installed" option in the column above that button.  You should get a
>> list of all the installed packages for that kernel.  The packages you
>> will have will depend a bit on your hardware.  There are always the
>> three basic packages: linux-image-<xxx>, linux-headers-<xxx> and
>> linux-headers-<xxx>-<kernel type>, where xxx is the kernel number
>> ("5.4.0-52" in this case) and the <kernel type> will normally be
>> "generic" unless you have installed a special kernel for some reason.
>> You may also have linux-modules-<xxx>-<kernel type> and some variants
>> of all those names with "extra" or "extras" in them.  You can click on
>> one of them, do Ctrl-A to select them all, then Right-Mouse-Button and
>> click on "Mark for reinstallation" or "Mark for complete removal".
>> Then click on the Apply button at the top.  I would suggest trying the
>> "Mark for reinstallation" option first, and if that does not fix
>> things, just completely remove those packages for now.  Hopefully if
>> this is a kernel bug or a bug in the packaging of the kernel, a fixed
>> version will be along shortly and you can upgrade to that.
>>
>> When you had to do a hard reboot, did you run fsck -C -f on all the
>> partitions that were mounted at the time?  If not, any of them may
>> have some corruption in the filesystem, which could be a reason for
>> initramfs being corrupt.  So I would recommend booting a live image of
>> Ubuntu 20.04 and from there running fsck -C -f on all the partitions,
>> especially the boot partition, before you do anything else like
>> reinstalling the kernel.  If there are any errors to be repaired,
>> repeat the fsck again and again until there are no errors reported.
>>
>
>I don't think any partitions were mounted at the time of hard reboot, I
>only did this when the box was stuck on the logo screen, after boot and
>BIOS options disappear but before booting.  Regardless, I'll run the check.
>
>>
>> Also, if mythbackend was recording at the time you did a hard reboot,
>> the recordedseek table will very likely be crashed and if you are
>> unlucky other database tables could be also.  So after you do the
>> fscks, when you reboot into the normal system, do this to repair the
>> database files:
>>
>
>It wasn't recording on hard reboot, but I optimized anyway.
>
>>
>> sudo systemctl stop mythtv-backend
>> cd /etc/cron.weekly
>>
>> (or wherever you have your optimize_mythdb file - you may have moved
>> it to /etc/cron.daily)
>>
>> sudo ./optimize_mythdb
>> sudo systemctl start mythtv-backend
>>
>> I also edited /etc/default/grub to show the menu and give 10 seconds,
>otherwise, if the first kernel doesn't boot hard reboots are required to
>get the menu to show.

Good idea.  I forget that the defaults where you only have one
operating system on a PC are to have the grub menu not appear unless
you force it to.  I usually have more than one system on all my PCs,
and I manually set the menu to appear if necessary, just in case.

>Another question, kernels are updated fairly regularly, would it hurt to
>wait for the next one, while running 24/7 on my older kernel? Just
>scratching my head here, 'cause I really don't want to borke anything.
>Thanks Stephen, I'll shut down now and do the checks.

No, there is not likely to be any problem with waiting for the next
kernel unless you are running the MythTV box as your router also.  If
it is behind a router, then it is pretty unlikely that there will be
any security problem that missing this kernel upgrade will cause any
dangers.  But it would be a good idea to try reinstalling the bad
kernel to see if that fixes things.  And if there is still a problem,
remove the packages for the bad kernel and do not upgrade the kernel
packages until the kernel after that is available to try.  New kernels
come along fairly regularly so it should be no more than a few weeks
to wait.

With your boot up problem, if the system had not got to the point
where it switches from read-only to writeable then there can not be
any damage from rebooting.  As far as I know, when that switch happens
is around the time that Ctrl-Alt-Del gets switched off.  So if you are
able to reboot during boot up by using Ctrl-Alt-Del, then it is still
safe.  If you have to use the reset button or cycle the power, then it
is much better to try something else first: The Magic Keys
(Alt-SysRq).  In my /etc/sysctl.conf file I have this:

###################################################################
# Magic system request Key
# 0=disable, 1=enable all, >1 bitmask of sysrq functions
# See https://www.kernel.org/doc/html/latest/admin-guide/sysrq.html
# for what other values do
#kernel.sysrq=438
kernel.sysrq=1

So I have changed the setting from the default 438 to 1, which allows
all of the "Magic Keys" to work.  So when I get a lockup condition
that I can not otherwise get out of, I can try holding down the Alt
and SysRq keys (SysRq = PrintScrn on keyboards where it is not
specifically marked), and then doing this sequence with Alt-SysRq
down:

REISUB

You do each of those keystrokes and then wait a second or so before
doing the next one.  What each keystroke does is detailed in the URL
in the comment above or here:

https://en.wikipedia.org/wiki/Magic_SysRq_key

The idea is to get as many critical things as possible shut down in a
safe manner before rebooting (= B) at the end.  If the system is still
even marginally functional, that sequence can protect the filesystems
from any corruption.  However, there are still times when none of
those keystrokes work, or only B, and the filesystem can still be
corrupted.  I have had some crashes in the Nvidia drivers that have
done that to me.