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
signature.asc
Description: Esta parte del mensaje está firmada digitalmente
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel