Mailing List Archive

kernels
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?
Re: kernels [ In reply to ]
Hoi Daryl,

Wednesday, October 21, 2020, 7:11:03 PM, 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?


Try removing and reinstalling the kernel. Possibly the initramfs is
damaged. This assuming that both kernels use their own initramfs file.

Tot mails,
Hika mailto:hikavdh@gmail.com

"Zonder hoop kun je niet leven
Zonder leven is er geen hoop
Het eeuwige dilemma
Zeker als je hoop moet vernietigen om te kunnen overleven!"

De lerende Mens

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: kernels [ In reply to ]
On Wed, Oct 21, 2020 at 3:14 PM Hika van den Hoven <hikavdh@gmail.com>
wrote:

> Hoi Daryl,
>
> Wednesday, October 21, 2020, 7:11:03 PM, 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?
>
>
> Try removing and reinstalling the kernel. Possibly the initramfs is
> damaged. This assuming that both kernels use their own initramfs file.
>
> Tot mails,
> Hika mailto:hikavdh@gmail.com
>
> "Zonder hoop kun je niet leven
> Zonder leven is er geen hoop
> Het eeuwige dilemma
> Zeker als je hoop moet vernietigen om te kunnen overleven!"
>
> De lerende Mens
>
> _______________________________________________
>
> Hoi Hika, good to hear from you, what do you think about this suggestion:
https://askubuntu.com/questions/253244/reinstall-latest-kernel
specifically #9?
Re: kernels [ In reply to ]
Hoi Daryl,

Wednesday, October 21, 2020, 9:55:37 PM, you wrote:




> On Wed, Oct 21, 2020 at 3:14 PM Hika van den Hoven <hikavdh@gmail.com> wrote:

> Hoi Daryl,
>
> Wednesday, October 21, 2020, 7:11:03 PM, 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?
>
>
> Try removing and reinstalling the kernel. Possibly the initramfs is
> damaged. This assuming that both kernels use their own initramfs file.
>
> Tot mails,
>   Hika                            mailto:hikavdh@gmail.com
>
> "Zonder hoop kun je niet leven
> Zonder leven is er geen hoop
> Het eeuwige dilemma
> Zeker als je hoop moet vernietigen om te kunnen overleven!"
>
> De lerende Mens
>
> _______________________________________________



> Hoi Hika, good to hear from you, what do you think about this suggestion:
> https://askubuntu.com/questions/253244/reinstall-latest-kernel

> specifically #9?

I do not work with Ubuntu but with Gentoo and here kernel updating is
done manual. So I have no experience with the proces under Ubuntu.
But that said, do you still have the old kernel in your bootmenu? And
selecting it does it boot OK?

Then if I understand it right the in page given command:

sudo update-initramfs -u -k 3.2.0-##-generic-pae

does a rebuild of the initramfs. If so that should fix a broken
initramfs.

Otherwise, change grub to by default use this old kernel and you should be
able to uninstall the new kernel while still being able to boot.
Then being back at your previous situation, reinstall the new kernel
and initramfs.

Tot mails,
Hika mailto:hikavdh@gmail.com

"Zonder hoop kun je niet leven
Zonder leven is er geen hoop
Het eeuwige dilemma
Zeker als je hoop moet vernietigen om te kunnen overleven!"

De lerende Mens

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: kernels [ In reply to ]
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.

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:

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
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: kernels [ In reply to ]
On Wed, Oct 21, 2020 at 10:49 PM Stephen Worthington <
stephen_agent@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.

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.
Re: kernels [ In reply to ]
On Thu, 22 Oct 2020 11:05:06 -0400, you wrote:

>On Wed, Oct 21, 2020 at 10:49 PM Stephen Worthington <
>stephen_agent@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.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: kernels [ In reply to ]
On Thu, Oct 22, 2020 at 12:12 PM Stephen Worthington <
stephen_agent@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@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.
Re: kernels [ In reply to ]
On Thu, Oct 22, 2020 at 12:12 PM Stephen Worthington <
stephen_agent@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@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?
Re: kernels [ In reply to ]
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@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@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@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

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: kernels [ In reply to ]
On Tue, Oct 27, 2020 at 12:53 PM Leen de Braal <ldb@braha.nl> wrote:

> 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
>
> I made this change, and got similar results to calling for a log pastebin,
with the added bonus of sending a bug report, due to an internal problem.
Re: kernels [ In reply to ]
On Tue, Oct 27, 2020 at 3:21 PM Daryl McDonald <darylangela@gmail.com>
wrote:

>
>
> On Tue, Oct 27, 2020 at 12:53 PM Leen de Braal <ldb@braha.nl> wrote:
>
>> 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
>>
>> I made this change, and got similar results to calling for a log
> pastebin, with the added bonus of sending a bug report, due to an internal
> problem.
>
Turns out that this was a mysql problem that worked out with the synaptic
all reinstall solution. There still yet may be an underlying cause for the
corruption in, first, the kernel and now mysql, but so far so good.