Jump to content











Photo
- - - - -

Multiboot CD-ROM via Grub4DOS


  • Please log in to reply
120 replies to this topic

#26 ilko

ilko

    Silver Member

  • Advanced user
  • 500 posts
  •  
    Bulgaria

Posted 15 June 2008 - 06:49 PM

@ilko


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....

Good, I thought this volume name is passed to kernel and you had that in mind, that's why I gave the link to msfn topic. I guess I should know how to get the volume name ;)



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.

About the first- it worked without specific label from USB disk, using 2.2 version. Haven't tried for CD yet.
Second- it might be possible, location of the files is passed as kernel parameters. May be a little play with that could lead to a solution.

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.

Downloaded it and extracted to USB disk, transferred the kernel parameters to menu.lst. In QEMU it fails, but on real machine it loads just fine. There is a little delay where it sits on a black screen seemingly doing nothing, I guess it's loading filesystem.squashfs. After a minute or so everything is loaded. From a CD this could be slower. Haven't tested it on CD yet, but I'd like to prove you wrong :thumbup:

Tynibit and Jaclaz mentioned about more "inteligent" distributions. I'll give you an example- Debian install from HD-like media.
On the disk you place only initrd and the kernel, wherever you like as you can change path to them in menu.lst. Since it's only these 2 files, they could be on a mapped ISO, IMG- doesn't matter. Next step is to place the actual netinstall.iso in root of disk, containing the packages and other stuff for the installer. When kernel is loaded, it seeks for the ISO, mounts it and uses it.
If more "live" distros are using the same approach, you can imagine how your goal would be easily accomplished.
When more and more people require this functionality, I guess developers would start implementing it. Shouldn't be a big deal to make their live distro work the same way, but for now that's what we got.

#27 SamK

SamK

    Member

  • Members
  • 44 posts

Posted 16 June 2008 - 11:01 AM

@ilko

About the first- it worked without specific label from USB disk, using 2.2 version. Haven't tried for CD yet.

This was part of the reason for the possible use of images rather than ISOs. It is unlikely that they will use a specific volume label.

For info I have a fully working multi-boot CD-ROM which incorporates an ISO based version of Parted Magic 2.10, booting via BCDW.


Downloaded it [CLONEZILLA] and extracted to USB disk, transferred the kernel parameters to menu.lst. In QEMU it fails, but on real machine it loads just fine.

All my tests are conducted using a real (physical) PC. As mentioned previously, a CD-ROM created directly from the downloaded ISO works perfectly. Booting an ISO or extracted ISO via Grub4DOS fails.


Haven't tested it on CD yet, but I'd like to prove you wrong

Any and all assistance will be welcomed.





@jaclaz

...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"...

To summarize my understanding of this;
  • Booting via CD-ROM requires CD-ROM simulation (virtual CD-ROM)
  • During bootup the virtual CD-ROM is accessed via the BIOS
  • The BIOS works in real mode
  • Linux works in protected mode
  • The transition from real mode to protected mode prevents access to the virtual CD-ROM via Linux
  • Any files held in the virtual CD-ROM that are required to complete the boot cannot be accessed
  • Boot fails to complete
  • The use of images in preference to ISO does not address this problem but may reduce difficulties such as the issue with Parted Magic ISO requiring a specific volume label.
Is this summary accurate?
Have I missed anything of significance?



...the "hmload" approach...

Checking the understanding here - outline of your suggestion
  • Create a disk image of the required tool
  • Boot the PC from CD-ROM using FreeDOS
  • During startup load memory managers himem.sys and emm386.exe to provide protected mode access
  • Load hmload.com + tool-disk.img
  • Load Grub.exe
  • Put the image in a ramdisk
  • Map the ramdisk as hd0
  • Start the kernel in mapped hd0
  • Initialize the the ramdisk in mapped hd0
  • Remove the mappings
  • Boot the tool
If this approach works using FreeDOS emm386.exe a reboot of the machine would be required to access another tool. If the Microsoft version of emm386.exe were used it seems it is possible to switch back to DOS without a reboot. Would this have the advantage of allowing another tool to be loaded by repeating the reloading of hmload.com + tool-disk.img, and grub.exe? If so is there an alternative to using the proprietary Microsoft version emm386.exe?

Is fdxms.sys required in preference to himem.sys?

Is there a benefit to using the Grub4DOS ramdisk rather than creating one in extended memory while starting FreeDOS?

Is it possible to restore the tool-disk.img directly to the FreeDOS ramdisk?

Can Grub4DOS start kernel and initrd if they are in a FreeDOS ramdisk and then conduct the boot?

Should these questions be asked of tinybit rather than you?

#28 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7100 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 16 June 2008 - 12:01 PM

To summarize my understanding of this;

  • Booting via CD-ROM requires CD-ROM simulation (virtual CD-ROM)
  • During bootup the virtual CD-ROM is accessed via the BIOS
  • The BIOS works in real mode
  • Linux works in protected mode
  • The transition from real mode to protected mode prevents access to the virtual CD-ROM via Linux
  • Any files held in the virtual CD-ROM that are required to complete the boot cannot be accessed
  • Boot fails to complete
  • The use of images in preference to ISO does not address this problem but may reduce difficulties such as the issue with Parted Magic ISO requiring a specific volume label.
Is this summary accurate?
Have I missed anything of significance?

Perfectly accurate :), the "unsaid" part is that with Linux it should be prolly easy to have the "real" mode part of the booting auto-mount the .img or .iso and thus continue booting using "protected mode" native drivers and accessing perfectly allright the files in the image.


Checking the understanding here - outline of your suggestion

  • Create a disk image of the required tool
  • Boot the PC from CD-ROM using FreeDOS
  • During startup load memory managers himem.sys and emm386.exe to provide protected mode access
  • Load hmload.com + tool-disk.img
  • Load Grub.exe
  • Put the image in a ramdisk
  • Map the ramdisk as hd0
  • Start the kernel in mapped hd0
  • Initialize the the ramdisk in mapped hd0
  • Remove the mappings
  • Boot the tool
If this approach works using FreeDOS emm386.exe a reboot of the machine would be required to access another tool. If the Microsoft version of emm386.exe were used it seems it is possible to switch back to DOS without a reboot. Would this have the advantage of allowing another tool to be loaded by repeating the reloading of hmload.com + tool-disk.img, and grub.exe? If so is there an alternative to using the proprietary Microsoft version emm386.exe?

Is fdxms.sys required in preference to himem.sys?

Is there a benefit to using the Grub4DOS ramdisk rather than creating one in extended memory while starting FreeDOS?

Is it possible to restore the tool-disk.img directly to the FreeDOS ramdisk?

Can Grub4DOS start kernel and initrd if they are in a FreeDOS ramdisk and then conduct the boot?

It seems to me you are making it far more complex than the original idea. :)

Since both Parted Magic and Clonezilla are pretty small sized, the idea is simply that of the original author of hmload.com, and detailed in "Update 2007-12-05" on the Readme_grub4dos.txt file.

You need himem.sys or equivalent high memory manager, I don't recall having used emm386.exe, but I may be wrong. (I did not try it with FreeDOS)

Cannot say if it can be unloaded by using mark.com:
http://www.boot-land...opic=2777&st=20
or another method.

You load the Linux image to RAM, then use grub4dos and Linux to mount that "segment" of RAM as a RAMDISK (there is no DOS or FreeDOS ramdisk or ramdisk driver, RAM is accessed directly from DOS, image is copied to it, then that part of RAM is accessed by Linux only as a Ramdisk)

The "important" parameter is the:

root=/dev/ram0


I just noticed, rechecking the link, that on:
http://sysdocs.stu.q...ent/GrubForDOS/
there is a new utility, xmsel which I have not tested, but that seems not to work with 0.4.3.

I remember testing the feature with grub4dos 0.4.2 and it worked if used as detailed in the readme.txt file of version 0.4.2.

For the disk image method, this page, referenced by the Author of hmload.com, details how Linux can access an image file through the loop device (courtesy of the Wayback Machine):
http://web.archive.o...ges Under Linux


Should these questions be asked of tinybit rather than you?

I guess that on a public forum questions are "publicly" asked, whoever feels like contributing is welcome :).

...and as I said before, all this is very near the border of currently available tools, VERY experimental, and a "hit and miss" game.... no definite answers yet :(, just ideas that need still LOTS:

of inspiration (followed by a lot of perspiration)

and LOTS of experiments....it is also possible that the "hmload.com" is a dead end...:)

:)

jaclaz

#29 SamK

SamK

    Member

  • Members
  • 44 posts

Posted 17 June 2008 - 06:45 AM

It seems to me you are making it far more complex than the original idea...

