120 replies to this topic

[SamK]

After working with Grub4DOS for a few days the construction of a multiboot CD-ROM toolkit is progressing well. Currently working are the following applications for linux and FreeDOS using ISO & floppy disk images:
DBAN v 1.0.7, CopyWipe 1.14, Ghost 2003, Super Grub 0.9725.

To complete this stage of the construction two additional ISOs are to be added, Parted Magic and Clonezilla. Both of these are proving difficult to incorporate. Has anyone succeeded in booting these ISOs via Grub4DOS? If so would you be willing to post how this was achieved?

Research conducted in various forums generally point to using isolinux or BCDW. The toolkit currently under construction is an attempt to unify a collection of multiboot and single boot CD-ROMs which variously use isolinux and BCDW into a single CD-ROM using only Grub4DOS. Ultimately booting only ISOs (no floppies).

Grub4DOS
Version Downloaded - grub4dos-0.4.3-2008-05-14.zip
Downloaded From - http://grub4dos.jot.com/WikiHome

Parted Magic
Version Downloaded - pmagic-svn.iso-08Jun,134947.zip (Extracted and renamed pmagic.iso)
Downloaded From - http://partedmagic.com/beef_drapes/
This will be released as version 3.0 "...wait until linux 2.6.26 comes out before 3.0 is called stable."

Clonezilla
Version Downloaded - clonezilla-live-20080511-hardy.iso (Renamed clonzlla.iso)
Downloaded From - http://www.clonezilla.org/


MENU.LST

# menu.lst - User configurable menu of available boot-time options provided by Grub4DOS## ISO Information# Command to create#	mkisofs -R -b grldr -no-emul-boot -boot-load-seg 0x1000 -volid "XXX" -o bootable.iso iso_root#	or# 	mkisofs -R -b grldr -no-emul-boot -boot-load-size 4 -volid "XXX" -o grldr.iso iso_root## ISO Burning Application#	ImgBurn	color black/cyan yellow/cyantitle TEST 1                  ---   Parted Magic via ISO   find --set-root --ignore-floppies /img-iso/pmagic.iso   map /img-iso/pmagic.iso (hd32)   map --hook   chainloader (hd32)   rootnoverify   boottitle TEST 2                  ---   Clonezilla via ISO   find --set-root --ignore-floppies /img-iso/clonzlla.iso   map /img-iso/clonzlla.iso (hd32)   map --hook   chainloader (hd32)   rootnoverify   boottitle WIPE DISKS              ---   DBan 1.0.7   find --set-root --ignore-floppies /img-iso/dban.iso   map  /img-iso/dban.iso (hd32)   map  --hook   chainloader (hd32)   boottitle WIPE DISKS              ---   CopyWipe 1.14   find --ignore-floppies /img-fd/bootfd06.img   map /img-fd/bootfd06.img (fd0)   map --hook   chainloader (fd0)+1   rootnoverify (fd0)   boottitle CREATE/RESTORE IMAGES   ---   Ghost 2003   find --ignore-floppies /img-fd/bootfd06.img   map /img-fd/bootfd06.img (fd0)   map --hook   chainloader (fd0)+1   rootnoverify (fd0)   boottitle MANAGE BOOT LOADER      ---   Super Grub 0.9725   find --ignore-floppies /img-fd/suprgrub.img   map /img-fd/suprgrub.img (fd0)   map --hook   chainloader (fd0)+1   rootnoverify (fd0)   boottitle WARM BOOT               ---   Reboot the PC   savedefault --wait=2   reboottitle SWITCH OFF              ---   Power Down the PC   savedefault --wait=2   halt

RESULT - PARTED MAGIC
File found and mapped
Chainloader = Load Segment: 0x0 System Type: 0x0 Sector Count: 0x4
Load RBA: 0x1E Boot Type: 0 = No Emulation
Boot = ISOLINUX 3.63 2008-04-10
Stalls at this point

RESULT - CLONEZILLA
File found and mapped
Chainloader = Load Segment: 0x0 System Type: 0x0 Sector Count: 0x4
Load RBA: 0xB9CE Boot Type: 0 = No Emulation
Boot = ISOLINUX 3.62 2008-03-01
Stalls at this point


ALTERNATIVE TRIED

filename.iso (hd32)
   map --hook
   chainloader (hd32)
   rootnoverify
   boot _linenums:0'>find --set-root --ignore-floppies /img-iso/pmagic.iso   map --mem /img-iso/filename.iso (hd32)   map --hook   chainloader (hd32)   rootnoverify   boot

RESULT - PARTED MAGIC
PC reboots

RESULT- CLONEZILLA
Symptoms unchanged

[was_jaclaz]

You may want to try the kernel and initrd directives, instead of chainloading the bootsector thus bypassing the isolinux inside the .iso image.

jaclaz

[SamK]

You may want to try the kernel and initrd directives, instead of chainloading the bootsector thus bypassing the isolinux inside the .iso image.

jaclaz

Thanks for a very swift reply, jaclaz. I am not sure I fully understand your suggestion. Would it be possible to give an example?

[SamK]

You may want to try the kernel and initrd directives, instead of chainloading the bootsector thus bypassing the isolinux inside the .iso image.

jaclaz

On the assumption that I have correctly understood your suggestion the following steps have been conducted for each of Parted Magic and Clonezilla:

• Establish the contents of isolinux.cfg
• Select the "failsafe" option (being the most likely to work)
• Transfer the kernel and initrd lines to Grub4DOS
• Boot using transferred parameters
• Report results

PARTED MAGIC - EXTRACT FROM ISOLINUX.CFG
...
LABEL failsafe
MENU LABEL ^4. Failsafe Settings
TEXT HELP
vga=normal, acpi=off, noapic, nolapic, nopcmcia, noscsi, nogpm, nosmart, & boots to console
ENDTEXT
KERNEL /pmagic/bzImage
APPEND noapic initrd=/pmagic/initrd root=/dev/ram0 init=/linuxrc keymap=us livecd vga=normal sleep=0 acpi=off noapic nolapic nopcmcia noscsi nogpm consoleboot nosmart ramdisk_size=25000
...


CLONEZILLA - EXTRACT FROM ISOLINUX.CFG
...
label Clonezilla live failsafe mode
# MENU DEFAULT
# MENU HIDE
MENU LABEL Clonezilla live (Failsafe mode)
# MENU PASSWD
kernel /live/vmlinuz1
append initrd=/live/initrd1.img boot=live union=aufs hostname=hardy acpi=off irqpoll noapic noapm nodma nomce nolapic nosmp ip=frommedia vga=normal
TEXT HELP
acpi=off irqpoll noapic noapm nodma nomce nolapic nosmp vga=normal
ENDTEXT
...


MENU.LST - PARTED MAGIC

title TEST 1 --- Parted Magic via ISOfind --set-root --ignore-floppies /img-iso/pmagic.isomap /img-iso/pmagic.iso (hd32)map --hookkernel (hd32)/pmagic/bzImageinitrd (hd32)/pmagic/initrd root=/dev/ram0 init=linuxrc keymap=uk livecd vga=normal sleep=0 acpi=off noapic nolapic nopcmcia noscsi nogpm consoleboot nosmart ramdisk_size=250000rootnoverifyboot

MENU.LST - CLONEZILLA

title TEST 2 --- Clonezilla via ISOfind --set-root --ignore-floppies /img-iso/clonzlla.isomap /img-iso/clonzlla.iso (hd32)map --hookkernel (hd32)/live/vmlinuz1initrd (hd32)/live/initrd1.img boot=live union=aufs  hostname=hardy  acpi=off irqpoll noapic noapm nodma nomce nolapic nosmp ip=frommedia vga=normalrootnoverifyboot

RESULT - PARTED MAGIC
File found and mapped
Kernel = [Linux-bzImage, setup=0x2800, size=0x1dc910]
Initrd = [Linux-initrd @ 0x1f407000, 0xbe5d9d bytes]
Decompressing Linux
...
RAMDISK: Compressed image found at block 0
RAMDISK: Incomplete write (-28 !=32768) 4194304
VFS: Cannot open root device "<NULL>" or unknown-block (8,8)
Please append the correct "root=" boot option; here are the available partitions:
Kernel panic - not syncing :
VFS: unable to mount root fs on unknown-block (8,8)
Stalls at this point


RESULT - CLONZILLA
File found and mapped
Kernel = [Linux-bzImage, setup=0x2a00, size=0x1ce278]
Initrd = Linux-initrd @ 0x1f71f000, 0x8cdc53 bytes]
Decompressing Linux
...
sda: sda1
sd 1:0:0:0: [sda] Attached SCSI disk
hda: max request size: 128KiB
hda: 8405775 sectors (4303MB) x/512KiB cache, CHS: 8195/15/63
hda: cache flushes not supported
hda: <5>sdf 1:0:0: Attached SCSI generic sg0 type 0
hda1 hda2 < hda5 >
hdb ATAPI 40X CD-ROM CD-R/RW drive 2048kB cache
Uniform CD-ROM driver revision 3.20
sd 1:0:0:0 Attached SCSI generic sg0 type 0
long pause at this point
DONE
Check root= bootarg cat /proc/cmdline
or missing modules, devices: cat /proc/modules ls /dev
Reading all physical Volumes. This may take a while...
ALERT! does not exist. Dropping to shell!
(initramfs)

[tinybit]

Parameters should be placed in the kernel line, not in the initrd line. Try with this:

title TEST 1 --- Parted Magic via ISO

find --set-root --ignore-floppies /img-iso/pmagic.iso

map /img-iso/pmagic.iso (hd32)

map --hook

kernel (hd32)/pmagic/bzImage root=/dev/ram0 init=linuxrc keymap=uk livecd vga=normal sleep=0 acpi=off noapic nolapic nopcmcia noscsi nogpm consoleboot nosmart ramdisk_size=250000

initrd (hd32)/pmagic/initrd

boot



title TEST 2 --- Clonezilla via ISO

find --set-root --ignore-floppies /img-iso/clonzlla.iso

map /img-iso/clonzlla.iso (hd32)

map --hook

kernel (hd32)/live/vmlinuz1 boot=live union=aufs hostname=hardy acpi=off irqpoll noapic noapm nodma nomce nolapic nosmp ip=frommedia vga=normal

initrd (hd32)/live/initrd1.img

boot

[SamK]

Parameters should be placed in the kernel line, not in the initrd line. Try with this:

title TEST 1 --- Parted Magic via ISO

find --set-root --ignore-floppies /img-iso/pmagic.iso

map /img-iso/pmagic.iso (hd32)

map --hook

kernel (hd32)/pmagic/bzImage root=/dev/ram0 init=linuxrc keymap=uk livecd vga=normal sleep=0 acpi=off noapic nolapic nopcmcia noscsi nogpm consoleboot nosmart ramdisk_size=250000

initrd (hd32)/pmagic/initrd

boot



title TEST 2 --- Clonezilla via ISO

find --set-root --ignore-floppies /img-iso/clonzlla.iso

map /img-iso/clonzlla.iso (hd32)

map --hook

kernel (hd32)/live/vmlinuz1 boot=live union=aufs hostname=hardy acpi=off irqpoll noapic noapm nodma nomce nolapic nosmp ip=frommedia vga=normal

initrd (hd32)/live/initrd1.img

boot

Thanks for the guidance, tinybit.

RESULT - PARTED MAGIC
Boot starts normally
Decompressing Linux
...
Oops couldn't find the live media

fails to command line interface - root@PartedMagic
does not provide access to directories with suffix "@"

• etc@
• home@
• linuxrc@
• media@
• mnt@
• opt@
• root@
• tmp@
• var@

RESULT - CLONZILLA
Boot starts normally
Decompressing Linux
...
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
end_request: I/O error, dev fd0, sector 0
At this point the preceding 3 lines are repeated many times
(initramfs)

[tinybit]

I see. Grub4dos worked fine by now, and no problems encountered(as far as grub4dos is concerned).

Oops couldn't find the live media

At this point the preceding 3 lines are repeated many times
(initramfs)

You may fix it by means of Linux shell programming and such. You need do some work to improve the ISO and let it boot just as what you expected.

[SamK]

I see. Grub4dos worked fine by now, and no problems encountered(as far as grub4dos is concerned).




You may fix it by means of Linux shell programming and such. You need do some work to improve the ISO and let it boot just as what you expected.

I find these conclusions slightly confusing. The applications work well if they are booted from CD-ROM burned from the downloaded ISOs using the in-built isoliunx. No errors are encountered during the boot process. When the boot has completed the applications can be used as expected.

When booting the downloaded ISOs directly using Grub4DOS the errors are encountered. The applications do not start correctly and are unusable.

In both of the above examples, the start parameters used during the boot process are identical. The only difference seems to be the use of Grub4DOS in preference to isolinux.

[was_jaclaz]

Cd emulation of a .iso image is something very "experimental".
Grub4dos gives "generic" support to access .iso images, other LiveCD Linux distributions work perfectly.
It's generally a "hit and miss" game, , where you might need to modify both the menu.lst and the "linux" part.

Another thing you can try:

title TEST 1 --- Parted Magic via ISO

find --set-root --ignore-floppies /img-iso/pmagic.iso

map /img-iso/pmagic.iso (hd32)

map --hook

root (hd32)

chainloader --force /boot/isolinux/isolinux.bin

boot

This is an intermediate way, where you bypass the bootsector but use isolinux.bin as loader.

But cannot say if it would work.

jaclaz

[SamK]

Cd emulation of a .iso image is something very "experimental".
Grub4dos gives "generic" support to access .iso images, other LiveCD Linux distributions work perfectly.
It's generally a "hit and miss" game, :(, where you might need to modify both the menu.lst and the "linux" part.

Another thing you can try:

title TEST 1 --- Parted Magic via ISO

find --set-root --ignore-floppies /img-iso/pmagic.iso

map /img-iso/pmagic.iso (hd32)

map --hook

root (hd32)

chainloader --force /boot/isolinux/isolinux.bin

boot

This is an intermediate way, where you bypass the bootsector but use isolinux.bin as loader.

But cannot say if it would work. :unsure:


jaclaz

Jaclaz, thanks for the additional suggestion. Are you able to clarify this a little bit more? Is a directory structure /boot/isolinux required in addition to the existing directories on the CD-ROM (rather than attempting to use the isolinux within the ISO)?

@tinybit and @jaclaz
To clarify my earlier comment regarding confusion -
This was meant as an observation rather than a criticism. The comment from tinybit -

