Comment 21 for bug 484102

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!