...load the Linux image to RAM, then use grub4dos and Linux to mount that "segment" of RAM as a RAMDISK (there is no DOS or FreeDOS ramdisk or ramdisk driver, RAM is accessed directly from DOS, image is copied to it, then that part of RAM is accessed by Linux only as a Ramdisk)

The references to using a FreeDOS ramdisk are musings prompted by recent work conducted with FreeDOS bootable floppy disk images. As a FreeDOS image is to be loaded to provide the wanted protected mode access, it is possibly simpler to create a ramdisk at this point rather than individully specifying it each time via Grub4DOS.

I agree that starting from a position that has been proven to work (hmload.com) is the best starting point, however might there be others worth exploring?

Musings...
Is Grub4DOS able to work with a ramdisk created by another package? If so which Grub4DOS commands are used to reference a 3rd party ramdisk and what is the correct syntax?

#30 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7100 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 17 June 2008 - 07:51 AM

I'll shock you with a revelation :):
RAMDISKs DO NOT EXIST:
http://www.boot-land...opic=2692&st=26
:)


RAM exists, DATA loaded in RAM at a given address may exist, a Ramdisk is actually a Ramdisk driver, i.e. just a method to access the data (if any) in RAM at a given address (and for a given extension), and "treat" it as a mounted filesystem.

So, you can load the data into RAM using XMSDSK, find WHERE it is, then access it through the grub4dos rd device.

But still cannot see the need for introducing this further level of complexity. :)

jaclaz

#31 SamK

SamK

    Member

  • Members
  • 44 posts

Posted 17 June 2008 - 04:55 PM

But still cannot see the need for introducing this further level of complexity.

I may have missed something here as I find the Grub4DOS documents difficult to work with; hence the continuing questions. I foresee two potential advantages but am not yet certain either of them is wanted or needed.
  • Creating a usable area in RAM can occur at two points:
    • When starting FreeDOS
      Each time a tool is started via Grub4DOS commands
    The former may be preferable if the ramdisk can be re-used and is specified only once. The latter has the advantage of having been shown to work, but must be specified multiple times.

  • If the creation of the ramdisk can be automated by incorporating it in the startup procedure it is slightly closer to "simplicity of use".

Can a disk.img (or ISO) be copied by Grub4DOS from a file on CD-ROM directly to a pre-created ramdisk and then booted? If so could you point to (or provide) example commands?

How does one find a ramdisk in Grub4DOS?

#32 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7100 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 18 June 2008 - 09:50 AM

The ramdisk of grub4dos is the rd device.

In grub4dos command line simply type:
find (
and press [TAB] key
you will get back something like:

fd hd0 cd rd


the rd is at this moment in an "undefined" state, i.e. has NOT a starting address in RAM and has NOT an extension (size) set and, of course it is "empty".

You then need to assign it these values and "hook" it.

Grub4dos has not the capacity to directly copy anything to the rd, hence the need for hmload.com (or a similar utility).

What I did some time ago was this test (on a VM):
1) have a hard disk booting grub4dos grldr containing a linux disk .img and a win98SE floppy .ima
2) chainload from grub4dos the floppy .ima and boot from it
3) have in the .ima, besided DOS 7.1 system files, hmload.com and grub.exe with a menu.lst
4) have in the .ima an autoexec.bat that would:
a. use hmload.com to copy the .img to a determined address in RAM
b. load grub.exe with a --config-file directive to load the menu.lst on floppy
c. in the menu.lst have the commands mapping the rd to the area in RAM where data was copied and boot from rd

jaclaz

#33 SamK

SamK

    Member

  • Members
  • 44 posts

Posted 18 June 2008 - 02:48 PM

What I did some time ago was this test (on a VM):
1) have a hard disk booting grub4dos grldr containing a linux disk .img and a win98SE floppy .ima
2) chainload from grub4dos the floppy .ima and boot from it
3) have in the .ima, besided DOS 7.1 system files, hmload.com and grub.exe with a menu.lst
4) have in the .ima an autoexec.bat that would:
a. use hmload.com to copy the .img to a determined address in RAM
b. load grub.exe with a --config-file directive to load the menu.lst on floppy
c. in the menu.lst have the commands mapping the rd to the area in RAM where data was copied and boot from rd

I understand how your test was constructed. It has the merit of using a single Grub4DOS menu to provide a list of available options, but the configuration files within nested images does not allow for "ease of maintenance/change".

My initial thought was to explore alternatives to nested images, but this has its own disadvantages. My approach has been based on booting the PC to a FreeDOS environment and selecting options from a user created (non-grub4DOS) menu. The result of the choice places the selected tool-disk.img into a ramdisk and Grub.exe is then used to conduct the mapping and booting. The advantage is potentially easier maintenance/change at the expense of a needing a non Grub4DOS/Grub.exe menu to be created.

Is there a way of adopting the desirable aspects of these two approaches?

When running in a FreeDOS environment is grub.exe able to conduct any DOS based tasks within the DOS environment? An example might be running a *.bat file as part of the process started when invoking a menu choice from Grub4DOS/Grub.exe? I suspect this is not the case but am, of course, unaware whether this may have been considered and discarded by tinybit at some earlier stage of the development of the Grub4DOS project.

#34 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7100 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 18 June 2008 - 04:35 PM

Well, essentially, if you change my post to:
1) have a hard disk booting grub4dos grldr containing a linux disk .img several disk images .img and a win98SE floppy .ima
2) chainload from grub4dos the floppy .ima and boot from it
3) have in the .ima, besided DOS 7.1 system files, hmload.com and grub.exe with a menu.lst
4) have in the .ima an autoexec.bat that would:
a. have the possibility to choose between several disk images
b. use hmload.com to copy the chosen .img to a determined address in RAM
c. create a menu.lst with the appropriate rd options then load grub.exe with a --config-file directive to load the menu.lst on floppy, or even more simply invoke grub4dos grub.exe with the --config-file directive and the proper parameters for the chosen image


I guess that the two "ways" become pretty much the same. :)

The menu.lst (or equivalent parameters) are thus created on-the-fly, by the same batch that lets you choose which image you want to load to rd and boot, so the only thing that may need editing is the "menu" in the batch file.

The only doubt :) I have is whether this is entirely supported by FreeDOS, at the time of the experiments described there were problems in re-loading grub.exe from FreeDOS, but since a long time has passed, it is well possible that the conflicts where solved, or are however solvable, one way or the other (I did not spend much time playing with loading/unloading of TSRs/drivers) DOS 7.1 worked for me and I left it there. :)

jaclaz

#35 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7100 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 18 June 2008 - 05:15 PM

I'm also having a problem with this. I am atempting to include AcronisMedia.iso but am getting an error.


The Acronis .iso WORKS as detailed here:
http://www.boot-land...?showtopic=4708

I am moving your post to there, to keep things as together as possible.

jaclaz

#36 darkman738

darkman738

    Frequent Member

  • Advanced user
  • 134 posts
  • Location:MA, US
  •  
    United States

Posted 18 June 2008 - 05:35 PM

The Acronis .iso WORKS as detailed here:
http://www.boot-land...?showtopic=4708

I am moving your post to there, to keep things as together as possible.

jaclaz

The reason I posted here is because I am having problems confiugring an ISO to boot with grub4dos. The fact that it is Acronis is purely coincidental. The final solutions are plugins that work within the PE. I am not looking for this solution, I am looking for a way to boot directly into my image. I am looking for some help defining if I need to changed my image, convert it to something more supported or simply change the way my menu.list is configured.

Thanks,
Frank

#37 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7100 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 18 June 2008 - 05:53 PM

The reason I posted here is because I am having problems confiugring an ISO to boot with grub4dos.
The fact that it is Acronis is purely coincidental. The final solutions are plugins that work within the PE. I am not looking for this solution, I am looking for a way to boot directly into my image. I am looking for some help defining if I need to changed my image, convert it to something more supported or simply change the way my menu.list is configured.


Yep, and the reason why I moved it there is because there you can get more specific help, while this thread is more "general" and may never come out with a solution to your problem.

On the other hand, if you are looking for a general solution, I guess that your only hope is to keep an eye open on this thread and wait when and if such a solution may be found.

Posting here making us know that you cannot boot a specific image may simply cause a hijacking of the thread.

I will repeat myself for the hmmmth time, there is NO one-size-fits-all solution for .iso images. (yet :))

There are a number of specific solutions, and an even greater number of specific .iso images for which there is not (yet :)) a known solution.

If you need "specific" help, you will hopefully have it in a "specific" thread.

jaclaz

#38 SamK

SamK

    Member

  • Members
  • 44 posts

Posted 18 June 2008 - 06:02 PM

The only doubt I have is whether this is entirely supported by FreeDOS, at the time of the experiments described there were problems in re-loading grub.exe from FreeDOS...

