Jump to content











Photo
- - - - -

Grub4dos "isohybrided"


  • Please log in to reply
41 replies to this topic

#26 was_jaclaz

was_jaclaz

    Finder

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

Posted 09 December 2009 - 10:10 AM

Anyone thinking that the title of "Finder" is not deserved, ... you are wrong! :whistling:

Full mirror of original page on Geocities, including download of makebt.zip :thumbsup::
http://www.reocities...8936/index.html


:thumbup:

jaclaz
  • iNf3kt0r likes this

#27 COD11

COD11

    Member

  • Members
  • 63 posts
  •  
    Germany

Posted 09 December 2009 - 11:25 PM

Hello,
I have good news. I solved the problem to get the same G4DOS menu, when starting as USB HDD and CD. Without my recent changes, you only get a G4DOS menu, when starting as USB HDD. Booting as CD always launches first ISO image, which should NOT be a "menu.iso", because then you give away the ability of the first ISO image to load external files .

What did I do ? I redirected boot catalog vector (-> isolinux.bin) of first ISO image (Parted Magic 4.6) to a slightly modified GRLDR on second ISO image (my "menu.iso").

Why modifying GRLDR and where ?
Without modification GRLDR finds "/boot/grub/menu.lst" on first ISO image and we are "as wet as before", see above. I even doubt, if it could find "menu.lst" on "menu.iso", if there wasn't a "menu.lst" on first ISO. How do I get GRLDR to ignore "/boot/grub/menu.lst" on first ISO ? Well, GRLDR has an internal menu.lst to find menu.lst externally ( first on partitioned devices, then on CD and at last on FDD). I edited the internal menu.lst and introduced as first seek path "configfile (hd0)1+1". Which points to the unused second sector of (hd0). There I put the following :

color black/black

timeout 1

default 0



title Boot Menu

map --unhook

map --heads=0 --sectors-per-track=0 (hd0)170960+825070 (hd32)

map --hook

root (hd32)

chainloader
(hd0)170960+825070 is the blocklist notation of the absolute address of "menu.iso". It's size isn't that big as it seems, but I noticed, that size doesn't matter, unless it's smaller than the ISO file. So I extended every size of ISO images to the whole (rest) size of my USB stick. This is crucial for the first ISO image, otherwise modified boot catalog points to Nirwana, because GRLDR is out of reach.

I then reduced timeout of "menu.lst" on second primary partition (for USB-HDD boot) to one second, so that there is no visible additional menu. Of course it's calling "menu.iso" as default.

I will create a trial version, containing "PartedMagic 4.6" as first ISO and a placeholder ISO as third (second is menu.iso) for your testing of other ISO images up to 200 MB (Just copy your whole ISO to the right sector location of the trial version and boot !). Since I'm "on the road" until Monday, you have to be a little bit patient until I will finish my work.

Concerning multiboot CD software, I analyzed, how it works and noticed that there is enough good software for this purpose. Since the result is one big ISO file, just put it as third ISO image on my trial version ... and it will work ! Multiboot ISOs contain NO internal ISO images, so the problem of not finding external files does NOT exist.

Regards
COD11

#28 tinybit

tinybit

    Gold Member

  • Developer
  • 1051 posts
  •  
    China

Posted 10 December 2009 - 01:58 AM

I edited the internal menu.lst and introduced as first seek path "configfile (hd0)1+1". Which points to the unused second sector of (hd0). There I put the following :

color black/black

timeout 1

default 0



title Boot Menu

map --unhook

map --heads=0 --sectors-per-track=0 (hd0)170960+825070 (hd32)

map --hook

root (hd32)

chainloader
(hd0)170960+825070 is the blocklist notation of the absolute address of "menu.iso".


Urh... Your approach seems to be "under construction" :thumbsup:

When you boot from CD, the (hd0) would be non-existent.

You might want to place the content of your menu.lst at the 5th sector of the (hd0), that is, LBA sector 4 of (hd0). Why? Because this is 2048-byte aligned and thus it can be accessed by a no-emulation-mode boot CD.

A no-emulation bootable CD uses 2048-byte big sectors. So you could call this sector (cd)1+1, which is your (hd0)4+4. Accordingly, when booting from CD,

map --heads=0 --sectors-per-track=0 (hd0)170960+825070 (hd32)

should change to

map --heads=0 --sectors-per-track=0 (cd)42740+206268 (hd32)

where 42740=170960/4 and 206268=825070/4 rounded up.

#29 was_jaclaz

was_jaclaz

    Finder

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

Posted 12 December 2009 - 04:15 PM

As often happens OT :rolleyes: but not much :thumbup:.

Look how the good guys at MenuetOS create a bootableCd from a bootable floppy:
http://www.menuetos.net/
http://www.menuetos.net/download.htm
http://www.menuetos.net/cdboot.htm