Grub4dos worked fine by now, and no problems encountered(as far as grub4dos is concerned).

- could be interpreted to mean that the problem does not relate to Grub4DOS. Indicating that the results obtained thus far can lead to a different conclusion was given in the spirit of helping the project develop further.

[SamK]

...

title TEST 1 --- Parted Magic via ISO

find --set-root --ignore-floppies /img-iso/pmagic.iso

map /img-iso/pmagic.iso (hd32)

map --hook

root (hd32)

chainloader --force /boot/isolinux/isolinux.bin

boot

...

jaclaz

Unfortunately, this was unsuccessful.

[SamK]

PARTED MAGIC
After a little bit of inspiration (followed by a lot of perspiration) the problem as far a Parted Magic is concerned is now closer.

The downloaded ISO contains a volume label which is created on the CD-ROM during burning. This volume label is critical to completing a successful boot and load of the application.

It appears that the volume label is used to identify the 'live media'. If it is not available, the message 'Oops couldn't find the live media' is received. Once established a fixed path to files required to complete the boot/load process is referenced.

This was verified by:

• Extracting all the files from the ISO
• Deleting from the root of the extracted ISO isolinux.cfg, syslinux.cfg, sample_pxelinux.cfg
• Placing the the remaining directory at the root of iso_root
• Creating the ISO with the same volume label as that contained in the downloaded ISO
• Booting via Grub4DOS using the kernel and initrd directives

RESULT
Parted Magic is available for use as expected.

In order to boot the ISO directly it needs to be fed a parameter which would allow it to identify the ISO as having the required volume label and thereby complete the boot/loading. Does Grub4DOS have this ability?


CLONEZILLA
A similar process to that listed above has been tried without success. It appears that volume label may not be critical at this time.

The same results are obtained when attempting to boot either the extracted ISO or the ISO directly. These results have already been posted earlier today. Booting from a CD-ROM burned from the downloaded ISO is successful. Using exactly the same parameters to boot the direct ISO or extracted ISO fails when using Grub4DOS.

[was_jaclaz]

@SamK
No, I just "imagined" a possible directory structure, you need to try adjusting the paths to where actually isolinux.bin is in the actual .iso.

Mapping a CDFS filesystem to a virtual hard disk may imply losing some information, possibly the "label" you mentioned.

You'll have to wait for tinybit or windrv to get an accurate reply about how it would be possible to "pass" the "label" parameter.

Since moving the files to the root of the .iso worked, you can try using the full path for the root directive, something like (again a guess from me):

root (hd32)/pmagic

Maybe you can, instead of using the .iso approach, try a "more conventional" .img one, where you try to boot an image file of a "Parted Magic LiveUSB".

The "source" being already a "hd-like" format, it may give a more accurate "translation".

jaclaz

[ilko]

As far as I got it while playing with booting from USB disks using grub4dos you can boot only ISOs, which don't contain boot managers like ISOLINUX, BCDW...I beleive booting form CD won't differ much.
Successfully tested Acronis recovery media, Paragon recovery media, Norton Ghost v11 and similar.

Even if you pass kernel and initrd parameters to the kernel inside the emulated ISO, if kernel needs to access other files like filesystem.squashfs for GParted, it won't find them, as after it is loaded, they no longer will be accessible because kernel doesn't know about this emulation. In short- if it's Linux and needs only kernel(vmlinuz..) and initrd(initrd1.img, ramdisk.dat...) you should be able to boot it. Open the ISO and look inside which are the biggest files.

If not- solution is to extract contents of the ISOs keeping directory structure, folders isolinux and syslinux don't copy unless initrd and kernel are there, and "convert" ISOLINUX.CFG menus, to grub4dos ones. This is simple-
GParted ISO, part of isolinux.cfg:

label GParted Live
MENU DEFAULT
# MENU HIDE
MENU LABEL GParted Live (Default settings)
# MENU PASSWD
kernel /live/vmlinuz1
append initrd=/live/initrd1.img boot=live username=casper noswap vga=788 ip=frommedia
...

label GParted Live (To RAM)
# MENU DEFAULT
# MENU HIDE
MENU LABEL GParted Live (To RAM. Boot media can be removed later)
# MENU PASSWD
kernel /live/vmlinuz1
append initrd=/live/initrd1.img boot=live username=casper noswap vga=788 toram ip=frommedia
...

menu.lst:

title GParted Live (Default settings)
kernel /live/vmlinuz1 boot=live username=casper noswap vga=788 ip=frommedia
initrd /live/initrd1.img

title GParted Live (To RAM. Boot media can be removed later)
kernel /live/vmlinuz1 boot=live username=casper noswap vga=788 toram ip=frommedia
initrd=/live/initrd1.img

PMagic isolinux.cfg:

LABEL normal
MENU LABEL ^1. Default settings (Runs from RAM / Ejects CD)
...
KERNEL /pmagic/bzImage
APPEND noapic initrd=/pmagic/initrd root=/dev/ram0 init=/linuxrc ramdisk_size=200000 pmodules=/pmagic/pmodules squashfs=/pmagic/pmagic keymap=us livecd vga=791 quiet toram

menu.lst:

title normal
kernel /pmagic/bzImage noapic root=/dev/ram0 init=/linuxrc ramdisk_size=200000 pmodules=/pmagic/pmodules squashfs=/pmagic/pmagic keymap=us liveusb vga=791 quiet toram
initrd /pmagic/initrd

This is working from USB disk. liveusb should be livecd if booting from CD. Root is set already where grldr was called from. Is that right, or where menu.lst was read from?

There was some limitation if I remember correctly- grub4dos can pass kernel parameters up to a certain size. Don't remember exactly how many characters were allowed, and this may be fixed in newer versions, or I could be wrong.

Hope that messy post helps.

edit:

label Clonezilla live
kernel /casper/vmlinuz1 boot=casper username=casper hostname=debian vga=788 ip=frommedia
initrd /casper/initrd1.img

works just fine from USB stick, should work from CD too. Extracted from ISO folders casper, etc, pkg and ocs-live.d.

[tinybit]

@SamK

could be interpreted to mean that the problem does not relate to Grub4DOS.

Yes, or at least roughly speaking Yes.

Indicating that the results obtained thus far can lead to a different conclusion was given in the spirit of helping the project develop further.

I beg your pardon. My English is very bad. I can not understand you these words, even with the help of Google Translation. It seems that there are grammatical mistakes.

The applications work well if they are booted from CD-ROM burned from the downloaded ISOs using the in-built isoliunx. No errors are encountered during the boot process. When the boot has completed the applications can be used as expected.

When booting the downloaded ISOs directly using Grub4DOS the errors are encountered. The applications do not start correctly and are unusable.

In both of the above examples, the start parameters used during the boot process are identical. The only difference seems to be the use of Grub4DOS in preference to isolinux.

The difference is on cdrom simulation. The simulation uses BIOS to access data(sectors) on the virtual cdrom. BIOS has a history of several decades and it is a widely used industry standard. BIOS is provided by the ROM board and it is up after the Power-On-Self-Test. But BIOS works in real-mode of the CPU, whereas Linux works in protected-mode of the CPU. So after Linux kernel gains control, BIOS will no longer work, and thus the virtual cdrom will not be accessible. And this is why the problems would occur. Indeed there are solutions to this problem, i.e., from the Linux side. If from the Linux side you can find the real media and mount the ISO instead of trying to access the virtual cdrom through BIOS, then that will do. So what you need to do is just edit some scripts and let the files in the ISO be accessed. Thus the applications would work as expected.

In order to boot the ISO directly it needs to be fed a parameter which would allow it to identify the ISO as having the required volume label and thereby complete the boot/loading. Does Grub4DOS have this ability?

No, unfortunately. And I think this is not the right way, or say, in a wrong direction, and it could hardly lead to a success. You might have to modify some shell scripts from the Linux side, as mentioned above. Similar situation for CLONEZILLA, the easiest way from my point of view is still to modify the Linux scripts and mount ISO more intelligently.

[SamK]

@jaclaz

Maybe you can, instead of using the .iso approach, try a "more conventional" .img one, where you try to boot an image file of a "Parted Magic LiveUSB".

The "source" being already a "hd-like" format, it may give a more accurate "translation"

This may prove a more successful approach at this time. From the perspective of an end user, it is not as appealing as directly booting an ISO. To an end user, the latter is potentially more 'universal' and requires less effort to implement and maintain.

Are you able to recommend suitable applications to produce the *.img files? For preference open source or freeware.



@ilko
Thanks for your input ilko.

As far as I got it while playing with booting from USB disks using grub4dos you can boot only ISOs, which don't contain boot managers like ISOLINUX, BCDW...I beleive booting form CD won't differ much.
Successfully tested Acronis recovery media, Paragon recovery media, Norton Ghost v11 and similar.

Did any of your tests include extracting the boot image from bootable (isolinux) CD-ROM's and attempting to boot using Grub4DOS and the extracted boot-image file?

...solution is to extract contents of the ISOs keeping directory structure, folders isolinux and syslinux don't copy unless initrd and kernel are there, and "convert" ISOLINUX.CFG menus, to grub4dos ones...

If I understand correctly this is very similar to the most recently posted test and results. Parted Magic worked using this method, but required the following:

• The bootable CD-ROM to have a specific volume label
• The Parted Magic root directory and files to be placed in specific locations on the bootable CD-ROM.

From the kernel directives you used, it appears that your results were obtained using an earlier version of Parted Magic than the version I am testing. The developer of Parted Magic has announced that the upcoming release of Parted Magic will be 3.0 and based on the version I am testing.