Behind our correspondence I have been testing a floppy disk image based on the last full release of FreeDOS. The design is specifically aimed at use with Grub4DOS booting images in ramdisk. I quickly encountered the problem you describe. It is also mentioned in The Grub4DOS readme.txt which suggests a possible workaround of using Microsoft emm386.exe in place of FreeDOS emm386.exe. If possible I would prefer to use non-proprietary software in pursuing this matter. Further experiments and tests were conducted with umbpci.sys which seems to work reliably and as a direct replacement for emm386.exe.


Well, essentially, if you change my post to:
1) have a hard disk booting grub4dos grldr containing a linux disk .img several disk images .img and a win98SE floppy .ima
2) chainload from grub4dos the floppy .ima and boot from it
3) have in the .ima, besided DOS 7.1 system files, hmload.com and grub.exe with a menu.lst
4) have in the .ima an autoexec.bat that would:
a. have the possibility to choose between several disk images
b. use hmload.com to copy the chosen .img to a determined address in RAM
c. create a menu.lst with the appropriate rd options then load grub.exe with a --config-file directive to load the menu.lst on floppy, or even more simply invoke grub4dos grub.exe with the --config-file directive and the proper parameters for the chosen image

I guess that the two "ways" become pretty much the same.

The menu.lst (or equivalent parameters) are thus created on-the-fly, by the same batch that lets you choose which image you want to load to rd and boot, so the only thing that may need editing is the "menu" in the batch file.

My original idea was to use only the official Grub4DOS menu (avoiding the need for an alternative) but I cannot see the solution to this yet; hence my question about Grub.exe being able to conduct DOS tasks in a FreeDOS environment.

#39 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7100 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 18 June 2008 - 07:59 PM

My original idea was to use only the official Grub4DOS menu (avoiding the need for an alternative) but I cannot see the solution to this yet; hence my question about Grub.exe being able to conduct DOS tasks in a FreeDOS environment.



Though of course tinybit might reply you more properly, maybe I can clear up this point:
at the moment grub4dos must be considered as a (small and limited) self-contained Operating System with it's own (internal) commands and NO possibility to execute "external" ones.
So NO way to execute DOS "tasks" or programs yet, nor in the immediately foreseeable future. :)

jacaz

#40 SamK

SamK

    Member

  • Members
  • 44 posts

Posted 19 June 2008 - 12:18 PM

Trying to use mkimg.cmd and think I might be missing something.

The following files are in a common directory:
09/02/2005 23:07:26 A----- 5,061 dsfi.exe
11/02/2005 12:51:14 A----- 6,637 dsfo.exe
16/03/2005 17:11:41 A----- 53,248 DumpHex.exe
19/06/2008 11:12:41 A----- 217 echoo.com
30/01/2005 14:44:12 A----- 6,144 fsz.exe
20/01/2008 21:18:16 A----- 19,968 gsar.exe
01/10/2007 20:29:52 A----- 33,065 mbrbatch.cmd
19/11/2007 16:11:22 A----- 14,394 mkimg.cmd (mkimg004.zip)
16/08/2002 18:52:04 A----- 24,576 mksparse.exe
06/04/2005 14:10:48 A----- 159,744 vdk.exe
10/11/2003 15:48:00 A----- 16,283 vdk.sys


Run mkimg.cmd and supply the following:
1) TEST.img = asks for a file name (for the moment use the same directory where the script and all utilities are)
2) 100M = asks for an image size in bytes, Kbytes, Mbytes or Gbytes
3) 16/63 = asks for the desired geometry
4) 06 = asks for the desired Partition (filesystem) type
5) default = asks whether you want to use the (default) mksparse.exe to create a sparse image or fsz.exe to create a full image
6) OK = creates the image
7) OK = autocalculates partition table entries to create the single biggest possible partition for given image size and creates a MBR with this data and 2K/XP MBR code
8) OK = copies this MBR to the image
9) OK = mounts the image with VDK and formats it using "standard" FORMAT
10)OK = opens with Explorer the freshly mounted Virtual Disk

RESULT
Files created:
TEST.$$$ - 512 Bytes
TEST.img - 100 MB
TEST.pln - 80 Bytes
TMPDATA.$$$ - 17 Bytes


Copy Clonezilla burned on CD-ROM to TEST.img with Explorer
RESULT
Copy conducted - no errors reported


Start IMDISK and mount TEST.img
RESULT
No errors reported - filesystem listed as N/A (not available)


Open mounted TEST.image with Explorer
RESULT
Error message - The disk is not formatted do you wish to format it now?


During the creation of TEST.img a quick format is performed. The image was mounted and able to have files copied to it so presumably it was formatted.

#41 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7100 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 19 June 2008 - 12:44 PM

Start IMDISK and mount TEST.img
RESULT
No errors reported - filesystem listed as N/A (not available)


Open mounted TEST.image with Explorer
RESULT
Error message - The disk is not formatted do you wish to format it now?


Everything is cool :) , it is by design :)

The image made is a HD one with MBR+hidden sectors.

If you mount it with VDK, you can use the .pln file INSTEAD of the .img one, but also mounting directly the .img will work (though with default 64/32 geometry).

If you mount it with IMDISK, you need to supply the OFFSET to bootsector (i.e. the MBR + hidden sectors) 63 sectors (or "blocks") in your case.

http://www.boot-land...?showtopic=3147
http://www.boot-land...?showtopic=2220

jaclaz

P.S.: if you need the .img file for use as a Ramdisk, you may as well use just fsz or mksparse to create the empty file, or even IMDISK directly, then mount the file with IMDISK open explorer and when it asks if you want to format it say yes, the resulting file will be a "partition" or "super-floppy" type of image, i.e. there is no MBR, nor hidden sectors and bootsector is first sector.

#42 SamK

SamK

    Member

  • Members
  • 44 posts

Posted 20 June 2008 - 12:30 PM

Feedback of Actions and Results

CLONEZILLA
Not tested


PARTED MAGIC
Downloaded USB version to avoid problem of volume label


IMAGE CREATION
Image created via mkimg as follows:
Size = 50MB
Geometry = 16/63
Type = 06
Image Name = pmagic.img
Image Size = 52428800 bytes


IMAGE POPULATING
Followed guide http://partedmagic.c...reatingTheMedia
Extracted Parted Magic download to root of image
Downloaded and extracted current version of Syslinux to root of image
Run syslinux.exe -maf [image_drive_letter:] (win32)
Verified creation of ldlinux.sys in root of image


CREATION OF ISO
iso_root

\grub4DOS

\all g4D files and subdirs

\images

\bootg4d.img (floppy)
\pmagic.img

\menu.lst
\gldr

mkisofs -R -b grldr -no-emul-boot -boot-load-seg 0x1000 -volid "XXX" -o bootable.iso iso_root
CD-ROM created using ImgBurn


BOOT UP PC
Normal boot using Grub4DOS and bootg4d.img
DOS access provided to CD-ROM


BOOT UP PMAGIC.IMG (Two methods shown)
Method 1

grub.exe
find --set-root /images/pmagic.img
map /images/pmagic.img (hd0) *
map --hook
chainloader (hd0)+1
boot ***

Method 2

hmload -f \images\pmagic.img -a 16
grub.exe
map --rd-base=0x1000000
map --rd-size=52428800
map (rd)+1 (hd0,0) *
map --hook
root (hd0,0) **
chainloader (hd0)+1
boot ***


RESULTS
In both cases isolinux starts as expected and displays the Parted Magic Welcome Page/Menu.
In both cases the Parted Magic menu option 'Safe Graphics' was selected (to view startup messages) supplying parameters:

kernel /pmagic/bzImage
append noapic initrd=/pmagic/initrd root=/dev/ram0 init=/linuxrc keymap=us liveusb vga=normal sleep=0 ramdisk_size=25000

Messages

* "Warning total-sectors calculated from partition table (102816) is greater than the number of sectors in the whole disk image (102400). The int13 handler will disable any read/write operations across the image boundary. This means you will not be able to read/write sectors (in the absolute address, i.e. lba) 102400-102815 though they are logically inside your emulated virtual disk (according to the partition table)."

** "Filesystem type is fat, partition type 0x6

*** (after loading is almost complete) "Oops couldn't find live media"


The results are consistent with those obtained from the previous tests of ISO and extracted ISO but do not advance the present position. I recall reports of inability to find the live media with earlier versions of Parted Magic. A message has been left in the Parted Magic forum asking the developer, Patrick Verner for an opinion.
http://partedmagic.c....php?f=11&t=151
Patrick is usually very helpful and might be able to indicate whether or not this matter is related to his design of Parted Magic.

Do you see any other scenarios worth testing?

#43 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7100 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 20 June 2008 - 05:16 PM

We are back to square#1, actually abit further, to square #14:
http://www.boot-land...opic=4902&st=13
and to square #25:
http://www.boot-land...opic=4902&st=24

