120 replies to this topic

[was_jaclaz]

@SamK
Patrick Verner in his last post "on Sun Jun 22, 2008 5:41 pm" seems like having hit the nail right on the head.

I just posted a "hallo, peeps" there.

I'll watch the developing of the thread however, and if needed I will post there any suggestion I can come up with.



jaclaz

[SamK]

Firstly, many thanks to everyone that contributed to making it possible to boot Parted Magic directly from ISO. This feature will be included in the forthcoming release, v 3. The increased awareness this will bring to both Grub4DOS and Parted Magic can only be beneficial to both projects.

Secondly, on to the next tool to add; Clonezilla.

Extracting the ISO to the root of iso_root and loading the kernel via Grub4DOS results in Clonezilla starting as expected. It looks to load Clonezilla.iso/live/filesystem.squashfs. Extracting the ISO to any other directory than iso_root leads to the bootup failing (working assumption - it can no longer find filesystem.squashfs). Booting the ISO/img directly both fail, presumably because they are also unable to find this file.

Other than requesting the developer of Clonezilla to implement a similar solution to that adopted by Parted Magic are there any other potential solutions worth exploring?

[was_jaclaz]

Firstly, many thanks to everyone that contributed to making it possible to boot Parted Magic directly from ISO. This feature will be included in the forthcoming release, v 3. The increased awareness this will bring to both Grub4DOS and Parted Magic can only be beneficial to both projects.

I guess that most of the merit goes to you.
The only thing we did was "convincing" you that it was not grub4dos "fault", and that the Linux side needed some changes.

However, it would be nice if you could (possibly) start a new thread, describing in detail how to setup grub4dos to boot the Parted Magic "new version" .iso, which files are needed, where did yuo put them, the menu.lst you use and so on.

I.e. something that a new member that is looking for such a solution may use as a tutorial guide.

Secondly, on to the next tool to add; Clonezilla.

Extracting the ISO to the root of iso_root and loading the kernel via Grub4DOS results in Clonezilla starting as expected. It looks to load Clonezilla.iso/live/filesystem.squashfs. Extracting the ISO to any other directory than iso_root leads to the bootup failing (working assumption - it can no longer find filesystem.squashfs). Booting the ISO/img directly both fail, presumably because they are also unable to find this file.

Other than requesting the developer of Clonezilla to implement a similar solution to that adopted by Parted Magic are there any other potential solutions worth exploring?

The "right" thing to do in this case would be to study a bit the release, and understand where these settings are hardcoded.

Again, to help others help you it is advisable if you post some details on how it is now working, like a DIR list of the files and structure, the menu.lst entry that you are using and so on.

But still, if the Clonezilla developer is as "reactive" as Patrick proved to be, contacting the Author would be better, as the recent Parted Magic experience proved, it is perfectly possible to build these mini-distro's in such a way that they boot and work:
1) with the .iso burned directly to CD
2) with the .iso burned in a folder of the CD and with kernel and initrd extracted
3) with the .iso burned in a folder of the CD directly mapped and chainloaded as (hd32) with grub4dos


As you pointed out, doing the above can be beneficial to both the Linux distro and to grub4dos, and makes life really easier to "multibooters".


jaclaz

[SamK]

However, it would be nice if you could (possibly) start a new thread, describing in detail how to setup grub4dos to boot the Parted Magic "new version" .iso, which files are needed, where did yuo put them, the menu.lst you use and so on.

I.e. something that a new member that is looking for such a solution may use as a tutorial guide.

I will be happy to document the way I have this working. Perhaps it might be advisable to wait until version 3 of Parted Magic is generally available (it is currently a development/testing release and wrinkles are still being 'ironed-out').

I am unable to support/guide others in a similar manner to you, and therefore do not envisage this being a 'full-blown' tutorial which I maintain and change over time. I do, however, see the value in enabling others to benefit from the knowledge gained. Where would you prefer the new thread to be opened?

[tinybit]

@SamK

Congratulations!

This is a relay race. Grub4DOS handed out the first bar, then Linux stick to the second. Both are indispensable. In this way, there could be a smooth transition from the "real mode" to "protected mode". And we can say that this is almost the only way, and almost all the other methods will not work.

Yes, we made it. This success belongs to each of us. Open a bottle of champagne to celebrate. Cheers!

[was_jaclaz]

Where would you prefer the new thread to be opened?

I opened it and stickied it.
Just post here:
http://www.boot-land...?showtopic=5041

@SamK
Yes, we made it. This success belongs to each of us. Open a bottle of champagne to celebrate. Cheers!

jaclaz

[ilko]

It really deserves champaign, a big step forward, thanks to everyone

I have made a similar request for UBCD, which is way easier to be made grub4dos aware:
http://www.ultimateb...opic.php?t=1399

as a follow up of this topic:
http://www.boot-land...?...ost&p=38234

As well as additional request to Patrick:
http://partedmagic.c...p;start=30#p695

[SamK]

@ilko

As well as additional request to Patrick:
http://partedmagic.c...p;start=30#p695

The developers of the mini-distros often brand them with a splash/menu screen. Certainly Patrick has a Parted Magic logo that appears on both the menu and loading screens. These look as though they may have been professionally designed.

The standard Grub4DOS menu is best described as functional, but is unlikely to be seen as visually pleasing. It may be that some developers are reluctant to such a menu - even though it is only a cosmetic issue. I have seen a splashscreen referred to in the Grub4DOS help command. Are you familiar with its use? Might it be worth explaining this facility to Patrick and any other developer that is requested to make their mini-distro Grub4DOS aware?

On a side issue, I don't suppose you have also approached Clonezilla with this request? I expect the answer is no but I am ready to be very pleasantly surprised.

A separate point, I have always been inclined towards the use of sub-directories rather than using the root directory for storage. I am in favour of simplicity and a universal approach, and was wondering if this might also include the use of sub-directories to hold the ISOs?.

Last point, if your idea to use a simple menu suitable for novices is adopted, how will the user add kernel parameters as they can currently with an isolinux based menu? For example Parted Magic uses a kernel parameter 'keymap=' to set the keyboard layout.

[ilko]

Grub4dos supports splash screens, there are some requirements, look here for some details:
http://www.msfn.org/...php/t69211.html

If ISO can be placed on root and those parameters avoided, then I suppose it should not be problem to be hardcoded to look at a specific folder for it, say /pmagic, instead of root.

The point is each ISO to be loaded in a standard way:

find --set-root /somewhere/something.iso

map /somewhere/something.iso (hd32)

map --hook

root (hd32)

chainloader (hd32)

In this case, you don't have to worry what kernel parameters must be, that's job of the loader in the ISO, which should be grldr in order to survive the emulation, or may be any other, which will not reread BIOS to enumerate devices. I know isolinux and bcdw would fail.

What tricky is- if /somewhere is used, each distro has to know where to look for something.iso, in order to access it later on while in protected mode.
Since you cannot pass this parameter/location, it has to be unique for each distro, which makes it more complicated.
Something.iso is the same name as released by the developer. Lets say pmagic-xy-z.iso. This name is passed as parameter from grldr/menu.lst on the ISO. Or if it has to be changed, then ISO must be rebuilt.

[was_jaclaz]

Most Linux based distros that use Grub, use a gfx enabled version of it.

Grub4dos (the current versions that support (hd32) mapping) are NOT gfx enabled and use the "old" .xpm splashimage format.

Some references:
http://www.boot-land...opic=4979&st=25
http://www.boot-land...?showtopic=4599
http://www.boot-land...?showtopic=4749

We have to ask tinybit if it is possible (and it does not "get in the way" of other features of grub4dos) to add or re-add, adapting it , the gfx enabling patch to grub4dos.

jaclaz

[SamK]

@jaclaz

In your post
http://www.boot-land...opic=2887&st=30
You describe the results of tests of booting nested images. Might this offer a possible solution to the requirement of ISO images being in a common location (iso_root) which is currently being explored by ilko and Patrick Verner?

