Grub2 doesn't chainload truecrypt loader correctly

[Janosch Maier]

Binary package hint: grub2

I am working on a dual-boot system with one hard disk.
sda1 = /boot
sda2 = Windows Vista Ultima encrypted with TrueCrypt System Encryption
sda3 = Ubuntu 9.10 encrypted lvm

The grub2 entry for windows is created by the file 50_windows in the "/etc/grub.d" directory:

#! /bin/sh -e
echo "Adding Windows Vista entry" >&2
 cat << EOF
menuentry "Windows Vista" {
 set root=(hd0,2)
 parttool (hd0,2) boot+
 chainloader (hd0,1)/truecrypt.mbr
}
EOF

Choosing this entry in the grub2 menu the Truecrypt loader only shows the following message:
"TrueCrypt Boot Loader
Load damaged! Use Rescue Disk: Repair > Options > Restore Truecrypt Boot Loader"
But this would install the Bootloader into the MBR, where grub2 shall be. The TrueCrypt Loader is in /boot/truecrypt.mbr
Booting Ubuntu works without problems.

With grub-legacy the chainloading worked.

The menu.lst:
title Windows Vista
rootnoverify (hd0,1)
savedefault
makeactive
chainloader (hd0,0)/truecrypt.mbr

My Grub2 version: 1.97~beta4

[RobPower (robpwr)]

Same problem here with an XP encrypted partition. It worked well with grub-legacy.
It seems that grub2 has some difficulties chainloading from an image file.
Looking at grub-devel mailing list (is there a similar problem under "Booting TrueCrypt Windows Hard Drive" topic) it seems related to partition or device mapping (not by grub itself, but by the chainloaded OS which maps them wrong.)

It is possible to workaround the problem only in a different configuration, where XP or Vista are on a secondary hard drive, using drivemap to swap drives (look at the mailing list).

No similar solution for XP on a different partition yet (aka the problem reported in this bug).

[Janosch Maier (phylu)]

With Truecrypt Boot Loader installed in the MBR and Grub2 on sda1, the Chainload works correctly.

[RobPower (robpwr)]

about comment #2:
if you have "Truecrypt Boot Loader installed in the MBR and Grub2 on sda1", as far as I know, Grub2 doesn't chainload anything.
You just have Truecrypt Boot Loader that starts first and then, pressing Esc Key, you can skip it and go to Grub2.
So it's Truecrypt that calls (chainloads?) Grub2 and not viceversa. But this bug is about Grub2 ability to chainload Truecrypt Boot Manager.
So no solution yet.

[Janosch Maier (phylu)]

So far so true. But what i meant was: If i load grub2 via Truecrypt Boot Loader and then choose the entry:
menuentry "Windows Vista" {
 set root=(hd0,2)
 parttool (hd0,2) boot+
 chainloader (hd0,1)/truecrypt.mbr
}
It again loads the TrueCrypt Bootloader.

[RobPower (robpwr)]

just to be sure I understood the situation:
you installed grub2 on sda1 and installed truecrypt on windows selecting "single boot" option (not "multi-boot"), right?
So you have "Truecrypt" -->Esc key--> "Grub2" --> Chainload with menu entry --> "Truecrypt" , and if you boot windows from the end of this chain it works, right?
what if you now reinstall Grub on mbr? does it stop working again?
(remember to backup mbr first
dd if=/dev/sda of=/media/<choose a disk>/truecrypt.mbr count=1 bs=512
dd if=/dev/sda of=/media/<choose a disk>/truecrypt.backup count=8 bs=32256 )

[Janosch Maier (phylu)]

Exactely. The chain works as you described it. Reinstalling grub into the mbr lets the TrueCrypt Loader fail loading

[oli z (oliver-z)]

same problem here
i have sda1 for win7 marked as bootable
and sda2 with my /boot marked as bootable
TC loader installed into mbr. when i press ESC it cant boot
now i must use grub and an disturbing boot cd for TC
i know that this worked for grub1
but i have no idea how to switch from grub2 to grub1
grub2 has absolutly no advantages for the user, grub1 was much better

[iulius (iulius)]

Apparently this joke hasn't been resolved yet. why on god's earth would you introduce grub2 as DEFAULT(!!) boot loader, if it's less reliable than the older version. This upgrade made the distro worse. You simply can ship with a buggy part just for the sake of shipping with it.
these are the actions that make the average user turn back to windows or switch to apple. I can't believe it. It's 2010 and a damn boot loader causes problems in an all together advanced and sophisticated piece of software.
Would really like to see that fixed and ship LTS versions only with reliable packages!

