Re: Etch to 5.0.2 upgrade failed - Encrypted filesystem will not boot
On Tuesday 11 August 2009 17:41:48 lineman@ruiner.halo.nu wrote:
> Ok I guess the system is just hosed. If no one has any more suggestions in
> the next couple days I will reinstall.
>
>
> I will never trust Debian upgrades again, at least not when encrypted
> filesystems are in use.
Well, all I can say is that it worked for me.
It's pretty clearly an initramfs problem, since it works for
your other kernel.
It's also very weird (as you've remarked) that you can
apparently initialize the encrypted partition via luksOpen from
within the initramfs, but then not mount it -- I'm assuming you
checked all the obvious things, like whether or not your candidate
mount point (/a in your example) existed.
I have one more nontrivial suggestion -- I suggest installing the
2.6.24 "etchnhalf" kernel. You'll have to pull it from the "etch"
repositories. It's possible that running a new kernel install and
corresponding update-grub and so forth will either (a) work, or (b)
give a more meaningful error message.
Also, please understand that I mean no disrespect, but I feel
compelled to remind you of some possible stupid-mistake solutions:
- Does your 2.6.26 kernel have the same boot options in menu.lst
as the one that works? Are they the default "kopt" options, so
they get propagated to new kernels by update-grub? If you manually
added encryption after your "etch" install, they might not be.
- Is the menu.lst that's modified by the package manager the same one
that the boot-loader is actually using? I once had a system that had
somehow gotten both /grub and /boot/grub directories, both with menu.lst
files in them, only one of which mattered.
- Along similar lines, is update-initramfs writing its files to the
correct place so they're read at boot time?
That's about all I can think of. Good luck.
-- A.
--
Andrew Reid / reidac@bellatlantic.net
Reply to: