grub install to partition fails with 12.04 alternate & LUKS multiboot setup

[Chris Evans]

[A lot about this is at https://answers.launchpad.net/ubuntu/+source/grub2/+question/193122 but I'm now fairly convinced that it's a bug, not something I'm doing wrong.]

I'm installing 12.04 alternate onto a Toshiba Satellite L750-170. I want to set things up with a multiboot configuration with a Truecrypt encrypted Windows 7 installation and a LUKS/LVM installation of Unbuntu that is also encrypted. That means that I can't let Ubuntu write the grub2 menu to the MBR of /dev/sda as it would destroy the Truecrypt bootloader there. It's clear from various pages on the internet that earlier versions of Ubuntu (and other Linuces I think) have been fine for this. You installed the grub menu to a separate /boot partition (that may no longer be necessary as I think grub2 is LUKS/LVM aware but I haven't risked that), you let Truecrypt load but don't enter the passphrase to boot to encrypted windoze, just hit Esc and the Truecrypt bootloader hands off the booting and my understanding is that it should then find the grub entry on /dev/sda5 (say) and boot fine. At least, it's clear that that worked for several people with earlier versions of Ubuntu.

What happens now is this:
1) I know that U12.04 installs fine before I Truecrypt encrypted the windoze system partition: grub2 installed the menu to the MBR and windoze and Unbuntu booted fine so I know that Ubuntu is fairly happy on the Toshiba
2) HOWEVER, if I ask the U12.04 installation to ask to a 2Gb small partition on either /dev/sda3 or /dev/sda5 (I've tried both) it simply refuses (*** I think this is bug #1 here as I _think_ it may actually have succeeded in doing the installation but is locking on the warnings, alternatively, it may have failed to use the --force option to override the warnings, either is a bug to my mind ***)
3) IF I use the rescue disc approach and try to force grub to install to /dev/sda5 from a root console I get the warning messages but the grub that gets installed doesn't work (more below)
4) when I say it doesn't work, what I mean is that the Truecrypt hand over just locks the machine saying:
   "Error: No bootable partition found". I appreciate that this may be a bug in Truecrypt but there are still bugs in the Ubuntu/grub combination because ...
5) One way that I heard I could rescue things was to use Boot Repair it simply won't show me options to move grub.cfg etc. to any partition but only to rewrite the MBR (which will kill the Truecrypt encrypted windoze)
6) I also found about Super Grub2 Disk (www.supergrubdisk.org) ... this helped me identify a few more things that make me think there are bugs in U12.04/grub since ...
7) it finds the grub.cfg on /dev/sda5 fine showing me three menu lines: linux, linux rescue and windows 7
8) linux rescue boots me into single user root OK after prompting correctly for the LUKS passphrase
9) plain linux just locks with a black screen ... but
10) if I remove "quiet splash vt.handoff=7" from
 linux /vmlinuz-3.2.0-20-generic-pae root=/dev/mapper/sda5_crypt-root ro quiet splash vt.handoff=7
I get a nice boot, I get prompted for the passphrase (*** so one definite bug, my bug #2 here, is that "quiet splash vt.handoff=7" is incompatible with LUKS encryption)
11) BUT I end up with a multiuser mode line/curses login prompt and seem to get in fine as chris, the ordinary user I defined when doing the U12.04 installation, but no Gnome (*** is this bug #3? ***)

Here's what cfdisk shows from a rescue root terminal:

Disk drive: /dev/sda
If I go into that cfdisk shows
Disk drive: /dev/sda
Size: 750156374016 bytes, 750.1 GB
Heads: 255 Sectors per track: 63 Cylinders: 91201

  Primary Free Space 1.05*
sda1 Primary ntfs [SYSTEM] 418.39*
sda2 Boot Primary HPFS/NTFS/exFAT 191572.74*
  Pri/Log Free Space 1.05*
sda5 NC Logical ext2 1998.59*
sda6 NC Logical crypto_LUKS 556163.67*
  Pri/Log Free Space 0.91*

(sorry for formatting there).

Here's the whole of grub.cfg from /boot on /dev/sda5

#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
set default="0"
if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
    saved_entry="${chosen}"
    save_env saved_entry
  fi
}

function recordfail {
  set recordfail=1
  if [ -n "${have_grubenv}" ]; then if [ -z "${boot_once}" ]; then save_env recordfail; fi; fi
}

function load_video {
  insmod vbe
  insmod vga
  insmod video_bochs
  insmod video_cirrus
}

if [ "${recordfail}" = 1 ]; then
  set timeout=-1
else
  set timeout=10
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=white/black
set menu_color_highlight=black/light-gray
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
if [ ${recordfail} != 1 ]; then
  if [ -e ${prefix}/gfxblacklist.txt ]; then
    if hwmatch ${prefix}/gfxblacklist.txt 3; then
      if [ ${match} = 0 ]; then
        set linux_gfx_mode=keep
      else
        set linux_gfx_mode=text
      fi
    else
      set linux_gfx_mode=text
    fi
  else
    set linux_gfx_mode=keep
  fi
