<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 22, 2020 at 12:12 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 Thu, 22 Oct 2020 11:05:06 -0400, you wrote:<br>
<br>
>On Wed, Oct 21, 2020 at 10:49 PM Stephen Worthington <<br>
><a href="mailto:stephen_agent@jsw.gen.nz" target="_blank">stephen_agent@jsw.gen.nz</a>> wrote:<br>
><br>
>> 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>
>> ><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>
>><br>
><br>
>I don't think any partitions were mounted at the time of hard reboot, I<br>
>only did this when the box was stuck on the logo screen, after boot and<br>
>BIOS options disappear but before booting.  Regardless, I'll run the check.<br>
><br>
>><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>
>><br>
><br>
>It wasn't recording on hard reboot, but I optimized anyway.<br>
><br>
>><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>
>> I also edited /etc/default/grub to show the menu and give 10 seconds,<br>
>otherwise, if the first kernel doesn't boot hard reboots are required to<br>
>get the menu to show.<br>
<br>
Good idea.  I forget that the defaults where you only have one<br>
operating system on a PC are to have the grub menu not appear unless<br>
you force it to.  I usually have more than one system on all my PCs,<br>
and I manually set the menu to appear if necessary, just in case.<br>
<br>
>Another question, kernels are updated fairly regularly, would it hurt to<br>
>wait for the next one, while running 24/7 on my older kernel? Just<br>
>scratching my head here, 'cause I really don't want to borke anything.<br>
>Thanks Stephen, I'll shut down now and do the checks.<br>
<br>
No, there is not likely to be any problem with waiting for the next<br>
kernel unless you are running the MythTV box as your router also.  If<br>
it is behind a router, then it is pretty unlikely that there will be<br>
any security problem that missing this kernel upgrade will cause any<br>
dangers.  But it would be a good idea to try reinstalling the bad<br>
kernel to see if that fixes things.  And if there is still a problem,<br>
remove the packages for the bad kernel and do not upgrade the kernel<br>
packages until the kernel after that is available to try.  New kernels<br>
come along fairly regularly so it should be no more than a few weeks<br>
to wait.<br>
<br>
With your boot up problem, if the system had not got to the point<br>
where it switches from read-only to writeable then there can not be<br>
any damage from rebooting.  As far as I know, when that switch happens<br>
is around the time that Ctrl-Alt-Del gets switched off.  So if you are<br>
able to reboot during boot up by using Ctrl-Alt-Del, then it is still<br>
safe.  If you have to use the reset button or cycle the power, then it<br>
is much better to try something else first: The Magic Keys<br>
(Alt-SysRq).  In my /etc/sysctl.conf file I have this:<br>
<br>
###################################################################<br>
# Magic system request Key<br>
# 0=disable, 1=enable all, >1 bitmask of sysrq functions<br>
# See <a href="https://www.kernel.org/doc/html/latest/admin-guide/sysrq.html" rel="noreferrer" target="_blank">https://www.kernel.org/doc/html/latest/admin-guide/sysrq.html</a><br>
# for what other values do<br>
#kernel.sysrq=438<br>
kernel.sysrq=1<br>
<br>
So I have changed the setting from the default 438 to 1, which allows<br>
all of the "Magic Keys" to work.  So when I get a lockup condition<br>
that I can not otherwise get out of, I can try holding down the Alt<br>
and SysRq keys (SysRq = PrintScrn on keyboards where it is not<br>
specifically marked), and then doing this sequence with Alt-SysRq<br>
down:<br>
<br>
REISUB<br>
<br>
You do each of those keystrokes and then wait a second or so before<br>
doing the next one.  What each keystroke does is detailed in the URL<br>
in the comment above or here:<br>
<br>
<a href="https://en.wikipedia.org/wiki/Magic_SysRq_key" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Magic_SysRq_key</a><br>
<br>
The idea is to get as many critical things as possible shut down in a<br>
safe manner before rebooting (= B) at the end.  If the system is still<br>
even marginally functional, that sequence can protect the filesystems<br>
from any corruption.  However, there are still times when none of<br>
those keystrokes work, or only B, and the filesystem can still be<br>
corrupted.  I have had some crashes in the Nvidia drivers that have<br>
done that to me.<br>
_______________________________________________<br></blockquote><div>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?</div></div></div>