Comment 29 for bug 484102
Revision history for this message
| Joseph Harrietha (nictrasavios) wrote | #29 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
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.