#REMOVE TRUECRYPT BOOTLOADER INSTALL#
#REMOVE TRUECRYPT BOOTLOADER ISO#
#REMOVE TRUECRYPT BOOTLOADER WINDOWS#

There's a lot I'd love to see improved both for LUKS encrypting and the VM. It's not perfect but I think it's pretty secure, certainly enough for my needs, and seems more solid than the dual boot. 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. If you're using TC, you have your reasons. (Remember the extracted 'volhead').Īnyone could take your unencrypted tc-rescue disk, run grub2tc on them, get your volume header and begin hacking. It also retains the encrypted keys in the bootloader image, whereas grub2tc does not. very insecure, and partially defeats the point of using truecrypt.

#REMOVE TRUECRYPT BOOTLOADER ISO#

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.

#REMOVE TRUECRYPT BOOTLOADER WINDOWS#

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.Įither way, the linker error is why we both get the 'No physical memory is available at the location required for the windows boot manager. 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. I can confirm that I get this same error. Please, do correct me if my understanding of the issue is wrong! I think 21) would be the best solution, but again, this is wild speculation, i lack the required background in grub2/booting/etc. Possible solutions (? this is just wild speculation):Ģ1) 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Ģ2) change grub2 to work from a single MBR sector (as grub1 used to?)Ģ3) 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Ģ4) write/compile a special version of the TC boot loader that assumes that all the required data is in the memory already.

#REMOVE TRUECRYPT BOOTLOADER INSTALL#

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.ġ) when installing grub2 it needs/overwrites more then just the first sector (first 512 bytes, aka the MBR)Ģ) TC uses the first 64 sectors (its MBR, then some code to decrypt the system, and some encryption keys)ģ) 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ġ1) 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ġ2) boot the TC rescue iso image (IIUC, no one reported this to work)ġ3) use grub2tc to generate a kernel from the TC rescue iso image (no reports here that it works, but most probably it does) To get around this problem, we need to backup the volume header and the MBR. 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? 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. So, you need more to backup than the first 512 bytes (as usually mentioned in public manuals). This header is encrypted and contains keys for system volume decryption. I searched the internet, but there is no workaround.īut 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. I got the same problems: Encrypted dualboot (windows, kubuntu 10.04) ist not possible (damaged tc loader). With grub-legacy the chainloading worked. The TrueCrypt Loader is in /boot/truecrypt.mbr The grub2 entry for windows is created by the file 50_windows in the '/etc/grub.d' directory:Ĭat Options > Restore Truecrypt Boot Loader'īut this would install the Bootloader into the MBR, where grub2 shall be. Sda2 = Windows Vista Ultima encrypted with TrueCrypt System Encryption I am working on a dual-boot system with one hard disk.

Remove truecrypt bootloader