It seems that the results you obtained for Clonzilla are based on an earlier version than I am testing. The developer of Clonezilla has announced the upcomming version will be be based on Ubuntu. The parameters I used in testing were exactly the same as those used in isolinux.cfg for the new version. Booting via Grub4DOS failed as reported previously. Booting from a CD-ROM burned from the downloaded ISO worked correctly. Currently the reason for the different behavior is unknown.

There was some limitation if I remember correctly- grub4dos can pass kernel parameters up to a certain size. Don't remember exactly how many characters were allowed, and this may be fixed in newer versions, or I could be wrong.

From the reply given by tinybit it seems that providing the volume label cannot be done this way at present.



@tinybit

I beg your pardon. My English is very bad. I can not understand you these words, even with the help of Google Translation. It seems that there are grammatical mistakes.

Forgive my poor English. It was a clumsy attempt to say:

• The results obtatined were inconclusive
• The comments were intended to be constructive rather than destructive.

Indeed there are solutions to this problem, i.e., from the Linux side. If from the Linux side you can find the real media and mount the ISO instead of trying to access the virtual cdrom through BIOS, then that will do. So what you need to do is just edit some scripts and let the files in the ISO be accessed. Thus the applications would work as expected.
...
Similar situation for CLONEZILLA, the easiest way from my point of view is still to modify the Linux scripts and mount ISO more intelligently.

As mentioned in the above reply to jaclaz, many years of experience have led me to believe that the most appealing solutions incorporate:

• simplicity of use
• ease of implementation
• ease of maintenance/change
• repeatable in nature

The solutions you propose do not correlate well with these criteria.

The overal objective (mentioned in my opening post) is to attempt to unify existing multi-boot and single-boot CD-ROMs into a single CD-ROM using a single boot loader. Currently this can be almost fully achieved using isolinux/syslinux. The great advantage of Grub4DOS is its (developing) ability to boot ISOs directly. If this can be achieved without modifying the contents of each individual ISO it will be a large step towards Grub4DOS becoming the universal boot loader it is intended to be. Such a development will inevitably result in an increase in the adoption of Grub4DOS.

[tinybit]

The results obtained were inconclusive
The comments were intended to be constructive rather than destructive.

Thanks for the explanation. I just said I have had that feeling and only in my point of view. And according to your report, grub4dos (itself) did work fine, and all the results are not too unexpected(of course only in my feeling).

As mentioned in the above reply to jaclaz, many years of experience have led me to believe that the most appealing solutions incorporate:

* simplicity of use
* ease of implementation
* ease of maintenance/change
* repeatable in nature

The solutions you propose do not correlate well with these criteria.

The overal objective (mentioned in my opening post) is to attempt to unify existing multi-boot and single-boot CD-ROMs into a single CD-ROM using a single boot loader. Currently this can be almost fully achieved using isolinux/syslinux.

I suspect the reason why you would say so. It may be because you did not seriously consider a number of technical issues I have mentioned, especially the CPU mode switching and BIOS-based emulation. There is a huge technical barrier between real and protected mode programs. Before the great obstacle is overcome there can be no simple/easy solution.

The great advantage of Grub4DOS is its (developing) ability to boot ISOs directly. If this can be achieved without modifying the contents of each individual ISO it will be a large step towards Grub4DOS becoming the universal boot loader it is intended to be. Such a development will inevitably result in an increase in the adoption of Grub4DOS.

In principle, we do have a possible way to overcome this great difficulty. But this needs for grub4dos to implement a full-system-emulation feature(just like QEMU), which is rather difficult at present. You may look at this discussion about "virtual machine for BIOS":

http://www.boot-land...?showtopic=4643

Before this full-system-emulation was done, we might have to do some modifications on our ISO and force it to work with BIOS-level emulation provided by grub4dos, or else we might have to give up(or say, surrender).

[SamK]

I suspect the reason why you would say so. It may be because you did not seriously consider a number of technical issues...

The items listed are general principles which I try to adopt when designing any solution or or system (IT or otherwise). They are to be seen as characteristics common to well designed solutions/systems. This is in no way intended to diminish the technical difficulties which may need to overcome in order that a simple/easy to use result is achieved.

I hope that "surrender" will not be required.

[was_jaclaz]

@jaclaz

This may prove a more successful approach at this time. From the perspective of an end user, it is not as appealing as directly booting an ISO. To an end user, the latter is potentially more 'universal' and requires less effort to implement and maintain.

Are you able to recommend suitable applications to produce the *.img files? For preference open source or freeware.

Under Windows 2K/XP/2003 (and I think Vista also ) you can use IMDISK or filedisk or VDK.EXE the first two by themselves or the last one with fsz.exe or mksparse or with Qemu-img.exe.

You might want to try the batch files you can find here:
http://www.boot-land...?showtopic=3191
using which it should be a breeze to create a suitable image.

Once you have tested that the .img works, creating a batch to create a fixed size image, formatting it and copying the needed files to it should be easy, using the afore mentioned batches as a guide, "simplifying" or stripping alltogether the interactive and calculatig part of them.