[angelo75 (angelo75)]

I got the same problems: Encrypted dualboot (windows, kubuntu 10.04) ist not possible (damaged tc loader).

I searched the internet, but there is no workaround.

But there are interesting informations about the truecrypt loader (see links below): Sector 0 contains truecrypt loader, secotrs 1-62 contain truecrypt resident boot-time decryptor (two mirrored copies), sectors 63 and 64 contain mirrored truecrypt system volume header. This header is encrypted and contains keys for system volume decryption.

http://martin.hinner.info/fs/truecrypt/
http://www.wilderssecurity.com/showthread.php?t=274342

So, you need more to backup than the first 512 bytes (as usually mentioned in public manuals). If I copy back the previously saved truecrypt.mbr (dd if=/truecrypt.mbr of0=/dev/sda count=1 bs=512), I get the same error as if I chainload tc-loader with grub2.

May it be that installing grub2 (grub-install /dev/sda) deletes more than the first 512 bytes only? So that the loader of truecrypt can load itself (program code) but not the header-files?

To get around this problem, we need to backup the volume header and the MBR. Then we setup grub2 such that depending on the user selection (Win oder Kubuntu), it restores the truecrypt volume header, activates that partition and chainloads the TrueCrypt MBR to continue the boot process with pre-boot authentication.

[Raisdead (dmttding)]

For now, a temporary fix is to put the true-crypt recovery disk in the /boot and boot the ISO.
http://michael-prokop.at/blog/2009/05/25/boot-an-iso-via-grub2/
NOT AN IDEAL solution, but will work for now.

[PrSdNt (prsdnt)]

About comment #10:
Has anyone got this to work yet (with a truecrypt bootcd ISO)?

Does the truecrypt bootloader scan all partitions for a bootloader or just the next one when ESC is pressed? I'm planning on installing the grub2-bootloader on /dev/sda3.

[Speezy (speezy)]

Same Problem here.

About comment #11:

I dont got the Truecrypt bootcd iso boot working.
For now i use the "Skip TC Bootloader with ESC" workaround.
I installed the Grub2 Bootloader in sda6.
So i think the Truecrypt bootloader will scan all partitions.

[pzolee (pzoleex)]

Here is my blog about this workaround:
http://pzolee.blogs.balabit.com/2010/07/grub2-and-truecrypt-windows-linux-dual-boot-system/

[DeadVirus (amfcosta13)]

Two years after this bug was repported, isn't this fixed?

[Sjet (sjet)]

Nope, bug still in, no one cares.

[Phillip Susi (psusi)]

So the problem only happens if you hit esc to skip truecrypt, then ask grub to reload truecrypt? Why on earth would you even do that? If you want to boot windows, then don't skip truecrypt the first time.

[Lukas Bunsen (lukasbunsen)]

We are Linux users, our default operating system is Linux. Therefore we have grub in our MBR. Grub is loading by default, and we only chainload the Windows boot manager if we want to start windows.
The approach described by pzolee is only a workaround, as you have to press escape each time to get to your default system.

[Phillip Susi (psusi)]

Grub can not be in the MBR if you are using truecrypt, since it requires the embed area to function. You must therefore, install grub to the partition and truecrypt to the MBR.

You have to press escape to get to grub because truecrypt is in the MBR, and you need to press escape to bypass truecrypt, and load grub in the partition boot sector. If your goal is to boot windows, then you should not press escape to get to grub.

[Lukas Bunsen (lukasbunsen)]

That's not true. I have Grub legacy in my MBR. If I want to boot windows, Grub is loading an image of the Truecrypt Boot Loader from /boot. It is working in that configuration, the only problem is that Grub legacy is able to do that, Grub 2 is not, due to that bug.

[Attila Lendvai (attila-lendvai)]

for the record, there's a project called grub2tc that :

"grub2tc converts the TrueCrypt boot loader into a multiboot kernel that can be loaded from grub2."

instructions: http://gitorious.org/grub2tc/grub2tc/blobs/master/README

[Attila Lendvai (attila-lendvai)]

so, to sum it up:

1) when installing grub2 it needs/overwrites more then just the first sector (first 512 bytes, aka the MBR)

2) TC uses the first 64 sectors (its MBR, then some code to decrypt the system, and some encryption keys)

3) when chainloading a backed up TC MBR from a file using grub2, then it tries to read sectors 2-64 from the physical driver, which has been overwritten by grub2