If I understand your results correctly booting the inner image automatically provided access to the outer image. Applying this concept to Parted Magic (as an example) might the following be possible?
Inner image = very small, basic, bootable
Outer image = Larger, bootable, + Inner image + pmagic-svn.iso (incorporating ilko's current idea) or pmagic.7z in the root.
Potential gains:
When the inner image boots the outer image is available
The outer image is available at a known location
The known location allows access to the application/mini-distro
Potential results:
The Outer image can be located in a location other than iso_root
The Outer image is bootable in the normal manner retaining compatibility with the common practice of CD-ROM burned from ISO

This is a very rough outline based on an incomplete understanding of your concept. Does it seem viable in principle?



Your post in the Parted Magic forum is intriguing but I cannot grasp how you see this leading to a "more universally bootable" result. Are you able to provide an explanation of your idea?
http://partedmagic.c...h...=a&start=39

[was_jaclaz]

Actually, as stated, it is more like one of my "semi-random" ones.

The original idea was to answer a request by Medevil who asked for a XP/PE CD that could be booted BOTH directly and as an image booted through RAMDISK method.

I started exploring the idea with FAT images because it is a very simple filesystem and I know a bit of it's innards, in the hope that once the thing proved to be feasible, it could be somehow "ported" to CDFS and CDs/DVD's.

Then cdob came out with his knowledge of CDFS and we found out that it was actually much easier than what was initially foreseen.

The "Outer" image described in the thread is an "image" only because I use tools that work with images and test in VM's (using images), more properly the "Outer image" is the actual filesystem on a device, whilst the inner image is really an image.

The described setup (either FAT or CDFS) was aimed to have the same "contents" accessible BOTH "directly" (as files in the filesystem) or through RAMDISK booting (i.e. as a "monolithic" image) without doubling (or worse) the space occupied.

The "overhead" of this solution on FAT is the "doubled" FAT tables, (a few hundreds kilobytes) and almost nothing on CDFS.

The FAT part was "abandoned" as the request for a CDFS, and cdob found the solution for it.

As said, it may be of NO use for the Parted Magic problem...
...or maybe someone could use this bit of info (which is not commonly found, I believe that thread is the only place where the problem has been raised and solved) in a creative way and make use of it...

Since I haven't even fully understood (nor tested) the CDFS method, I am "throwing" the idea on the table, to see if anyone can use it.

Your approach seems to me correct at first sight, but as I see it there is a problem that I do not know how it could be solved:

The outer image is available at a known location

jaclaz

[SamK]

Your approach seems to me correct at first sight, but as I see it there is a problem that I do not know how it could be solved:

The outer image is available at a known location

I may have misunderstood but I interpreted your description to mean that drive J: (outer image) was automatically recognized and made available by the Windows OS following a boot from drive K: (inner image).
See here:
http://www.boot-land...opic=2887&st=30

If this is correct might a similar result be obtained when using Linux instead of Windows? If so, this may represent "a known location" and point towards a solution to the problem of the Linux kernel being unable to locate and load any files required to complete the boot/load.

This might also be able to be combined with the experiments currently being conducted by ilko and Patrick Verner to remove the kernel parameters iso_location and isoboot.
See here:
http://partedmagic.c...h...=a&start=31

[was_jaclaz]

I may have misunderstood but I interpreted your description to mean that drive J: (outer image) was automatically recognized and made available by the Windows OS following a boot from drive K: (inner image).

Yes, but in that context the J: (called conventionally outer image) was actually a PHYSICAL drive from which the system was booted from.

In THAT experiment:
booting sequence:
1) BIOS loads MBR of drive J:
2) MBR loads bootsector of drive J:
3) bootsector loads system loader
4) system loader loads grub4dos
5) You can choose between "normal" or Reamdisk loading
6) if you choose "normal", the files in filesystem on drive J: are accessed normally
7) if you choose "Ramdisk loading" the SAME files on drive J: are accessed through a inner.img file, which is a "fake" filestem pointing to the same physical addresses on disk as the filessystem of drive J:

