darylangela at gmail.com
Thu Oct 22 15:05:06 UTC 2020
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 "
> > 3)Or, is there a way to repair the uncooperative
> >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
> Then when you run Synaptic, put this in the small "Quick search" field
> at the top:
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mythtv-users