else
  set linux_gfx_mode=text
fi
export linux_gfx_mode
if [ "$linux_gfx_mode" != "text" ]; then load_video; fi
menuentry 'Ubuntu, with Linux 3.2.0-20-generic-pae' --class ubuntu --class gnu-linux --class gnu --class os {
 recordfail
 set gfxpayload=$linux_gfx_mode
 insmod gzio
 insmod part_msdos
 insmod ext2
 set root='(hd0,msdos5)'
 search --no-floppy --fs-uuid --set=root b373189d-0999-47a6-a925-0fe6d2511e49
 linux /vmlinuz-3.2.0-20-generic-pae root=/dev/mapper/sda5_crypt-root ro quiet splash vt.handoff=7
 initrd /initrd.img-3.2.0-20-generic-pae
}
menuentry 'Ubuntu, with Linux 3.2.0-20-generic-pae (recovery mode)' --class ubuntu --class gnu-linux --class gnu --class os {
 recordfail
 insmod gzio
 insmod part_msdos
 insmod ext2
 set root='(hd0,msdos5)'
 search --no-floppy --fs-uuid --set=root b373189d-0999-47a6-a925-0fe6d2511e49
 echo 'Loading Linux 3.2.0-20-generic-pae ...'
 linux /vmlinuz-3.2.0-20-generic-pae root=/dev/mapper/sda5_crypt-root ro single nomodeset
 echo 'Loading initial ramdisk ...'
 initrd /initrd.img-3.2.0-20-generic-pae
}
### END /etc/grub.d/10_linux ###

### BEGIN /etc/grub.d/20_linux_xen ###
### END /etc/grub.d/20_linux_xen ###

### BEGIN /etc/grub.d/30_os-prober ###
menuentry "Windows 7 (loader) (on /dev/sda1)" --class windows --class os {
 insmod part_msdos
 insmod ntfs
 set root='(hd0,msdos1)'
 search --no-floppy --fs-uuid --set=root 04FC772AFC771560
 chainloader +1
}
### END /etc/grub.d/30_os-prober ###

### BEGIN /etc/grub.d/40_custom ###
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.
### END /etc/grub.d/40_custom ###

### BEGIN /etc/grub.d/41_custom ###
if [ -f $prefix/custom.cfg ]; then
  source $prefix/custom.cfg;
fi
### END /etc/grub.d/41_custom ###

I'm happy to supply any other information and try anything. I'd really like to get this working and suspect that this multiboot combination is one quite a lot of people will want.

