From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KQmoY-0007HE-8m for mharc-grub-devel@gnu.org; Wed, 06 Aug 2008 13:28:46 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KQmoX-0007H5-3t for grub-devel@gnu.org; Wed, 06 Aug 2008 13:28:45 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KQmoV-0007Gt-C5 for grub-devel@gnu.org; Wed, 06 Aug 2008 13:28:44 -0400 Received: from [199.232.76.173] (port=45522 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KQmoV-0007Gq-96 for grub-devel@gnu.org; Wed, 06 Aug 2008 13:28:43 -0400 Received: from nf-out-0910.google.com ([64.233.182.191]:27596) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KQmoV-0001t2-7t for grub-devel@gnu.org; Wed, 06 Aug 2008 13:28:43 -0400 Received: by nf-out-0910.google.com with SMTP id c7so9732nfi.26 for ; Wed, 06 Aug 2008 10:28:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:in-reply-to :references:content-type:date:message-id:mime-version:x-mailer; bh=p92UMq2DLuCFkDVeoPL56G4YfVPRjGy0YAF+wPzFKHs=; b=X8YWG3o3hkxgJ5jMfXEGKlQQwMasfL3M2misgBFa5feryaLitTuOlL6OGGT6sREXXf aJwGjkiKDIiZXlhOSNi0zHC8DSERgUegwpZ882kqgBBbLcjOXW2NpnDoGfvFRJw+lItA sQCcGxjRJmJ2+1I5VZV0WLTrXFvM4+hKG34g0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:in-reply-to:references:content-type:date:message-id :mime-version:x-mailer; b=Jex3H1llJgLB7B4MUzAEGbLELfAFGXoUyFJp6VDZaTFYPhL8filaT6wgF+bPppgCSh f6t/z+AyVwKeRUW6VJMYSpyY4SNLJcv4J8YIv4maUvkibqG812EC9vYZHP7JJ7R4YPAM FB2qxmkVKaXmbuiiv4TwxUIe6aPICvm5rL8uk= Received: by 10.210.25.19 with SMTP id 19mr2873010eby.13.1218043719951; Wed, 06 Aug 2008 10:28:39 -0700 (PDT) Received: from ?192.168.1.100? ( [213.37.137.93]) by mx.google.com with ESMTPS id y34sm21581647iky.10.2008.08.06.10.28.37 (version=SSLv3 cipher=RC4-MD5); Wed, 06 Aug 2008 10:28:38 -0700 (PDT) From: Javier =?ISO-8859-1?Q?Mart=EDn?= To: The development of GRUB 2 In-Reply-To: <721379.55348.qm@web31608.mail.mud.yahoo.com> References: <721379.55348.qm@web31608.mail.mud.yahoo.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-F+WeEQGmVdkx2ThWQQaI" Date: Wed, 06 Aug 2008 19:31:19 +0200 Message-Id: <1218043880.6890.32.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) Subject: Re: [PATCH] Drivemap module X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2008 17:28:45 -0000 --=-F+WeEQGmVdkx2ThWQQaI Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable El mi=C3=A9, 06-08-2008 a las 07:43 -0700, Viswesh S escribi=C3=B3: > Hi, >=20 > =20 >=20 > 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=3D(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=3D(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=3D(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 --=-F+WeEQGmVdkx2ThWQQaI Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iQIVAwUASJnf56Sl+Fbdeo72AQL5GA/+MW520iW8XloULPG8YunheB/ZFDRB/dpj Ay9ty6rLN1k0um8L0pvGfQE6llQp3Bdi1St4hCY0ygf9D03oyOZJfI0FEDeZju7E fZp4lHqpAzUQQ/xRwZuegQcz5f9waYEhTR808hNsoO/y1UVik6Q1/dBZQFBJa3uZ gZgyxWYQdVMYyonOqHm90fn3KI+3srGjiBsaIwBsOky42imuuejPALauWyxZCtw/ EeHZpcLqrx6fHBqEp03eajCuIInnNkEqj2c7GhdinxOO49Q8jl7sf2jNARhFGH3y Tju4svxehPX9Iv/IANfyI41yXy26GZp22+ra7ZxEfPXGPDByzP6h4yEAUs03454c uD5eeYI7B6avlMdIE0oUKmtipK9yjAZu9xplCVsW6hFnOfcR9ZATdXJTQDG15qLw NqNtQ5yWpMWzyA5v+/bHjc1DFGJey9Y61+G52FcJeLQTL84YHJltz/S0q33NGNAO Eg/v5ncA2j/RlpzsUmBJ52Tk7juotGg8OBMP/iiIZiUss97RBXSbR9F6xvJQ+07v DO04nsvJOV6i8YszakQq/BbwJVkBbm7H7wzA860r53+ybm1eJacJwPOYvhrbkblb 41R8nE7OYQ0qidgO7tOfqJadO1Gn63eECEaKPmAMlNhDZIxKokV1CWEpplqcIYwf T6afhxwAe4A= =GJCE -----END PGP SIGNATURE----- --=-F+WeEQGmVdkx2ThWQQaI--