Tested same approach with the first floppy image I had handy, a Windows 98 one, and the Qemu booted it from CD-ROM allright.

Really simplified way. :thumbup:

jaclaz

#30 COD11

COD11

    Member

  • Members
  • 63 posts
  •  
    Germany

Posted 21 December 2009 - 11:24 PM

Urh... Your approach seems to be "under construction" :cheers:

Now it's working !!!
Download : http://www.mediafire...hybrid_test.zip

It contains as first ISO Image "PartedMagic 4.6" and a second dummy ISO, where you can put your own Image (max. 355,8 MiB) for testing. My aim was to leave the ISO Images untouched and get things to work anyway. This goal is reached with one exception : the pointer to the no-emulation program in boot.catalog of first ISO image has to be redirected to GRLDR (one double-word changed). I need ONE GRLDR file (with modified "internal" menu.lst), a special MBR, a "hybrid.lst" file at CD sector 1 (addr. 0x800), a fake first primary partition, a real second (primary or extended-logical) partition for at least GRLDR file and (main) "menu.lst". Since "menu.lst" is stored on a real filesystem, you can easily edit and adapt it. Structures of real filesystems are NOT woven into ISO images as with tinybit's approach, which will also work, no doubt.

There was a nice "side-effect" : PartedMagic contains its own "menu.lst". If you invoke it from my main menu.lst with colors and splashimage set, they are applied as well. Of course the menu items work; no need to reinvent the wheel so far. Since whole drive and second partition are mapped (hd32), resp. (hd16) both with CD and HDD boot, you always have a constant reference to it. "Local Boot" from any ISO image on USB-HDD means "reload" GRLDR by MBR since USB pendrive is (hd0). This brings main menu back ! You can change from image to image without BIOS reboot.

Try it and tell your experiences.

Regards
COD11

#31 COD11

COD11

    Member

  • Members
  • 63 posts
  •  
    Germany

Posted 23 December 2009 - 05:29 PM

As a spin-off product of my experiments with G4DOS-Isohybrid, I found another way to get multiple ISO Images to work from USB pendrives (NOT CD). I was inspired by tinybit's "yet another approach". The construction is very simple :

[ Isohybrid MBR with MS-DOS partition table ]
[ FAT 16 Menu partition, bootable, with GRLDR, menu.lst]
[ Extended or primary partition without PBR, but ISO Image 1]
[ primary (or extended/logical) partition without PBR, but ISO Image 2]
[ primary (or extended/logical) partition without PBR, but ISO Image 3]
[ logical partition without PBR, but ISO Image 4]
.... and so on.

The ISO images are aligned one after the other (with primary partitions), resp. with preceeding extended Boot Records (with logical volumes). You can easily create such structures with GParted or fdisk. There only exist partitioning structures, no Volume / Filesystem structures other than the internal ISO filesystems. Linux does NOT have any problems to mount such a "partition"; Windows doesn't see it (fs ID 83). So if the ISO image contains a Linux based program AND has an appropriate algorithm to find a needed external file or resource, it may find it on its own ISO image, located anywhere on the USB medium.

GRLDR (with menu.lst) as bootmanager is located on the first primary bootable partition.
Here we need a regular filesystem, which is also accessible for Windows then. So you can easily customize menu.lst. Note, that you can't chainload isolinux.bin, when used as bootmanger on an ISO file, because isolinux needs a CD boot (2048 bytes/sect.) to work properly. Unfortunately, mapping doesn't work. This means, that you have to analyze isolinux.cfg, to adapt the menu code for G4DOS and to add it to your menu.lst.

It seems not so complicated to program a Linux bash script, which composes such an "USB multi-ISO image" automatically. I think, fdisk, mtools-mkdosfs, cat and dd would do the job. Writing menu.lst might remain a manual work, but you often get the chance to localize your distro with boot parameters and to avoid annoying boot dialogues.

Note, that GRLDR was NOT modified with this approach. It's also clear, that it won't work on a CD, but of course on a(n external) harddisk. I didn't test Windows bootable ISO images, some might work, others not, I suppose. Loading external resources from the ISO image is definitely NOT possible under Windows.

My USB teststick had "GParted 0.5.0-3 " and "PartitionMagic 0.4.6" on board. Both distros loaded their sqfs-files without any problems.


Supplement :

Note, that you can't chainload isolinux.bin, when used as bootmanger on an ISO file, because isolinux needs a CD boot (2048 bytes/sect.) to work properly.


I found a solution ( PM 46 is on an extended logical partition ! ):

menu.lst
title PartedMagic 0.4.6 (boot by internal isolinux.bin)

map (hd0,4)0+170960 (hd32)

map --hook

root (hd32)

chainloader

It's now possible to create a first menu.lst automatically. You can edit and customize items later.

M E R R Y

C H R I S T M A S !

#32 cdob