jaclaz

[ilko]

• The bootable CD-ROM to have a specific volume label
• The Parted Magic root directory and files to be placed in specific locations on the bootable CD-ROM.

...

I don't quite get the first one, are you talking about a volume label, like mentioned here?
http://www.msfn.org/...950#entry765950

If yes, could you point me to a distro, which uses the same for a CD boot? If it is just to pass to kernel where root is, there are alternatives.
If not, could you post details?

As for the second part- isn't it easy and supposed to be like this? Unless you want to customize the Linux startup scripts and locations yourself.

Sorry, I started losing what you wanted to achieve. Was it in short how to add various Linux distros to your multiboot CD/DVD, which uses grub4dos as boot manager?
ISO emulation in most cases won't work as explained already.
What bothers you adding them by extracting the contents, and calling kernels directly from grub4dos? It should be just matter of adjusting kernel parameters. Can you give me a download link, for the distro you couldn't make work?
Worst case scenario would be when 2 different distros use the same folders and files in them. Kernel and initrd can be renamed, the rest- some distros have a help file with list of kernel parameters, part of them are locations/names of these files/folders. If there is no such help file, may be asking in the relevant supporting forum would help.

[tinybit]

The items listed are general principles which I try to adopt when designing any solution or or system (IT or otherwise). They are to be seen as characteristics common to well designed solutions/systems. This is in no way intended to diminish the technical difficulties which may need to overcome in order that a simple/easy to use result is achieved.

Perhaps I should clarify what I just said. I really mean:

Before this full-system-emulation was done, the user might have to do some modifications on the ISO and force it to work with BIOS-level emulation provided by grub4dos, or else the user might have to give up(or say, surrender).

I hope someone can participate in the development and improvement of this technology. Users have to wait until the final realization of this goal. And we do not know when this technology can be achieved, it is uncertain. At present we even do not know who are able and willing to do this work.

I hope that "surrender" will not be required.

But wait is inevitable. In many cases, technology is not perfect. The user and the ISO maker have two choices: One is making maximum use of existing technologies of all kinds to solve specific problems(it is possible indeed, though it needs the ISO maker to do some extra work), and the other is sitting down and pending. Neither is costless. Both need someone(the user or the ISO maker) to pay the price.

[SamK]

@ilko

I don't quite get the first one, are you talking about a volume label, like mentioned here?
http://www.msfn.org/...950#entry765950

The volume label I am referring to is the name given to the CD-ROM while burning it. When creating an ISO using mkisofs it is referred to as the volid.

mkisofs -R -b grldr -no-emul-boot -boot-load-seg 0x1000 -volid "Volume Name" -o bootable.iso iso_root

This can be seen with the following commands:

Windows   vol [drive:]Linux     vol_id --label [device]

As for the second part- isn't it easy and supposed to be like this? Unless you want to customize the Linux startup scripts and locations yourself.

The comment is related to Parted Magic. It insists upon compliance with the following:

• The multiboot CD-ROM volume label is "Parted Magic"
• The downloaded Parted Magic ISO is extracted to the root of the multiboot CD-ROM. It cannot be located anywhere else.

In addition, upon extracting the downloaded Parted Magic ISO it creates isolinux.cfg, syslinux.cfg, sample_pxelinux.cfg in the root of the multi-boot CD-ROM. Individually none of these are 'show stoppers'; in combination they are restrictive. They also represent a good example of requiring individual/unique treatment in order to run. Exploring the ability to boot/load an ISO directly is (in part) an attempt to obviate these (and potential future) difficulties. In short, it is exploring whether it is "supposed to be like this" or whether an alternative is available (such as the suggestion from jaclaz to use images rather than ISOs). One outcome of this approach might be to avoid (unwanted) customizing of "the Linux startup scripts and locations".

Sorry, I started losing what you wanted to achieve. Was it in short how to add various Linux distros to your multiboot CD/DVD, which uses grub4dos as boot manager?

The general objectives were outlined in my opening post as "The toolkit currently under construction is an attempt to unify a collection of multiboot and single boot CD-ROMs which variously use isolinux and BCDW into a single CD-ROM using only Grub4DOS. Ultimately booting only ISOs (no floppies)." Underlying the overall aim are the principles expressed to tinybit:

• simplicity of use
• ease of implementation
• ease of maintenance/change
• repeatable in nature

ISO emulation in most cases won't work as explained already.

The explanation by tinybit that Grub4DOS is developing but not yet sufficiently mature to meet my objectives signals the end of exploring this route, unless there is an alternative boot-loader which can work with ISOs. I am now considering the approach suggested by jaclaz of using images. The general objectives and underlying principles will remain as outlined previously.

What bothers you adding them by extracting the contents, and calling kernels directly from grub4dos? It should be just matter of adjusting kernel parameters. Can you give me a download link, for the distro you couldn't make work?