workarounds:

11) install grub2 into a partition (which is not recommended and warns at install), instead of the MBR, and press ESC at the TC screen to boot linux

12) boot the TC rescue iso image (IIUC, no one reported this to work)

13) use grub2tc to generate a kernel from the TC rescue iso image (no reports here that it works, but most probably it does)

possible solutions (? this is just wild speculation):

21) smarten up grub2 chainload, and chainload TC so that the MBR is ignored and the decryption code, that normally gets loaded/started by the TC MBR, gets loaded/started by grub2 chainload

22) change grub2 to work from a single MBR sector (as grub1 used to?)

23) add feature to grub2 to hijack the bios routines reading from the disk in case of a chainloading a file, and read data from the file instead of the physical disk

24) write/compile a special version of the TC boot loader that assumes that all the required data is in the memory already.

i think 21) would be the best solution, but again, this is wild speculation, i lack the required background in grub2/booting/etc.

please, do correct me if my understanding of the issue is wrong!

[Phillip Susi (psusi)]

That's pretty much it Attila. Both grub2 and TC use the first 62 sectors when installed to the MBR, so you can not install both there. Instead you must install grub2 to a partition.

[Attila Lendvai (attila-lendvai)]

...but installing grub2 to a partition "is a BAD idea" according to its own warning message when installing.

what's the deal with that warning message then?

[Phillip Susi (psusi)]

It is a bad idea because it has to hard code the blocks that contain /boot/grub/core.img into the boot sector. This isn't even possible on some filesystems ( btrfs ), and if the file is ever moved and the boot sector not updated to match, booting will fail horribly.

[Janosch Maier (phylu)]

I don't understand, how it has been working with Grub1. And if or why that implementation is not possible anymore.

[Phillip Susi (psusi)]

Grub1 only used the additional sectors if you enabled stage1.5, otherwise it embedded the blocklist in the MBR. This was found to be too fragile, so now it embeds the core in the extra sectors.

The grub2tc you described seems to be the best way to have the two inter operate, since it eliminates the conflict over the boot track.

[Attila Lendvai (attila-lendvai)]

for people stumbling on this bug report:

