darylangela at gmail.com
Thu Oct 22 16:31:12 UTC 2020
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
> >> >5.4.0-52, after a couple hard restarts, I get "initramfs unpacking
> >> >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
> >> >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
> >> >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
> >> 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
> 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
> 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:
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mythtv-users