Comment 9 for bug 979971

That article is brilliant Maarten and would have been a great help to me and saves me a lot of work as I was planning to create something like that: no need now as you've done it better than I ever could.

I had misunderstood things about LVM on LUKS that your step through would have clarified for me I'm sure but the real "gotcha" for me on the Toshiba was at the end. I think it's probably fairly specific to the graphics system on this Toshiba.

What happens is that the default /boot/grub/grub.cfg that Ubuntu had installed for me in /dev/sda3 says "gfxmode $linux_gfx_mode". However, that appears to conflict with the way that LUKS was prompting for the key. That left me with a black screen lockout. Here's how I summarised my workaround for Canonical:

"OK. We have some real progress. I think the key incompatibility that is different on this machine from whatever you are using must be about the graphics and that line in /boot/grub/grub.cfg that reads "gfxmode $linux_gfx_mode". That is the killer that gets me the black screen lock up.

What I've done now is a complete reinstall of Ubuntu this time creating a 500Mb /dev/sda3 for /boot, otherwise all the same. I then boot to that using supergrub2 to find that grub.cfg and go for the recovery/rescue option (and the "resume normal boot" that comes up in that). Then I get in and edit that line in /boot/grub/grub.cfg to replace "gfxmode $linux_gfx_mode" with "gfxmode auto" and I seem to be away. "

Thanks for prompting me to bring that fix back here. I hope someone can work out why "gfxmode $linux_gfx_mode" seems to cause this, if only on this particular graphics system. I think it should still be an open bug but with what I've done as a rather non-noobie workaround.