So, the "container" is PHYSICAL (and thus auto-detectable by the OS), while the "content" is "Virtual", it is an "image inside disk".

The approach for multibooting several images needs an "image inside image" approach, where BOTH the container and content are "virtual".

You can maybe have something like (untested):

title iso_in_iso
map (hd0,0)/outer.iso (hd33)
map --hook
map (hd33)/inner.iso (hd32)
map --rehook
chainloader (hd32)

But would it work?
Or would it "loose contact" as soon as Protected Mode kicks in?

I guess the second....

But anyway Patrick and ilko appear to be making the greatest progresses, so this will most probably be unneeded.

jaclaz

[SamK]

But would it work?
Or would it "loose contact" as soon as Protected Mode kicks in?

Stage1 CREATE INNER & OUTER ISOs
Downloaded ISO of Parted Magic (pmagic-svn.iso)
Extracted \pmagic\bzImage and \pmagic\initrd
Created ISO containing BZIMAGE and INITRD (named PM.ISO)
Injected PM.ISO in \ of pmagic-svn.iso


Stage2 CREATION OF PHYSICAL CD-ROM
File Structure:
ISOBUILD\mkisofs
ISOBUILD\iso_root\gldr and menu.lst
ISOBUILD\iso_root\images\pmagic-svn.iso
Build using mkisofs
Burn using ImgBurn

At this point we have a physical CD-ROM containing an outer.iso containing an inner.iso

Stage3 BOOTING
menu.lst

map --mem /images/pmagic-svn.iso (hd32)

map --hook

map (hd32)/PM.ISO (rd)

kernel (rd)/BZIMAGE root=/dev/ram0 initrd=/linuxrc keymap=uk livecd vga=normal sleep=0 ramdisk_size=25000 noapic

initrd (rd)/INITRD

boot

RESULT
Boot/load completes as expected.

Notes:

• On the standard Parted Magic downloaded ISO all the files required for booting are located at \pmagic\ (bzImage, initrd, pmagic.7z)
• The kernel parameters passed to (rd)/BZIMAGE are the same as those used when booting the (non Grub4DOS aware) Parted Magic CD-ROM via isolinux. Neither iso_location or isoboot parameters are used.
• The transition from real to protected mode is successfully accommodated.
• The file required to complete the boot/load (pmagic.7z) remains in its original location and is successfully found and loaded by PM.ISO.

[was_jaclaz]

GOOD!

Two questions/considerations:
1) is the --mem parameter neceessary?:

map --mem /images/pmagic-svn.iso (hd32)

or would this work as well:

map /images/pmagic-svn.iso (hd32)

2) this way the size of pmagic-svn.iso is incremented by the size of PM.ISO, is it not?
What happens if you use the info from cdob and create the PM.ISO as a simple filesystem entry pointing to the entire pmagic-svn.iso ?

jaclaz

[SamK]

...is the --mem parameter neceessary?:

If the --mem option is omitted the following error is received:

map (hd32)/PM.ISO (rd)

Autodetect number-of-heads failed. Use default value 2.
Autodetect sectors-per-track failed. Use default value 2.

Error 25: Disk read error.

...this way the size of pmagic-svn.iso is incremented by the size of PM.ISO, is it not?

Yes. It was meant as a simple test of my concept. Size was therefore a secondary matter.

What happens if you use the info from cdob and create the PM.ISO as a simple filesystem entry pointing to the entire pmagic-svn.iso ?

I do not understand cdob's post and therefore am unable to test it. Are you able/willing to conduct the test and subsequently explain your understanding?

[was_jaclaz]

The pmagic-svn.iso needs to be contiguous.

Use CONTIG:
http://technet.micro...s/bb897428.aspx

to check.

Can you also try with the (hd33) method?

map /images/pmagic-svn.iso (hd32)

map --hook

map (hd32)/PM.ISO (hd33)

map --rehook

