Edited by Andreea, 27 December 2014 - 10:53 PM.
A lot of questions about grub4dos& truecrypt working together
#1
Posted 27 December 2014 - 10:28 PM
#2
Posted 27 December 2014 - 11:17 PM
Lots of questions, a few (educated BTW ) guesses but not (yet ) some basics on the background.
A few (hopefully useful) answers:
The "boot" command is needed (as last command) to boot when you are issuing commands in grub4dos command line, when you have a menu.lst the "boot" command is implied as last command of any entry that contains a chainloader or a kernel + intrd command.
But of course it has nothing to do with the map --hook command that simply hooks (i.e. renders "permanent within the boot session" the previous device (re-) mapping).
The MBR is not black (the full exact content of the "truecrypt MBR") or white (completely made of zeroes) only but rather has several shades of gray, there are 4 (four) parts in it:
- the CODE that is at offset 0 up to offset 440
- the DISK SIGNATURE that is at offset 440 and is 4 bytes long
- the PARTITION TABLE, a set of four entires, each 16 bytes in length, starting at offset 446
- the MAGIC BYTES 55AA at offset 510
What you tried till now is seemingly only 1+2+3+4 and 0, whilst what is enough to not be able to recognize the "truecrypt nature" of the MBR is simply that of removing the #1 part (the CODE), all the other parts are needed:
2. the DISK SIGNATURE to allow the booting XP to assign the C:\ drive letter to the right volume on the right disk
3. the PARTITION TABLE to allow the booting XP to even find the volume and to load files from it.
4. the MAGIC BYTES to allow the booting XP to recognize the disk as "initialized"
And yes, your grub4dos menu.lst entry is correct
map (hd0) (hd2) <- this means "from now on let's make grub4dos call the first disk (hd2), i.e. let's map first disk to third disk
map (hd2) (hd0) <- this means "from now on let's make grub4dos call the third disk (hd0), let's map third disk to first disk
map --hook <- this means OK, now that I have changed the mapping of devices, let's make this changes permenent (within this boot) and let's "export" them to the BIOS device table so that whatever interrogates the BIOS will read the disks as I re-order them.
Since you booted from USB the first disk was the USB device and the third disk is the "truecrypted" one, so basically at this point it is exactly if you initiated the boot from the "truecrypted" disk BUT before you execute any CODE on it
rootnoverify (hd0,0) <- this establishes root on the first volume of your (now) first disk, i.e. the "truecrypted" one
chainloader (hd2,0)/tc.dat <- this loads the file /tc.dat from your (now) third disk, i.e. the USB stick
boot <- this command is really not in your menu.lst entry but it will be executed automatically by grub4dos, since the menu entry has reached its end (or if you prefer whenever grub4dos finds the EOF next or the string "title" - which is the beginning of the next menu.lst entry, if the chainloader command was present, i.e. the entry is a "bootable" one )
This said, it is of course well possible to write a sector "on the fly" when booting to grub4dos, you will need to use the grub4dos dd command (which has a syntax similar or actually the same as in Linux):
grub> help dd
dd: dd if=IF of=OF [bs=BS] [count=C] [skip=IN] [seek=OUT] [buf=ADDR] [buflen=SI
ZE]
Copy file IF to OF. BS is blocksize, default to 512. C is blocks to
copy, default is total blocks in IF. IN specifies number of blocks to
skip when read, default is 0. OUT specifies number of blocks to skip
when write, default is 0. Skipped blocks are not touched. Both IF and
OF must exist. dd can neither enlarge nor reduce the size OF, the
leftover tail of IF will be discarded. OF cannot be a gzipped file. If
IF is a gzipped file, it will be decompressed automatically when
copying. dd is dangerous, use at your own risk. To be on the safe side,
you should only use dd to write a file in memory. ADDR and SIZE are
used for user-defined buffer.
So, which EXACT version of grub4dos are you using?
WHATEVER you are using now it is most probably "wrong" , right now you should be using the latest version of the 0.4.5c series, get it from here:
http://grub4dos.chen...ries/downloads/
right now:
http://grub4dos.chen....5c-2014-12-24/
Or get the last "featured" version (which would be "recent enough" and "stable enough" for your uses) here:
http://code.google.c.../downloads/list
http://code.google.c...-03.7z&can=2&q=
Please take some time (if needed) to digest the above info and try with the MBR with just the CODE removed (first 440 bytes zeroed) and post when you are ready to try the dd command (if you need advice on the exact commands you need).
Wonko
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users