You need to tell somehow to Parted Magic that it is running from a disk image or from a ramdisk.

For the "direct .img" method:
Chainloading the bootsector, or, even worse, the MBR, cannot work, as you just experimented, you need to either:
continue chainloading either of them AND change something in ISOLINUX settings
or:
chainload directly the linux kernel from grub4dos (bypassing completely ISOLINUX) WITH the appropriate parameters

I cannot say what these parameter are, but they should involve a loop mount of the image from Linux.

Wubi (the windows installer for Ubuntu) uses a "loop=disk_image" parameter:
http://www.boot-land...?showtopic=4303

For the hmload/rd test, you should use an image without MBR, unless I am mistaken :) /dev/ram0 is expected as "partition" or "super-floppy"

In other words, forget for the moment about multiboot, grub4dos and making .isos, (as tinybit and myself already told you, the grub4dos side works as expected) you have to find the right way to boot Parted Magic from a disk image - this ALL happens on the "Linux" side - once you have solved this part, adding it to the multiboot becomes the easy one.

jaclaz

#44 ilko

ilko

    Silver Member

  • Advanced user
  • 500 posts
  •  
    Bulgaria

Posted 20 June 2008 - 06:37 PM

SamK- if we put it in another way-
Kernel and initrd are loaded simultaneously, no matter form direct loading or from IMG/ISO mounting.

Now you are in protected mode. Linux kernel does NOT know about your mounted via grub4dos image, there are no drivers for it.
Next kernel has to access file(s) to be loaded or mounted- pmagic, filesystem.squashfs or whatever.
How would kernel find those files, since mapping no longer exist, where are they? When you answer yourself this question you will get the picture clear.

Solutions could be:
- build initrd so it includes all needed files which are used later, no idea if it's possible at all
- place file(s) to be loaded or mounted- pmagic, filesystem.squashfs or whatever is needed somewhere OUTSIDE the image and point the location as a kernel parameter. On some distros it is possible, however, support is needed from the developer. Remember about Debian install from HD.
Again- it doesn't make sense to have the image, because in it you can have ONLY initrd and kernel, which can be loaded from custom folders anyway. What does putting them in image gain you?
- have a driver, which tells Linux about grub4dos image mounting

As I see it the simplest solution is distro with 3 files, like the Debian install- kernel, initrd and it's own image which is mounted later by the kernel. Location of this image must not be hardcoded, but rather passed as a kernel parameter.
In this scenario you can have folders FEDORA8, GPARTED, PMAGIC22, PMAGIC21.... each containing 3 files- kernel, initrd and filesystem.squashfs or whatever it is. Pass the location to the latter as a kernel parameter. Problem solved.

#45 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7100 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 20 June 2008 - 06:45 PM

Again- it doesn't make sense to have the image, because in it you can have ONLY initrd and kernel, which can be loaded from custom folders anyway.


I have to disagree :).

How does WUBI work? :)

Everything BUT kernel and initrd is inside the image.

As I see it the simplest solution is distro with 3 files, like the Debian install- kernel, initrd and it's own image which is mounted later by the kernel. Location of this image must not be hardcoded, but rather passed as a kernel parameter.
In this scenario you can have folders FEDORA8, GPARTED, PMAGIC22, PMAGIC21.... each containing 3 files- kernel, initrd and filesystem.squashfs or whatever it is. Pass the location to the latter as a kernel parameter. Problem solved.


We then agree fully. :)

Question is why also kernel and initrd cannot be inside the image? :)

jaclaz

#46 ilko

ilko

    Silver Member

  • Advanced user
  • 500 posts
  •  
    Bulgaria

Posted 20 June 2008 - 07:05 PM

I have to disagree :).

How does WUBI work? :)

Everything BUT kernel and initrd is inside the image.

*Inside the image, which is loaded by the linux kernel.


Question is why also kernel and initrd cannot be inside the image? :)

Because that image is not loaded by the kernel. If Linux kernel and grub4dos load those images in a similar way and know about each other then may be...not my field to comment any further. Have to do some reading about 'squashfs'.

About the loop=... parameter- in some cases it fails if you change the image name.

Example- Gparted 0.3.4-8. There is gparted.dat in root and loop=/gparted.dat in menu.lst. This loads fine.

kernel /boot/gparted root=/dev/ram0 init=/linuxrc real_root=/dev/loop0 looptype=squashfs loop=/gparted.dat udev dokeymap scandelay=6 cdroot=/dev/hd dodmraid nosound