kernel (hd33)/BZIMAGE root=/dev/ram0 initrd=/linuxrc keymap=uk livecd vga=normal sleep=0 ramdisk_size=25000 noapic

initrd (hd33)/INITRD

boot

or

map /images/pmagic-svn.iso (hd32)

map (hd32)/PM.ISO (hd33)

map --hook

kernel (hd33)/BZIMAGE root=/dev/ram0 initrd=/linuxrc keymap=uk livecd vga=normal sleep=0 ramdisk_size=25000 noapic

initrd (hd33)/INITRD

boot

I do not understand cdob's post and therefore am unable to test it. Are you able/willing to conduct the test and subsequently explain your understanding?

I can try, can you give some details about the following:
1) the pmagic-svn.iso is the one here:
http://partedmagic.c...7Jun,221033.zip
or is it another one? Please give a link to it.
(that one appears to be a truncated archive)

2) Which apps did you use for these steps?:

Created ISO containing BZIMAGE and INITRD (named PM.ISO)
Injected PM.ISO in \ of pmagic-svn.iso

3) which options did you use with mkisofs in this step?:

Build using mkisofs

4) Do you happen to know which parameters are used with mkisofs when creating the original pmagic-svn.iso?

jaclaz

[ilko]

In the latest posts in pmagic forum, Patrick has accepted the idea to include only customized grub4dos.lst in root of his builds.
Since pmagic.iso is going to be loaded by grub4dos anyway, there is no point to load a second grldr in pmagic.iso. It just has to use the config file in root of pmagic.iso.

title Start PMagic

find --set-root /pmagic-svn.iso

map /pmagic-svn.iso (hd32)

map --hook

root (hd32)

configfile (hd32)/grub4dos.lst

This will be an easy way to request similar functionality from other live CD maintainers. They will not have to change Isolinux or whatever they use, to grub4dos. And anoyne creating multiboot will have to change only the name of the ISO file in his menu.lst.
Seeing grub4dos.lst in root of an ISO will mean that the ISO is grub4dos aware.

You probably already saw the last posts, what do you think?

I am on my way to UBCD, in latest v5 beta, pmagic is included. Now we have to figure out how to start pmagic from UBCD.ISO.
PMagic is already in directory \pmagic. That's good. Simple solution is to rename UBCD.ISO to PMAGIC.ISO or whatever name it was extracted from. Will have to request additional file or a commented out line in grub4dos.lst to indicate what ISO name PMagic was extracted from, as well as to include the latest version, which should be released soon.

title Start UBCD

find --set-root /pmagic-svn.iso

map /pmagic-svn.iso (hd32)

map --hook

root (hd32)

configfile (hd32)/grub4dos.lst

@SamK- sorry, I forgot to answer, haven't done anything with clonezilla.

[was_jaclaz]

You probably already saw the last posts, what do you think?

But anyway Patrick and ilko appear to be making the greatest progresses, so this will most probably be unneeded.

But still, I like exploring alternatives.

Remember that Patrick has been EXCEPTIONALLY present and positive in his attitude towards our requests and comments, Authors of other distro's or minidistro's may not be as much available to this kind of requests/suggestions, and TIMTOWTDI:
http://en.wikipedia.org/wiki/There's_m...ne_way_to_do_it
or, if you prefer,

There's more than one way to skin a cat

http://www.worldwide.../qa/qa-mor1.htm

jaclaz

[SamK]

The pmagic-svn.iso needs to be contiguous.

Use CONTIG:
http://technet.micro...s/bb897428.aspx

to check.

Is this a suggestion to overcome the Autodetect... and Disk read error messages? Contig was not used to establish the following results. I would prefer to build each ISO using mkisofs to obviate this possible problem but need some additional information (detailed below).

Can you also try with the (hd33) method?

RESULTS

map /images/pmagic-svn.iso (hd32)
map --hook
map (hd32)/PM.ISO (hd33)

Disk read error.

map /images/pmagic-svn.iso (hd32)
map (hd32)/PM.ISO (hd33)

