[mythtv-users] kernels

Thu Oct 22 16:31:12 UTC 2020

On Thu, Oct 22, 2020 at 12:12 PM Stephen Worthington <
stephen_agent at jsw.gen.nz> wrote:

> 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.
>
> Well, I stopped scratching my head and grew a pair and did the synaptic
all reinstall, successfully, 52 is running now.
Stephen, U DA Best!    I'll get to the magic key business next, thanks
again.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20201022/5ce42560/attachment.htm>