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