*bolded is changed for boot from hd.

Rename both to gparted1.dat. Boot fails when it needs that file, cannot find it.

kernel /boot/gparted root=/dev/ram0 init=/linuxrc real_root=/dev/loop0 looptype=squashfs loop=/gparted1.dat udev dokeymap scandelay=6 cdroot=/dev/hd dodmraid nosound



#47 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7100 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 21 June 2008 - 09:08 AM

We are slowly drifting away from our "main" field of competence and entering the "misterious" Linux world..... :) ...I guess it's time to start studying...:)


Most probably the "gparted.dat" is also hardcoded in some setting file within the gparted.dat image file. :)

OT:
I quickly checked the gparted site (version 0.3.6.7), and it seems like there is this Windows app, DBRL Helper:
http://gparted.sourc...net/liveusb.php
http://www.clonezill...ive-usb-helper/
(which is actually hosted on clonezilla site)
that can:

Format a USB flash drive
Install the image file
Make USB flash drive bootable



There is "live" version (to be put on HD) that uses this grub sintax:
title GParted live

root (hd0,3)

kernel /live/vmlinuz1 toram boot=live union=aufs noswap noprompt vga=788 ip=frommedia

initrd /live/initrd1.img

boot

the filesystem is however:
/live/filesystem.squashfs

this should mean that the latter name is hardcoded somewhere. :)

jaclaz

#48 SamK

SamK

    Member

  • Members
  • 44 posts

Posted 21 June 2008 - 12:54 PM

OT:
I quickly checked the gparted site (version 0.3.6.7), and it seems like there is this Windows app, DBRL Helper:
http://gparted.sourc...net/liveusb.php
http://www.clonezill...ive-usb-helper/
(which is actually hosted on clonezilla site)
that can:
Format a USB flash drive
Install the image file
Make USB flash drive bootable

I discovered this about a week ago on the Clonezilla site. It is a package to conduct the items mentioned under How to Make Clonezilla Live - "Choice 2 (Manually):"
See here http://www.clonezill...clonezilla-live

It uses the following:
  • Formatting utility with HP USB Disk Storage Format Tool
  • Unzip the image file with 7zip
  • Syslinux v3.62
Win32 syslinux.exe is used to mark the drive as bootable. Mentioned here under Method 1
http://partedmagic.c...reatingTheMedia


Which was used here http://www.boot-land...opic=4902&st=41

#49 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7100 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 21 June 2008 - 01:43 PM

Still OT:

It uses the following:

  • Formatting utility with HP USB Disk Storage Format Tool
  • Unzip the image file with 7zip
  • Syslinux v3.62


Damn :) I thought it was an alternative to the HP utility, not a wrapper around it. :)

I hope the good Linux guys understand that they are distributing a file that (surprise - surprise :)) embed also DOS 7.x system files.....:)
(try using 7-zip on HPUSBFW.EXE - open inside) :)


But, :(, on the other hand how can they fit around two Mb (or even the 436 Kbytes of HPUSBFW.EXE) in 204 Kb? :(

I had a look at the .exe and it seems like it downloads on-the-fly the HP utility from:
http://h50178.www5.h...550/SP27608.exe

Which is even worse, it means that the tool is useless if you are offline AND that as soon as HP will change, as it often does the file location, it will become TOTALLY useless.

I expected something more from those guys..... :(

IMHO a very, very sneaky way to save time instead writing an actual Open Source program with no strings attached. :(

jaclaz

#50 SamK

SamK

    Member

  • Members
  • 44 posts

Posted 22 June 2008 - 03:51 PM

@jaclaz/ilko

I have been corresponding with Patrick Verner, developer of Parted Magic. Patrick wants to produce an ISO version of his mini-distro that is directly bootable by Grub4DOS, as shown by the following extracts from my thread on his forum.

I'm interested in making Parted Magic boot in any truly useful manner...
Can you give me a quick run down on how to set-up grub4dos?...
I can make a "pmagic-grub4dos.iso" for 3.0 until the grub4dos project gets things rolling...
...This will give exposure to grub4dos and Parted Magic, so it's worth the trouble.


Your greater experience/knowledge of Grub4DOS will be greatly appreciated. Should you wish to provide any ideas to Patrick on this matter please add your advice to my existing thread at the Parted Magic forum.
See here http://partedmagic.c...9d57e94fa6#p663




1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users