Selected disk does not exist

can you give some details about the following:
1) the pmagic-svn.iso is the one here:
http://partedmagic.c...7Jun,221033.zip
or is it another one? Please give a link to it.
(that one appears to be a truncated archive)

Patrick normally updates his svn versions overnight (UK time). In this process each ISO is given a filename that includes a date element which changes depending upon the date of upload. The link you are trying has probably been superseded with a newer version. Try http://partedmagic.com/beef_drapes and download the most recent ISO. There are usually three files shown for booting from CD-ROM, USB or PXE.

Which apps did you use for these steps?:

Created ISO containing BZIMAGE and INITRD (named PM.ISO)
Injected PM.ISO in \ of pmagic-svn.iso

A commercial product called WinISO. This is able to extract from ISO, create ISO and inject into ISO. This may also account for the previously mentioned disk errors - hence my preference for mkisofs. Can we agree on a common set of software tools to avoid as many 'incompatibilities' as possible?

which options did you use with mkisofs in this step?:

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

Do you happen to know which parameters are used with mkisofs when creating the original pmagic-svn.iso?

No - hence my use of WinISO instead of mkisofs. I will ask Patrick Verner to post it in the Parted Magic forum.

[tinybit]

map /images/pmagic-svn.iso (hd32)

map --hook

map (hd32)/PM.ISO (hd33)



Disk read error.

Perhaps you are using an older version of grub4dos. Try the latest builds here: http://download.gna.org/grub4dos/
You'd better try the build 2008-06-28 first. If you still got "Disk read error", this would indicate a new bug in grub4dos.

map /images/pmagic-svn.iso (hd32)

map (hd32)/PM.ISO (hd33)



Selected disk does not exist

map --hook is required before map (hd32)/PM.ISO (hd33) or before any other command that will access files on (hd32).

map --mem /images/pmagic-svn.iso (hd32)

map --hook

map (hd32)/PM.ISO (rd)

kernel (rd)/BZIMAGE root=/dev/ram0 initrd=/linuxrc keymap=uk livecd vga=normal sleep=0 ramdisk_size=25000 noapic

initrd (rd)/INITRD

boot

Before boot, you may try to free the memory that was used for the mapping:

map --mem /images/pmagic-svn.iso (hd32)

map --hook

map (hd32)/PM.ISO (rd)

kernel (rd)/BZIMAGE root=/dev/ram0 initrd=/linuxrc keymap=uk livecd vga=normal sleep=0 ramdisk_size=25000 noapic

initrd (rd)/INITRD

map (hd32) (hd32)

map --rehook

boot

Notice the mapping map (hd32) (hd32). Generally mapping a drive to itself really means to delete the map. Then after map --rehook, the memory that was occupied by the virtual CD-ROM will be freed.

Also note that the use of (rd) is not required in this situation. You may just do it as folows:

map --mem /images/pmagic-svn.iso (hd32)

map --hook

kernel (hd32)/BZIMAGE root=/dev/ram0 initrd=/linuxrc keymap=uk livecd vga=normal sleep=0 ramdisk_size=25000 noapic

initrd (hd32)/INITRD

map (hd32) (hd32)

map --rehook

boot

[tinybit]

Use CONTIG:
http://technet.micro...s/bb897428.aspx

Someone in a Chinese forum told me that there is a new tool called WinContig(which is better than the Microsoft contig):

http://wincontig.mdtzone.it/en/

[SamK]

@jaclaz

I will ask Patrick Verner to post it in the Parted Magic forum.

mkisofs -R -l -D -b pmagic/isolinux.bin -o pmagic-svn.iso -c pmagic/boot.cat \
-no-emul-boot -boot-load-size 4 -boot-info-table -V "Parted Magic" current

All of the boot process is done in /etc/init.d/rcS

Nobody boots a LiveCD like I do, so I don't know how reliable my ideas might be for other distros.

[SamK]

You probably already saw the last posts, what do you think?

My previously expressed principles:

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

All well met.