just now the git checkout of grub2tc failed for me with an error (extract.rb:78:in `pack': can't convert String into Integer (TypeError))

but this entry seems to work:

menuentry "windoze" {
    insmod part_msdos
    insmod fat
    insmod ext2
    insmod search_fs_uuid
    search --fs-uuid --no-floppy --set=root 01e[...]
    linux16 ($root)/boot/memdisk iso raw
    initrd16 ($root)/boot/truecrypt-rescue-disk.iso
}

requires:

sudo apt-get install syslinux
cp /usr/lib/syslinux/memdisk /boot/

[Attila Lendvai (attila-lendvai)]

FYI, grub2tc has been fixed to work with newer ruby versions, but when i try to boot the generated multiboot kernel i get this error:

"No physical memory is available at the location required for the windows boot manager. The system cannot continue."

the iso booting method in my previous comment works fine though. you can use 'sudo blkid' to find the UUID of your root partition.

[Joseph Harrietha (nictrasavios)]

About Comment #28

I can confirm that I get this same error.

I've done a bit of diagnosing and I have found that its a linker error, the -tText field fails to resolve the system memory address. This could be due to this laptop having a newer UEFI-supporting BIOS, or due to some quirk with where the OS stores its data concerning usable memory.

Either way, the linker error is why we both get the "No physical memory is available at the location required for the windows boot manager. The system cannot continue." error.

The ISO method is imperfect, my main reason being that you cannot, with a hex editor, go in and remove all strings that identify the bootloader as a rescue CD, which means that this solution is very... very insecure, and partially defeats the point of using truecrypt. It also retains the encrypted keys in the bootloader image, whereas grub2tc does not. (Remember the extracted "volhead").

Anyone could take your unencrypted tc-rescue disk, run grub2tc on them, get your volume header and begin hacking. Sure, it still wouldn't be easy... but never underestimate your opponent.
If you're using TC, you have your reasons.

[Chris Evans (chrishold)]

Thanks, that sounds clear. I gave up on trying to do things that way and went for a fully LUKS encrypted disc, (well except for a small stub that acts as the initial bootloader and /boot on /dev/sda1) and I run Windoze using VirtualBox. It's not perfect but I think it's pretty secure, certainly enough for my needs, and seems more solid than the dual boot. There's a lot I'd love to see improved both for LUKS encrypting and the VM. (Windoze is definitely slow in it though I'm not sure why and that fluctuates, I _THINK_ it's partly down to the Windoze antiviral I run in there as sometimes there's a dramatic improvement after that updates itself but it always slumps back to crawl speed. Fortunately I don't need Windoze for that much so I just live with it.)

Anyway, glad to see someone is still interested in this: thanks.

Chris

----- Original Message -----
> From: "Joseph Harrietha" <email address hidden>
> To: <email address hidden>
> Sent: Saturday, 11 January, 2014 6:02:21 PM
> Subject: [Bug 484102] Re: Grub2 doesn't chainload truecrypt loader correctly
>
> About Comment #28
>
> I can confirm that I get this same error.
>
> I've done a bit of diagnosing and I have found that its a linker error,
> the -tText field fails to resolve the system memory address. This could
> be due to this laptop having a newer UEFI-supporting BIOS, or due to
> some quirk with where the OS stores its data concerning usable memory.
>
> Either way, the linker error is why we both get the "No physical memory
> is available at the location required for the windows boot manager. The
> system cannot continue." error.
>
> The ISO method is imperfect, my main reason being that you cannot, with
> a hex editor, go in and remove all strings that identify the bootloader
> as a rescue CD, which means that this solution is very... very insecure,
> and partially defeats the point of using truecrypt. It also retains the
> encrypted keys in the bootloader image, whereas grub2tc does not.
> (Remember the extracted "volhead").
>
> Anyone could take your unencrypted tc-rescue disk, run grub2tc on them, get
> your volume header and begin hacking. Sure, it still wouldn't be easy... but
> never underestimate your opponent.
> If you're using TC, you have your reasons.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/484102
>
> Title:
> Grub2 doesn't chainload truecrypt loader correctly
>
> Status in “grub2” package in Ubuntu:
> Invalid
>
> Bug description:
> Binary package hint: grub2
>
> I am working on a dual-boot system with one hard disk.
> sda1 = /boot
> sda2 = Windows Vista Ultima encrypted with TrueCrypt System Encryption
> sda3 = Ubuntu 9.10 encrypted lvm
>
> The grub2 entry for windows is created by the file 50_windows in the
> "/etc/grub.d" directory:
>
> #! /bin/sh -e
> echo "Adding Windows Vista entry" >&2
> cat << EOF
> menuentry "Windows Vista" {
> set root=(hd0,2)
> parttool (hd0,2) boot+
> chainloader (hd0,1)/truecrypt.mbr
> }
> EOF
>
> Choosing this entry in the grub2 menu the Truecrypt loader only shows the
> following message:
> ...

[nikhil (nikhil-ashok-sharma)]

Hi Guys,

I am able to dual boot my machine ( Windows 7 + Ubuntu) with McAfee Endpoint Encryption enabled on windows.

Below are the details steps that I followed,

1) Installed Windows 7 without McAfee Endpoint encryption enabled. This is because as McAfee encryption is a sector level encryption we cannot an partition if encryption is enabled.

2) Once windows is installed I logged in widows and shrink one of the partition to create a free unallocated space for ubuntu.

3) Then I enabled McAfee Endpoint Encryption in windows and encrypted the hard disk.

4) Then I booted through ubuntu live cd (by clicking on try ubuntu) and made a copy of Master boot record on a pen drive by executing following command,

            " dd if=/dev/sda of=/media/user/pen_drive/safemode.mbr bs=512 count=1"

5) Then I installed ubuntu in the unallocated space that I created by shrinking the partition in windows.

6) After completing ubuntu installation I copied the "safeMode.mbr" file from my pen drive to "/boot" folder in ubuntu.

7) Then I modified "/etc/grub.d/40_custom" and added following lines,

menuentry 'Windows 7' {

       insmod chain
       insmod ext2
       set root=(hd0,4)
       chainloader /boot/safeMode.mbr
       boot
}

insmod :- To load chain and ext2 module
set root = (hd0,4) :- To load ubuntu file system and as ubuntu was installed at "/dev/sda5" so "hd0,4" will the root
chainloader /boot/safeMode.mbr : - TO load the Master boot record of Windows
boot :- To boot through the Master boot record chainloaded

8) Then execute the following command :- "sudo upgrade-grub" to place the "/etc/grub.d/40_custom" file into "/boot/grub/grub.cfg"

9) Reboot and you will see "Windows 7" as as entry in GRUB on selecting it you will be asked for McAfee key.

Both operating system are working fine.

Hope it helps !