cdob

    Gold Member

  • Expert
  • 1314 posts

Posted 09 January 2010 - 04:28 PM

@COD11
Thanks for the isohybrided approach.

A sliphtly different approach: ISO fake partition:

Given a USB Stick with one partition (hd0,0).
There are multiple ISO Images at USB stick.

Grub4dos creates a appropiate ISO partition on the fly.
Grub4dos partnew can write a partition entry at MBR.
Changes are permanent.
A booted OS may find the ISO partition.

This is a universal approach to *nix ISO images.
Most images should work, of course some will fail.
Windows won't mount the ISO partition.

In addition there is a tag file writeMBR.usb001 to mark the USB stick 001.
This tag file is for safety reasons.
Be careful: don't use this, if your MBR use (hd?,3) already.

Examples:

#Boot AVIRA AntiVir Rescue System from a UBCD 5.0 ISO image

title UBCD 5.0 -  AVIRA AntiVir Rescue System

ls /images/ubcd50RC1.iso || find --set-root /images/ubcd50RC1.iso

ls (hd0,0)/images/writeMBR.usb001 && partnew (hd0,3) 0x00 /images/ubcd50rc1.iso

map /images/ubcd50RC1.iso (0xff)

map --hook

root (0xff)

configfile /ubcd/boot/antivir/grub4dos.lst



title Knoppix 6.2 partnew

ls /images/KNOPPIX-6.2.iso || find --set-root /images/KNOPPIX-6.2.iso

ls (hd0,0)/images/writeMBR.usb001 && partnew (hd0,3) 0x00 /images/KNOPPIX-6.2.iso

#ls (hd1,0)/images/writeMBR.usb001 && partnew (hd1,3) 0x00 /images/KNOPPIX-6.2.iso

#ls (hd2,0)/images/writeMBR.usb001 && partnew (hd2,3) 0x00 /images/KNOPPIX-6.2.iso

map /images/KNOPPIX-6.2.iso (0xff)

map --hook

root (0xff)


#33 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13338 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 09 January 2010 - 05:46 PM

Grub4dos creates a appropiate ISO partition on the fly.
Grub4dos partnew can write a partition entry at MBR.
Changes are permanent.
A booted OS may find the ISO partition.

Nice "by-product" :) or "collateral damage". ;)

:D

Be careful: don't use this, if your MBR use (hd?,3) already.


Maybe it would be possible to "assemble" your ".iso partnew" idea with some of the ideas scattered in this thread:
http://www.boot-land...?...ic=7138&hl=
and create a "fool-proof" method of backing-up (and later restore) existing partition table before issuing the partnew command....;)

:)

Wonko

#34 cdob

cdob

    Gold Member

  • Expert
  • 1314 posts

Posted 10 January 2010 - 07:32 PM

Nice "by-product" ;) or "collateral damage". ;)
It's my pleasure :)
 
a "fool-proof" method of backing-up
No, I don't have a "fool-proof" method of backing-up the partition table.
All approaches have disatvantages.

I like the manual bakcup to sector 62.
http://www.boot-land...?...ost&p=61520

Another example: ophcrack
 
title ophcrack-xp-livecd-2.3.1.iso partnew

ls /images/ophcrack-xp-livecd-2.3.1.iso || find --set-root /images/ophcrack-xp-livecd-2.3.1.iso

ls (hd0,0)/images/writeMBR.usb002 && partnew (hd0,3) 0x06 /images/ophcrack-xp-livecd-2.3.1.iso

map /images/ophcrack-xp-livecd-2.3.1.iso (0xff)

map --hook

root (0xff)

chainloader (0xff)

Ophcrack does boot, but hash files are not found.
There is a directory /mnt/sda4 created, but no partition mounted.
Therefore mount the parititon manually
su

root

mount /dev/sda4 /mnt/sda4

/home/tux/launch.sh

  • ilko likes this

#35 COD11

COD11

    Member

  • Members
  • 63 posts
  •  
    Germany

Posted 11 January 2010 - 06:01 PM

@cdob
Fascinating approach :confused1:

You only need one "active" Windows visible partition for Bootmanager (Grub4DOS) and a (structured) repository of ISO images, create a second (Linux) partition with the Bootmanager "on the fly" and get it even permanent for a next boot ( should have an appropriate menu item : Boot last ISO image )! If you keep one empty primary partition table for this purpose, there should be no need for a backup of MBR. Of course it only works with (Linux) ISO images, which are able (and willing !) to look for "external" needed files by mounting all (at least temporarily) in their range.

#36 Icecube

Icecube

    Gold Member

  • Team Reboot
  • 1061 posts
  •  
    Belgium

Posted 18 September 2010 - 04:35 PM

As often happens OT ;) but not much :cheers:.

