Hi all,
I just updated the kernel on my 64-bit OpenSuSE 12.1 system and can no longer boot in to my computer. Here are the details:
After the update, I got a kernel panic involving some “VFS error”. This had happened to me before, and running mkinitrd on the system fixed it last time, so I booted an Ubuntu live cd and chrooted into my OpenSuSE installation and ran mkinitrd.
The system is encrypted with LUKS and LVM2 (the way the installer sets it up).
When I rebooted, I didn’t get the VFS panic, but instead am informed that my kernel lacks the encryption algorithm necessary to decrypt my hard drive. The exact error is:
Failed to setup dm-crypt key mapping for device /dev/sda2.
Check that kernel supports aes-cbc-essiv:sha256 cipher (check syslog for more info).
Failed to read from key storage.
Volume group "system" not found.
Volume group "system" not found.
Volume group "system" not found.
Volume group "system" not found.
...
The same error comes up no matter what password I enter, and I obviously can’t check the syslog because the disk isn’t decrypted yet. I tried changing to the default kernel, but when I did, it stopped letting me enter the password (no keystrokes were accepted), so I don’t know if that would would work. When I changed back to kernel-desktop, my situation had not changed.
Any help you can offer would be greatly appreciated!
Thanks in advance!
My system, also using an encrypted LVM, still boots after that update.
It shouldn’t be a kernel problem that is stopping the crypto from working. It might be a problem in the “initrd”.
If possible, boot to rescue mode on the 12.1 DVD (make sure its the 64 bit DVD). Or, alternatively, boot a 64 bit live CD for 12.1.
Unlock your LVM, using cryptsetup. If possible, do that with exactly the names normally used. Then mount at “/mnt” (for the root volume), and mount your “/boot” at “/mnt/boot”.
The man page for mkinitrd(8) will give you the magic incantations needed to run “mkinitrd” from there.
I just did that (for a different reason), for 12.2 Beta2. It turns out that “mkinitrd” uses the way that the file system is opened while “mkinitrd” is running, rather than what is in “/etc/crypttab”.
I hope that helps.
On 2012-06-24 20:06, nthread wrote:
> so I booted an Ubuntu live cd and chrooted into my OpenSuSE
That’s an error. Use an openSUSE live of the same version as your installed
system.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)
Yes, doing the same thing from within the OpenSuSE rescue system worked perfectly. I guess I just didn’t understand how much mkinitrd can differ from distro-to-distro. I assumed it would use the same configuration files, and grabbed the nearest live cd around.
Anyway, it still isn’t clear to me *why *this happened, or how I can prevent it in the future. This has actually happened to me twice, now. The only difference in both cases has been kernel updates, and while most kernel updates don’t leave me in this situation, it seems that it is a possibility in some cases.
Thank you both for your help!
There are probably some logs of the failed “mkinitrd” that must have occurred during the kernel update.
Maybe file a bug report at the bugzilla, and somebody should guide you in finding those logs.
On 2012-06-25 08:46, nthread wrote:
> Anyway, it still isn’t clear to me -why -this happened, or how I can
> prevent it in the future. This has actually happened to me twice, now.
> The only difference in both cases has been kernel updates, and while
> most kernel updates don’t leave me in this situation, it seems that it
> is a possibility in some cases.
Simply by leaving installed the previous kernel when you install the next.
Search for a thread named “multiple kernels” in this same forum.
This at least would leave your system bootable if not updated.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)