grub4dos mapping to (hd32) or (0xff), General syntax External links Options

[bartonexdu]

Hi, all

Here are some samples of grub4dos iso mapping.
For map --mem, using contig.exe to put pieces of ISO files together into contiguous clusters is highly recommended.

CODE

title  1.0           (map-mem)
map --mem (hd0,0)/test.iso (0xff)
map --hook
chainloader (0xff)
boot

title 1.1        (map-mem)
map --mem (hd0,0)/test.iso (hd32)
map --hook
chainloader (hd32)
boot

title 2.0     (map)
map (hd0,0)/test.iso (hd32)
map --hook
chainloader (hd32)
boot

title 2.1   (map)
map (hd0,0)/test.iso (0xff)
map --hook
chainloader (0xff)
boot

barton

[was_jaclaz]

bartonexdu,
I moved your post from here:
http://www.boot-land.net/forums/?showtopic=5041

The idea of that thread is to post info about specific .iso's that DO WORK with the approach you described (but that is already described in the grub4dos_readme.txt within grub4dos).

The point is that only a small subset of all .iso's can be booted with this method, usually NOT because of problems with grub4dos, but because of the way the .iso's itself are built, the referenced thread should become a list of actual working .iso's (working as they are) or of working .iso's once modified (detailing what needs to be modified in order to have them working).

To clear things about contig an image mapped "directly" NEEDS to be contiguous.
Using contig:
http://technet.microsoft.com/en-us/sysinte...s/bb897428.aspx

Or, as suggested by tinybit, wincontig:
http://www.boot-land.net/forums/?showtopic=4902&st=72
http://wincontig.mdtzone.it/en/

is compulsory or booting won't happen.

When using the map --mem, the image is copied to memory and thus made contiguous on-the-fly, having it contiguous is NOT strictly needed, but may improve speed of booting, and it is however a very good idea to have it contiguous as well.



jaclaz

[bartonexdu]

Jaclaz

I got it .


Your post about grub4dos map iso is very specific




barton