PDA

View Full Version : [ubuntu] 16.04 LTS: Have kernel without matching initramfs; how to fix?



ArlieS
April 14th, 2018, 09:23 PM
My Ubuntu 16.04 system wedged solid while I was installing the latest updates, and I had to power cycle to reboot it.

When it came back I got "Kernel Panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)". Google led me to https://askubuntu.com/questions/41930/kernel-panic-not-syncing-vfs-unable-to-mount-root-fs-on-unknown-block0-0 The explanation was exactly right - I had a new kernel without the associated new ramdisk.

The description of how to recover wasn't consistent with what I was seeing, but I was able to get to a point where I could boot to recovery mode on an earlier kernel, and from there to something reasonably close to a normal boot, with GUI.

So far so good. But I really don't want to follow out of date instructions for updating grub. Especially if I'm not really using grub, as seems likely. (The instructions are from 2011, and I seem to remember something called "grub2" appearing since then.)

In 2011, the way to solve this would have been
update-initramfs -u -k version to generate the initrd for version then update-grub

I presume 'version' means kernel version. I've no idea of the appropriate format.

In any case, it's 2018. What I really want to know is the right way to do this today, on a Ubuntu 16.04 system originally installed as 12.04 and since updated to 16.04 (via some intermediary LTS version, IIRC).

I'm not afraid of using the command line, or reading documentation. But the last time I was paying attention, I think the boot loader may have been called LILO, not GRUB - i.e. just figure me for completely ignorant ;-)

If I'm lucky, the software updater has the ability to pick up where it left off, figure out it has a half installed new kernel, and fix that. But past experience says that the GUI software updater can't handle this, and the method for fixing things from the command line is a bit arcane. (I found it once, via a chain of error messages, but don't remember how to do it. It wasn't as simple as "apt-get upgrade" or even "man apt-get; then do what the man page suggests" ;-))

ArlieS
April 14th, 2018, 10:59 PM
AFAICT, the relevant vlinuz and initrd were both in my /boot

rerunning grub-mkconfig produced no relevant change.

I got the system booting without intervention again by uninstalling and reinstalling the latest kernel image, using apt-get.
Heavens knows what side effects that may turn out to have ;-)

I'm still interested in knowing what tools I should have used, both to inspect the state and to repair it.