Kernel pani - what could I do now?

After the latest kernel update and after rebooting I got this:

kernel panic - not syncing: VFS: unable to mount root fs on unknown-block (0/0)
pid 2, comm: swapper/0 Not tainted 3.7.10-1.11-desktop #1

I have an installation DVD at hand. I recently removed the multikernel option from zypper.conf. Any suggestions on how to get this system back to working?

…never had so much trouble with openSUSE as I have after the release of 12.3 (ignore my frustration)

On 2013-06-01 17:06, Nikos78 wrote:
>
> After the latest kernel update and after rebooting I got this:

What openSUSE version do you have?

What grub version, 2 or 1?

> I have an installation DVD at hand. I recently removed the multikernel
> option from zypper.conf.

Hah! Serves you right, now you can not boot, and you can not boot with
the old kernel either. :-p

The feature is there for a reason…


Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

What openSUSE version do you have?

12.3

What grub version, 2 or 1?

2

The feature is there for a reason…

Yep, I know that, but I disabled it for a reason too (My boot partition is only 150Mb and I once had to make a reinstall because in a series of updates, including a kernel and zypper update…anyway you are right, but that doesn’t help a lot)

My guess is, that somehow you got kernel-desktop-**base **installed and that is lacking the driver for your harddisk controller…

Well, you somehow have to get a working kernel and initrd to your boot partition.
Maybe you could fix it like this: (replace i586 with x86_64 everywhere if you have a 64bit system)

  • download the kernel-desktop-3.7.10-1.4.1.i586.rpm package from Index of /update/12.3/i586 (or just take the kernel RPM that is on the installation DVD for the next steps)
  • boot the installation CD and select “Rescue System”
  • mount your harddisk root partition to anywhere (let’s say /mnt)
  • mount your boot partition to /mnt/boot
  • install the kernel package with
sudo rpm -Uvh --force --root /mnt kernel-desktop-3.7.10-1.4.1.i586.rpm

(or use the path to the installation CD’s kernel RPM instead)

That should hopefully bring you back a bootable kernel, but I’m not 100% sure if this works…

Thank you, I am going to try this. I wanted to add:

initramfs unpacking failed

is the first line before the panic…

Now, to your suggestion. My root partition is on an encrypted LVM, how would I go about mounting that from the command line?
PS: Indeed I am on a 64bit system (the first in my signature)

OK, then just the initrd seems to be corrupt, so mkinitrd should suffice instead of installing a kernel.
But you would have to chroot to your system first. (the rpm line above does that)

Now, to your suggestion. My root partition is on an encrypted LVM, how would I go about mounting that from the command line?

No idea, sorry.
Never used an encrypted LVM…

Or you could try this:
https://plus.google.com/photos/107564133608385811033/albums/5515870388381660129?banner=pwa

OK, I just used the DVD to update an existing system and allowed it to only update the kernel. Thank you, that was close. I am going to reenable multikernel support now, so that Carlos does not mock me any more:P.

Thank you!

Wow, that is great that somebody put this in pictures for future reference.

On 2013-06-01 18:46, Nikos78 wrote:
>
>> What openSUSE version do you have?
> 12.3
>> What grub version, 2 or 1?
> 2
>> The feature is there for a reason…

> Yep, I know that, but I disabled it for a reason too (My boot partition
> is only 150Mb and I once had to make a reinstall because in a series of
> updates, including a kernel and zypper update…anyway you are right,
> but that doesn’t help a lot)

Well, I was waiting for your response :slight_smile:

I see you are in track with wolfi323’s help.

About your lack of space in /boot, you might consider removing plymouth
to save some space in initrd. You’d get the password prompt in text
mode, though.


Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

On 2013-06-01 19:46, Nikos78 wrote:
>
> Nikos78;2561906 Wrote:
>> Or you could try this:
>> ‘https://plus.google.com/photos/10756...129?banner=pwa
>> (http://tinyurl.com/mzffddw)
>>
> Wow, that is great that somebody put this in pictures for future
> reference.

Indeed, I like the trick about “keeping” installed packages.


Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

On 2013-06-01 19:46, Nikos78 wrote:
>
> OK, I just used the DVD to update an existing system and allowed it to
> only update the kernel. Thank you, that was close. I am going to
> reenable multikernel support now, so that Carlos does not mock me any
> more:P.

:slight_smile:

Besides plymouth, you may have to, before updating a kernel, remove the
old one. Normally you have two, just after the update you have 3. On the
next boot the older is deleted; I think you should remove it before the
update.


Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

I could live with that, and this

Before updating a kernel, remove the
old one.

is good idea. Gonna stick with it,

You could also change the 'multiversion.kernels" setting in /etc/zypp/zypp.conf to just the running kernel:

multiversion.kernels = running

So then you would only have one kernel.
An update would additionally install another one, so you would have 2.
And the older one would be automatically removed, when the newer one successfully boots…

So it would be a lot safer than without multiversion, and not take too much space.

On 2013-06-01 23:26, wolfi323 wrote:

> You could also change the 'multiversion.kernels" setting in
> /etc/zypp/zypp.conf to just the running kernel:
>
> Code:
> --------------------
> multiversion.kernels = running
> --------------------
>
> So then you would only have one kernel.
> An update would additionally install another one, so you would have 2.
> And the older one would be automatically removed, when the newer one
> successfully boots…

If it gets stuck a bit later, after the moment when the previous one is
deleted, you are in trouble.


Cheers / Saludos,

Carlos E. R.
(from 11.4, with Evergreen, x86_64 “Celadon” (Minas Tirith))

That’s true, but it’s safer than disabling multiversions completely and it would protect against the original problem that started this thread.
Also, purge-kernels is run quite late in the startup process, so there shouldn’t be any kernel problem preventing boot then anymore. (actually, on my system the oldest kernel only got deleted after I was already logged in to KDE, because “rpm -qa” which purge-kernels calls to find out which kernels are installed took so long… :wink: )

But of course it’s not as safe as keeping 2 kernels…