Look how the good guys at MenuetOS create a bootableCd from a bootable floppy:
http://www.menuetos.net/
http://www.menuetos.net/download.htm
http://www.menuetos.net/cdboot.htm

Tested same approach with the first floppy image I had handy, a Windows 98 one, and the Qemu booted it from CD-ROM allright.

Really simplified way. :ph34r:

jaclaz

Strange you didn't notice that they use create a bootable ISO with floppy emulation:
$ hexdump -C ISOHDR

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

*

00008800  00 43 44 30 30 31 01 45  4c 20 54 4f 52 49 54 4f  |.CD001.EL TORITO|

00008810  20 53 50 45 43 49 46 49  43 41 54 49 4f 4e 00 00  | SPECIFICATION..|

00008820  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

*

00008840  00 00 00 00 00 00 00 13  00 00 00 00 00 00 00 00  |................|

00008850  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

*

00009800  01 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

00009810  00 00 00 00 00 00 00 00  00 00 00 00 aa 55 55 aa  |.............UU.|

00009820  88 02 c0 07 01 00 01 00  1a 00 00 00 00 00 00 00  |................|

00009830  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

*

0000d000
0x8800 = 34816 = sector 17 * 2000 bytes ==> Boot record
0x9800 = 34880 = sector 19 (= 0x13) *2000 bytes ==> Boot catalog

0x9821 = Boot media type ==> 0x2 = 1.44 meg diskette

So you can create a bootable ISO image from the floppy image with mkisofs too (which will look very similar).

#37 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13338 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 18 September 2010 - 06:52 PM

Strange you didn't notice that they use create a bootable ISO with floppy emulation:

Sure I noticed :cheers:.
What you missed noticing ;) is the fact that I noticed it so well that I tested the header on a Win98 floppy image (and obviously succeeded in booting) ;)

So you can create a bootable ISO image from the floppy image with mkisofs too (which will look very similar).


Sure :ph34r:, the whole point was the simplified way, NO need for mkisofs, or cygwin.dll or ANYTHING but the actual "header", like:

How to convert a bootable floppy into a bootable .iso?

COPY /B isohdr + floppy.ima floppy.iso


Narrow scope, but simple, rudimental, effective. ;)

;)
Wonko

#38 steve6375

steve6375

    Platinum Member

  • Developer
  • 6462 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 11 December 2012 - 08:44 PM

Tails seems very difficult to boot from an ISO, but it works using cdob's partnew method. I have detailed the method here.



#39 ilko

ilko

    Silver Member

  • Advanced user
  • 500 posts
  •  
    Bulgaria

Posted 11 December 2012 - 10:50 PM

Tails seems very difficult to boot from an ISO..

Seems to support findiso parameter, first menu tested, rest not, posted sample in the relevant topic:
http://reboot.pro/to...e-7#entry164106

#40 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13338 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 12 December 2012 - 10:47 AM

@steve6375

If I remember correctly Linux does not care (much) about the partition ID in the partition table :unsure:.

 

Instead of writing a partition ID of 0 to the 4th entry, it would be advised to use a Linux ID (I know how a partition entry pointing to a .iso with ID of 0x82 is normally mounted in Zeroshell a "niche" Linux distro for router/firewall, cannot say if this is specific to that distro or is "generalized" if the latter other ID's may be good as well).

 

A number of programs dealing with MBR and partition tables do not like finding a partition ID of 0, and this could also be a "safecheck" for the blanking on the partition.

 

Can you try changing the ID to a few values?

If something very rarely used such as 80 or 81 (Minix) works, we will have a "reasonable" added safety to:

 

 

 

# make empty table entry in 4th position in ptn tablepartnew (hd0,3) 0 0 0

by making it check that the ID is the given one before blanking the ehtry.

 

:cheers:

Wonko



#41 steve6375

steve6375

    Platinum Member

  • Developer
  • 6462 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 12 December 2012 - 11:42 AM

Using 0 is quite nice in that Windows should ignore it (if a HDD is being used) and so will not try to format it when accessed (which would erase the ISO file on the 1st ptn!).

I see what you are saying, but until we can find something that does not like 0, I think it is safer to stick with 0 until then.



#42 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13338 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 12 December 2012 - 12:06 PM

Using 0 is quite nice in that Windows should ignore it (if a HDD is being used) and so will not try to format it when accessed (which would erase the ISO file on the 1st ptn!).
I see what you are saying, but until we can find something that does not like 0, I think it is safer to stick with 0 until then.
Well, at the very least a check if it is 0 before blanking the partition data would be advised IMHO, you know Murphy's Law + kids + matches :ph34r:.....
 
I mean something like:

# make empty table entry in 4th position in ptn table
parttype (hd0,3) | set check=
set check=%check:~-5,4%
if %check%==0x00 partnew (hd0,3) 0 0 0
 
 
:cheers:
Wonko
  • steve6375 likes this




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users