Re: [PATCH] Drivemap module

["Javier Martín" <lordhabbit@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4125 bytes --]

El mié, 06-08-2008 a las 07:43 -0700, Viswesh S escribió:
> Hi,
> 
>  
> 
> Could you let all know how to use your drivemap command.Is it similar
> to the map command in legacy grub.

Hi there. Information about the use of a command is better placed in the
wiki than in this list, however this command is not merged in yet, and I
reckon its "help" feature could be quite better.

Currently, the "safe" GRUB2 commands for booting from (hd1,1) is:

drivemap (hd0) (hd1)
drivemap (hd1) (hd0)
set root=(hd0)
chainloader (hd1,1)+1
boot

Maybe an explanation of what "drivemap" does would put a bit of light
here:

	* The BIOS hard disks are numbered from 0 to 128 (actually from 0x80 to
0xFF because the lower numbers are reserved for floppy disks). These
numbers are used to select the target drive when issuing I/O requests
through the BIOS routines (INT 13h)
	* When the BIOS loads a boot sector and transfers control to it, the DL
register contains the "boot disk number", i.e. the disk from which the
bootsector was loaded. This allows the bootsector to load its OS from
the same disk it was run, instead of having to probe every single disk
in the system.
	* The "chainloader" command works like the BIOS: it loads a bootsector
into memory and jumps to it. In this case, the value in DL corresponds
to the disk that was set as "root drive" to GRUB. If no root drive is
set, the OS receives 0xFF, which should be recognized as an impossible
drive. Some OSes will just trust this and fail (i.e. FreeDOS) while
others will try to boot from the first hard disk (0x80).
	* The "drivemap" command acts as the old TSRs from the DOS times: when
the "boot" command is issued, it installs its own handler for INT 13h
requests, which performs the requested mappings and then call the old
(usually BIOS) handler with the changed parameters. Thus, an OS
accessing the drive through the BIOS routines will see the drives moved,
duplicated or whatever the mappings provided. Again: drivemap does NOT
modify the "live" drive mappings within GRUB; its changes only affect
the booted OS.

The strange root=(hd0) line that appears to contradict the chainloader
line is there because drivemap has no communication with the particular
loader. If you set root to (hd1,1) and then issue chainloader and boot,
the OS will receive 0x81 in DL because hd1 was the second hard drive
when chainloader was issued (remember that drivemap doesn't act until
"boot"). Thus, the target OS will try to boot from what _it_ sees as the
second hard disk, which will now be the old hd0 - wrong.

If the target OS does not need to access the old hd0 or it only uses the
BIOS routines for the boot process (i.e. it later uses ATA drivers and
will redetect everything from scratch), you can leave the second
drivemap line out and use a more compact script like this:

drivemap (hd0) (hd1)
set root=(hd1,1)
chainloader +1
boot

This will work on Windows, because no matter where it tries to boot from
it will find the same disk: both the first and second BIOS disks point
to hd1 now. However, if you use a DOS-like system which uses the BIOS
routines exclusively (i.e. FreeDOS) then your hd0 disk would have
disappeared to it and you'd have D: to be a mirror of C:. In order to
have hd0 as D:, hd1 as C: and everything working, you need the first
script I posted, which makes the complete swap and then makes FreeDOS
load from the "first" hard drive (i.e. hd1). This is the setup I have
extensively tested in QEMU, while the Windows boot has been tested in
both QEMU (with ReactOS) and some random computers including mine (with
Windows XP Home and Windows XP Pro x64).

I'm looking forward to streamline the drivemap syntax, so that the two
drivemap lines can be fused into one like "drivemap --swap (hd0) (hd1)".
However, given that it's not a bug and that GRUB is still in heavy
development (and thus syntax changes are acceptable), I'd prefer to have
the patch integrated as it is - so we have the functionality - and then
modify what's needed - so we have it pretty.

-Habbit

[-- Attachment #2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 827 bytes --]