[Ubuntu Foundations Team Bug Bot (crichton)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/979971/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

[bastafidli (ubuntu-bastafidli)]

Marked as duplicate of 997407 so that it is hopefully in the right package and looked at.

[Phillip Susi (psusi)]

Your description is very meandering and so it is difficult to discern what bug you are trying to describe. Let's try to focus it up. If I understand you correctly, you had no problem at all without truecrypt, but with truecrypt, you had difficulty installing grub to a partition instead of the MBR, and had to disable the vt.handoff boot option in order to get the luks prompt, and still gnome won't load?

[Chris Evans (chrishold)]

We obviously use English differently. Your response is unclear to me. What would "no problem without truecrypt be"? What is unclear about the statement:
"That means that I can't let Ubuntu write the grub2 menu to the MBR of /dev/sda as it would destroy the Truecrypt bootloader there."

So, to try to unmeander you. Yes, of course one can install Ubuntu to the MBR, I don't think Ubuntu would be a much used OS if that weren't the case.

Yes indeed, because Truecrypt insists on monopolising the MBR (yes, I know, not your doing etc.) that means that if you want Truecrypt encrypted windoze and ubuntu to coexist, ubuntu has to install the grub bootloader to another partition and yes, my account is clear (see my very clear point #2) that grub/ubuntu/debian-installer seems to have real difficulties with that. I think that's been confirmed as a grub bug elsewhere [Bug 997407] as the previous reply notes.

The rest of this bug report is about what happens when I attempt to get beyond that. I found that I can can override that failure (or apparent failure) to install grub to the partition by using the ubuntu rescue disc and appear to be able, with some external assistance and despite an error message saying you can't, to install a grub boot to a partition (my #3 to #9 above). However, one utterly clear bug to my mind is that this reveals that the "quiet splash vt.handoff=7" default in grub prevents you seeing the LUKS prompt for the passphrase so locks you up if you have LUKS encrypted your partitions. I don't know why that's not the case when you install grub to the MBR, someone who understands grub and the debian-installer can probably see why that is the case.

... But, as you rightly say, even when I remove that and get through to the LUKS prompt for the passphrase I clearly get LUKS decryption but I don't get to gnome and I'm baffled by that and don't understand enough about gnome normally gets launched to go further. I also, as you say, unflatteringly, seem to have had to meander so far up a set of workarounds that I decide simply to put it in as a bug, which I'm sure it is, probably actually a set of bugs.

So hear I am stuck with a lovely machine, with an OS I love and can encrypt (Linux & LUKS: my first love was Debian but after 15 or so years together I'm moving to Ubuntu because I thought it would have better support for newer hardware and exactly this sort of problem) AND I can in principle have encryption of my unloved OS (windoze) that I need to retain for some things ... but I can't have the two cohabiting on the hard disc of my lovely new machine and working for me!

Is that any clearer?

[Phillip Susi (psusi)]

It sounds like truecrypt is leaving your video card in a broken state, causing the gfxboot to be unable to display the luks prompt, and when you work around that by disabling the splash and vt.handoff boot options, X fails to load. Can you attach your /var/log/Xorg.0.log file at that point? Also I don't suppose you could try this type of setup ( Windows install, Ubuntu dual boot with grub installed on a partition instead of the mbr ) without truecrypt in the picture?

[Chris Evans (chrishold)]

I don't see how truecrypt can have broken the video card: the display works fine in windoze and truecrypt has never had access to any of the partitions that contained linux and the installation of linux came after truecrypt was used to encrypt the windoze partitions.

I can try to boot with ubuntu rescue over the weekend, stick in a USB stick & try to pull /var/log/Xorg.0.log off and paste it up here via another machine but if something has killed the Xorg config (which is what I assume you mean by "leaving your video card in a broken state") then it must be something ubuntu did with its failed install or something I did with my attempts to rescue that failed install.

I'm certainly not about to wipe the truecrypt encrypted windoze installation that is working fine to reinstall unencrypted windoze and then go back to trying to install unbuntu encrypted alongside it (which I can vouch for failing as I've been there previously: the ubuntu install, with LUKS encryption, refuses to install grub to a partition, I think that's already been logged as a bug though I can't see it now).

[Phillip Susi (psusi)]

You said that before you set up truecrypt on windows, that ubuntu installed and ran fine, so I inferred that either the problem comes from installing grub to a partition, or from having truecrypt in the MBR that does something weird before running grub.

When I said broken state, I meant the hardware, not a config file.

For testing purposes, could you try installing Ubuntu and letting grub take over the MBR and restore the truecrypt MBR later? If that resolves the luks and X problems, that would confirm the problem is either with grub being in a partition, or truecrypt loading before it. From there we could narrow down which of the two it is by installing a normal boot loader to the MBR and grub to a partition. If having grub in a partition without truecrypt works, but with truecrypt fails, then truecrypt must be doing something strange.

[Maarten Mastbroek (maarten-la)]

I did not have any problems with this. I described the installation process on my techblog. I installed Windows 7 first and encrypted it with Truecrypt. The Truecrypt loader is placed inside the master boot record. Then I installed Ubuntu 12.04 with the alternate CD, created a boot partition first (for /boot), then created a crypto volume and a LVM for the swap and root filesystem. I installed the GRUB loader in the volume boot record inside the boot partition. See my blog for the detailed installation process and screenshots. It is all working fine. If you installed Windows and Ubuntu the other way around you probably have to repair/re-install Grub inside the volume boot record in the boot partition. This is also documented on my blog.

Article: http://techblog.mastbroek.com/all-articles/dualboot-encrypted-windows-and-ubuntu/

Maarten Mastbroek - http://techblog.mastbroek.com

[Chris Evans (chrishold)]

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.

[Chris Evans (chrishold)]

Maarten Mastbroek sent the following at 25/06/12 12:49:
> I did not have any problems with this. I described the installation
> process on my techblog. I installed Windows 7 first and encrypted it
> with Truecrypt. The Truecrypt loader is placed inside the master boot
> record. Then I installed Ubuntu 12.04 with the alternate CD, created a
> boot partition first (for /boot), then created a crypto volume and a LVM
> for the swap and root filesystem. I installed the GRUB loader in the
> volume boot record inside the boot partition. See my blog for the
> detailed installation process and screenshots. It is all working fine.
> If you installed Windows and Ubuntu the other way around you probably
> have to repair/re-install Grub inside the volume boot record in the boot
> partition. This is also documented on my blog.
>
> Article: http://techblog.mastbroek.com/all-articles/dualboot-encrypted-
> windows-and-ubuntu/
>
> Maarten Mastbroek - http://techblog.mastbroek.com
>

That's 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. The default /boot/grub/grub.cfg that Ubuntu had
installed for me says "gfxmode $linux_gfx_mode" but 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.

Now I've got another problem that ubuntu doesn't seem to want to suspend
which is a real pain but I guess that's something quite different!

Many thanks again,

Chris

--
Chris Evans <email address hidden> Skype: chris-psyctc
Consultant Psychiatrist in Psychotherapy, Notts. PDD network;
Professor, Psychotherapy, Nottingham University
*If I am writing from one of those roles, it will be clear. Otherwise*
*my views are my own and not representative of those institutions *
If you have difficulty Emailing me on this address or getting a reply,
send again but cc to: chris dot evans at nottshc dot nhs dot uk
and to: c dot evans at nottingham dot ac dot uk

[Launchpad Janitor (janitor)]

[Expired for debian-installer (Ubuntu) because there has been no activity for 60 days.]