This was partly answered earlier in this post where you refer to "As for the second part-". In addition Clonezilla has proved difficult to load using this method. Calling the kernels directly also has the disadvantage of bypassing the isolinux inside the ISO and thereby potentially not starting as the developer intended. http://www.clonezill...ad/sourceforge/
Release: 20080511-hardy is the version I am testing as this about to be released as the next version.

[was_jaclaz]

@SamK

Yes, I can see exactly what your goal is.

But the point is that every Linux distro is somewhat "focused" on a certain way of booting, and this is not necessarily "universal", so, you will probably have to dirt your hands anyway on the Linux side, if it is possible at all to use grub4dos for this multi-iso kind of booting.

You may want to read this entire thread:
http://www.msfn.org/...-Us-t94398.html

And this one:
http://www.msfn.org/...ll-t116225.html

And this post:
http://www.msfn.org/...-....html&st=93

Maybe you could ask for help to kof94 or jotnar over at MSFN, they are the real experts on these matters on the "Linux side".



jaclaz

[SamK]

Yes, I can see exactly what your goal is.

Sometimes it is not easy to express one's ideas in simple and concise terms.

...every Linux distro is somewhat "focused" on a certain way of booting, and this is not necessarily "universal"...

Fully accepted - at the present stage of development of Grub4DOS. With a slight alteration in the objectives a very similar goal may reachable. This might be an acceptable result, given that I am not a developer and therefore can be of limited direct assistance to tinybit.

Each of the individual tools within the proposed toolkit are quite small in size; the largest is less than 100MB, the smallest is 1.44MB. The purpose of the toolkit is not to produce a 'full-blown' Linux distribution, but to combine a series of individual DOS and Linux utilities in a convenient form, in a repeatable and sustainable manner. Currently each of the tools that can be started via Grub4DOS are available in *.img form. Both Parted Magic and Clonezilla can be booted/loaded from a usb flash drive and therefore can also be created as bootable disk images. On the proviso that future additions to the toolkit are also able to be imaged, the desired repeatability is thereby achieved.

The objectives and principles might be altered as follows:
"The toolkit currently under construction is an attempt to unify a collection of multiboot and single boot CD-ROMs which variously use isolinux and BCDW into a single CD-ROM using only a single boot-loader. Booting only disk images (no ISOs)." Underlying the overall aim are the principles:

• simplicity of use
• ease of implementation
• ease of maintenance/change
• repeatable in nature

This would not obtain a position of no input from the end-user, (I have no objection to getting my hands dirty) but does appear to minimize the input and produce common/repeatable steps.

Do you have a view on my suggestion?
Is it an over-simplification?
What are the disadvantages of the suggested approach?
Can isolinux/syslinux be started from within images by Grub4DOS?
Is Grub4DOS the most suitable boot-loader for this?
Are there any hidden traps when combining FreeDOS, Linux, Windows (BartPE XP) in this way?
etc.

[was_jaclaz]

Do you have a view on my suggestion?

Everything is clear and all right , but you appear to still be missing this point :
UNLESS the maker of the distro made it in such a way that it is ALREADY bootable from inside a .img or a .iso, it WILL NOT work "as is" in such a format through grub4dos or ANY OTHER bootloader.
If the distro does not work "as is" (whether from .iso or .img) it NEEDS to be modified on the "Linux side", there is nothing, and I mean NOTHING that can be done on the "grub4dos" (or ANY other bootmanager) to correct this situation.

The alternative is to "unpack" the contents as detailed in the referenced posts on MSFN.

Using .img files instead of .iso is simply an easier method to make the edits:
on .img:
1) try editing something
2) try booting the edited version
3) if it does not work loop to 1)

on .iso:
1) try editing something on extracted contents of the .iso (change Read Only attributes first)
2) re-build the .iso
3) try booting the edited version
4) if it does not work delete latest .iso and loop to 1)

Is it an over-simplification?

NO.

What are the disadvantages of the suggested approach?

As said that you need to "adapt" what does not work "as is".

Can isolinux/syslinux be started from within images by Grub4DOS?

YES, the point is not isolinux/syslinux, you already have seen that they can be started, but the problem is the Linux distro or minidistro.
Actually the real problem is that due to the frequence with which new releases of Linux based distros/tools are generally released, often with deep changes in their structure, as soon as you will have found the way to "adapt" the distro and written a batch to repeat the mods automatically, probably a new release with files with different names, or in different positions, or different "cheatcodes" or alltogether different mounting approach will have been made available, making your effort obsolete.

Is Grub4DOS the most suitable boot-loader for this?

YES, as long as we're talking about the "DOS/Windows/Vista" side.
NO, if we are talking about the "Linux" one.
However, is the only one that has such extended mapping options.

Finally, something that you may still want to try is the "hmload" approach, do read the Readme_grub4dos.txt and this:
http://sysdocs.stu.q...ent/GrubForDOS/

jaclaz