[mythtv-users] kernels

Tue Oct 27 16:52:52 UTC 2020

More about the error here:

https://forums.linuxmint.com/viewtopic.php?t=323152

and here:

https://github.com/linuxmint/mint20-beta/issues/90

If you are still able to boot change compress in
/etc/initramfs-tools/initramfs.conf:

compress=gzip

> 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.
>> _______________________________________________
>>
> Sephen, I did make the magic keys change you suggested, but a hard
> resrtart is still required when I find my machine at the mobo logo, and
> 20.04 seems to always do a fsck on hard restarts. No worries?
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>

-- 
L. de Braal
BraHa Systems
NL - Terneuzen
T +31 115 649333