Jump to content











Photo
- - - - -

Grub4dos "isohybrided"


  • Please log in to reply
41 replies to this topic

#1 COD11

COD11

    Member

  • Members
  • 61 posts
  •  
    Germany

Posted 05 December 2009 - 05:26 PM

Hello,
since I'm already quoted here and have a new feature for this famous forum, I decided to register .
I'm not quite sure, where my ideas fit (Grub4dos ->Grub4dos,.iso images ... or new topic under Grub4dos?) .
I managed to get Grub4dos (0.4.4-2009-11-14) "isohybrided" (comparable to isolinux), i.e. using ONE image for both creating a bootable CD and a bootable USB pendrive. Well, isolinux can do that stuff already ... and it 's faster ! But it can only do it with ONE ISO image on ONE storage device. Grub4dos can potentially do it with MULTIPLE different ISO images on ONE medium. And Grub4dos is able to boot virtually ANY ISO image, no matter if it loads additional files, when running initial ramdisk, since ISO Image works like booted from a CD. At the moment, I have to create such images manually ( of course, I will upload a sample file for your tests and mention my tools), so I search for co-workers to create (Windows and Linux) scripts/programs for process automation, if this forum finds, that it's a useful feature.

The principle structure is as follows :
[ Master Boot Record; Code derived from isolinux, isohybrid]*
[ (fake)1st primary partition; boot, ID 0x83 (Linux; all ISO Image(s))]
[ 2nd partition : primary (FAT) or extended, for GRLDR, menu.lst and else ]


*) grldr.mbr didn't work !

When BIOS boots a USB pendrive as USB-HDD, it gets device (hd0). The Master Boot Record searches for GRLDR, but only on MS filesystems, first primary partition is skipped. So we need GRLDR on another partition, which eases BTW editing menu.lst.

How do we boot first ISO Image ?

menu.lst :

title Boot ISO image 1
map --unhook

# +100024 : size of 1st ISO image in sectors (512B) = 48.84 MiB
map --heads=0 --sectors-per-track=0 (hd0)0+100024 (hd32)
map --hook
root (hd32)
chainloader


Regards
COD11

#2 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7,100 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 05 December 2009 - 05:41 PM

Good. :cheers:

Welcome to the Forum. :thumbsup:

The place where you are quoted is actually this one:
http://www.boot-land...?...=5041&st=21

I am moving this thread to "Grub4dos" as it is where it actually belongs.

I am not sure to understand the advantage over "conventional" (hd32) or (0xff) mapping, but I am sure you will clear soon these perplexities.

If you are allright with having an old grumpy dinosaur :thumbup: mainly criticizing you (besides writing some batch files for the DOS/Windows platform :whistling:) you can count me in. :cheers:

:thumbup:

jaclaz

#3 COD11

COD11

    Member

  • Members
  • 61 posts
  •  
    Germany

Posted 05 December 2009 - 06:38 PM

Hello,

I am not sure to understand the advantage over "conventional" (hd32) or (0xff) mapping, but I am sure you will clear soon these perplexities.

I map an automatically contiguous file (the ISO Image) with sector (block) adressing outside a filesystem. Normally you would do it within a filesystem on a partition by using its filename. My experience is, that the latter way does NOT load files contained on the "CD", but needed, when kernel/initrd are already running ( eg. virus definition files or squash-filesystems for the main function). The files are out of sight, unless the ISO image gets loop mounted within initrd. To my amazement are those files on "CD" visible to initrd, when started with conventional map device names, but done "my way". The difference may be, that I'm able to have a non partitioned device name (hd0) as root on a partitioned device.

Regards
COD11

#4 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7,100 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 05 December 2009 - 07:31 PM

Hello,

I map an automatically contiguous file (the ISO Image) with sector (block) adressing outside a filesystem. Normally you would do it within a filesystem on a partition by using its filename. My experience is, that the latter way does NOT load files contained on the "CD", but needed, when kernel/initrd are already running ( eg. virus definition files or squash-filesystems for the main function). The files are out of sight, unless the ISO image gets loop mounted within initrd. To my amazement are those files on "CD" visible to initrd, when started with conventional map device names, but done "my way". The difference may be, that I'm able to have a non partitioned device name (hd0) as root on a partitioned device.

Regards
COD11


I see. :thumbup:

And of course is possible to give "any" start location of the .iso?

i.e. what this:

(hd0)0+100024


stands for?

Can I have, say,

(hd0)10025+100024

for a "second image"?


Hmmm :thumbsup:,
maybe you found, besides an alltogether new approach, also a practical use for this old (left unfinished/unfinalized) idea:
http://www.boot-land...?showtopic=2887
http://www.boot-land...?...=2887&st=14

:whistling:

jaclaz

#5 COD11

COD11

    Member

  • Members
  • 61 posts
  •  
    Germany

Posted 05 December 2009 - 11:40 PM

With device (hd0) as root, the whole storage medium is random accessible, regardless whether there are partitions and filesystems "on board" or not. The notation "(hd0)0+100024" is derived from "blocklist" command : 0 = sector 1 as starting point and 100024 gives the size in sectors of 512 bytes each. A second image might follow with "(hd0)100024+nnnnnn", where the sum must of course be less or equal than the end sector address of fake 1st primary partition.

Now we get into practice. I attach a zipped ISO file with two tiny ISO Images. Both images contain nothing but GRLDR ( as no-emul boot file) and menu.lst. They differ in coloring. 2nd primary partition holds a FAT12 filesystem also with GRLDR and menu.lst as first menu. You can switch between all three possibilities. Note, that GRLDR is ONLY ONCE necessary. The ISO images may have isolinux or Windows bootmanagers or whatever emulation boots.
GRLDR is dual used. It gets started by the MBR to find itself as a file... so it's a real advantage, that grldr.mbr didn't do the job ! The unpacked file has exactly the size of two harddisk cylinders. This is the minimum size or BIOS detects the USB Stick as HDD-ZIP.

How do you get it on your USB pendrive ?
As a Linux friend use "dd". As a Windows user, I would suggest "HxD" ( well, there is also "DD for Windows" ). HxD allows to edit the drive on sector basis and to directly write the file content to the drive. You can also create a drive image to backup its content, before you overwrite its Master Boot Record with my file.

So the steps are :
1. Download G4DOS.zip and unpack it.
2. Backup your USB pendrive, if necessary.
3. Start HxD and load G4DOS.ISO
4. Load USB pendrive content to HxD ( must be set writable !)
5. Copy whole G4DOS.ISO and write (not paste!) it to USB pendrive, beginning with first Byte on first sector.
6. Boot your system ( Adapt Boot sequence in BIOS !) and enjoy.
7. Those, who don't believe, that it works from a CDROM may burn one ( Note, that first ISO image always starts; further images only, if first image offers an appropriate menu item. So if you intend to create a multiboot CDROM, it would be a good idea to have GRLDR and an appropriate menu.lst within the first ISO image.)

COD11

Attached Files



#6 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7,100 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 06 December 2009 - 08:46 AM

How do you get it on your USB pendrive ?
As a Linux friend use "dd". As a Windows user, I would suggest "HxD" ( well, there is also "DD for Windows" ). HxD allows to edit the drive on sector basis and to directly write the file content to the drive. You can also create a drive image to backup its content, before you overwrite its Master Boot Record with my file.


I am used to dsfo/dsfi, part of the DSFOK:
http://members.ozema...ware/index.html

a dsfi command would be (example):

dsfi \\.\PHYSICALDRIVEn 0 0 c:\tmp\G4DOS.ISO

where n is the number of physical drive for the USB in windows (first disk is \\.\Physicaldrive0)

:thumbsup:

jaclaz

P.S.: just tested, G4DOS.ISO works allright in Qemu (used as first hard disk) :whistling:

#7 COD11

COD11

    Member

  • Members
  • 61 posts
  •  
    Germany

Posted 06 December 2009 - 10:52 AM

dsfi \\.\PHYSICALDRIVEn 0 0 c:\tmp\G4DOS.ISO

where n is the number of physical drive for the USB in windows (first disk is \\.\Physicaldrive0)

No need to guess. Just copy the following code to "Start -> Run" :
cmd /c wmic diskdrive get name & echo Plug in USB stick and press any key & echo. & pause > nul & wmic diskdrive get name & echo Which line is new ? & echo. & pause

Regards
COD11 :thumbsup:

#8 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7,100 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 06 December 2009 - 11:47 AM

No need to guess. Just copy the following code to "Start -> Run" :

cmd /c wmic diskdrive get name & echo Plug in USB stick and press any key & echo. & pause > nul & wmic diskdrive get name & echo Which line is new ? & echo. & pause

Regards
COD11 :thumbup:

WHO is guessing? :thumbup:

With all due respect :cheers: we are a bit ahead of that. :smart:
http://www.911cd.net...o...22273&st=26
http://www.911cd.net...o...22273&st=27
(without using WMIC)

However I like your approach :whistling: :
@ECHO OFF

ECHO Please connect a USB device and press any key...&PAUSE>nul

FOR /F "tokens=2 delims=E" %%? IN ('wmic diskdrive get name') DO (

SET You added drive=\\.\PhysicalDrive%%?

)

SET You added drive

PAUSE

(Last added drive is last drive in "wmic diskdrive get name") :thumbup:

:thumbsup:

jaclaz

#9 COD11

COD11

    Member

  • Members
  • 61 posts
  •  
    Germany

Posted 07 December 2009 - 12:13 AM

Hello,
I'm just surfing with "pmagic-4.6.iso" (resp. its Firefox browser), working from my USB pendrive, which also contains a working Windows 7 Repair ISO. I don't need to know any parameters ... and it works. "Parted Magic" has NO problems to find its squashfile, ... but only if it's the first ISO image on the USB Stick, which is no good news. The second and all further ISO images do NOT find external files, unless you use memory mapping or give them a storage location, where they can find their files (maybe the second partition). A (G4DOS) menu, which works from a CDROM must be inside the first ISO image to get all further ISO Images usable.

Regards
COD11

#10 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7,100 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 07 December 2009 - 08:34 AM

... but only if it's the first ISO image on the USB Stick, which is no good news. The second and all further ISO images do NOT find external files, ...


:whistling:

I had a look at the approach. It seems to me really nice, though I still have to do some experiments with it, to better understand it.

Some (completely trivial) news:
If you open the .iso in 7-zip the CD bootsector will "prevail", and you will see first .iso
If you open the .iso in Winimage the MBR will "prevail" and you are offered to access either the first EXT2FS partition or the FAT one.
VDK doesn't "like" it apparently. <- need to do more tests
IMDISK can connect to:
  • "Whole" CD ROM (read as first .iso)
  • First partition <-haven't checked thoroughfully as I don't have an ext2fs driver installed on this machine
  • Second partition
BUT for the latter two you need to specify device type (as otherways it will mount the .iso as CD-ROM drve and have no valid filesystem)

:whistling:

jaclaz

#11 COD11

COD11

    Member

  • Members
  • 61 posts
  •  
    Germany

Posted 07 December 2009 - 01:51 PM

First partition <-haven't checked thoroughfully as I don't have an ext2fs driver installed on this machine

There is no filesystem on first partition. There are only two ISO images, one after the other and the rest unallocated space up to the cylinder border, no FAT or other such structures. A valid filesystem (FAT12) is used on second partition, which might even be an extended partition. Filesystem ID 0x83 (Linux) is chosen, because it's unknown to Windows ( no drive letter assigned).

Regards
COD11

#12 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7,100 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 07 December 2009 - 02:45 PM

There is no filesystem on first partition. There are only two ISO images, one after the other and the rest unallocated space up to the cylinder border, no FAT or other such structures. A valid filesystem (FAT12) is used on second partition, which might even be an extended partition. Filesystem ID 0x83 (Linux) is chosen, because it's unknown to Windows ( no drive letter assigned).

Regards
COD11


Yep :thumbup:, I know, but Winimage can see the files in it :thumbup: (actually the ones in the first .iso) as if they were in the filesystem, let's call this "side effect" or "collateral damage", OK?
The effect for the "casual user" will be that he "connected" winimage to a Linux partition....:whistling:

:whistling:

jaclaz

#13 Icecube

Icecube

    Gold Member

  • Team Reboot
  • 1,047 posts
  •  
    Belgium

Posted 07 December 2009 - 03:11 PM

If you want more than one iso (dd-ed) on the drive, you need to store each iso in a separate partition, else Linux never will see the second, third, ... iso (unless you write a driver for it of course).

#14 COD11

COD11

    Member

  • Members
  • 61 posts
  •  
    Germany

Posted 07 December 2009 - 06:50 PM

If you want more than one iso (dd-ed) on the drive, you need to store each iso in a separate partition, else Linux never will see the second, third, ... iso (unless you write a driver for it of course).

This is clear, but Linux is my secondary concern ... or as jaclaz says "a collateral dammage" of my work. First concern is Grub4dos, of course. Yesterday, I had the same idea and put an ISO image on its own partition (fs ID 0x83). It seems, that a partition is not mappable, but a whole drive (or a file representing a whole drive). G4dos does it however without fault message, but shows whole drive (1st ISO image) as with (hd0). Linux wasn't able to mount such a device ("unknown filesystem", even with "-t iso9660"). It's not intended by me, to create an ISO repository for use from Linux distributions, but a bootable medium, which offers a choice at boot, what ISO image should start. Furthermore the ISO images should not need any customization to work this way (well, the first of course) ... and there should be a program or script, which gets the storage locations of a few ISO images as parameters or selection and composes automatically the wanted unified bootable ISO file.

#15 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7,100 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 08 December 2009 - 06:51 AM

Maybe a good old fashioned boot catalog .....:thumbsup:

http://sharktooth.or...s/bootable_cds/

jaclaz

#16 tinybit

tinybit

    Silver Member

  • Developer
  • 887 posts
  •  
    China

Posted 08 December 2009 - 10:30 AM

Yesterday, I had the same idea and put an ISO image on its own partition (fs ID 0x83). It seems, that a partition is not mappable, but a whole drive (or a file representing a whole drive). G4dos does it however without fault message, but shows whole drive (1st ISO image) as with (hd0).


Partitions should be mappable. But partition (hd0,0) of G4DOS.ISO is starting at sector 1 of the whole drive (hd0), compared to starting at sector 0 of (hd0). Thus, partition (hd0,0) is no longer of a valid iso9660 filesystem. So you may try again and adjust the starting-sector of partition (hd0,0) to 0, that is, starting at the MBR(!!!!), and if grub4dos complains, you may patch grub4dos and let it accept it.

The map of the partition is normal:

map --heads=0 --sectors-per-track=0 (hd0,0)+1 (hd34)

where (hd0,0)+1 (in the map command-line) stands for the whole partition of (hd0,0).

Also you may try to simply use this one:

map --heads=0 --sectors-per-track=0 (hd0)+1 (hd35)

or this one:

map --heads=0 --sectors-per-track=0 (hd0) (hd35)

And so, the virtual cdrom of (hd35) will be in valid iso9660 format.

Linux wasn't able to mount such a device ("unknown filesystem", even with "-t iso9660").


Your G4DOS.ISO can be mounted under my ubuntu 9.04:

mount -o loop G4DOS.ISO iso_tmp_dir

The files in the first iso image in G4DOS.ISO can be seen without any problem.

#17 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7,100 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 08 December 2009 - 01:07 PM

So you may try again and adjust the starting-sector of partition (hd0,0) to 0, that is, starting at the MBR(!!!!), and if grub4dos complains, you may patch grub4dos and let it accept it.


Yep. :thumbsup:

I was thinking of using the makebootfat "dual use" MBR/Bootsector for this.

But what I am guessing is the actual initial observation by COD11 is that the whole drive (having actually a CD Volume descriptor on sector 17CDFS i.e. 16*2048=32768 =64*512=sector 65 HDFS) is read as CD.

jaclaz

#18 COD11

COD11

    Member

  • Members
  • 61 posts
  •  
    Germany

Posted 08 December 2009 - 01:48 PM

@jaclaz :

Multiboot CD style may be a promising approach. But it's not quite clear, how to select the various ISOs at boot, unless a special BIOS does it. I 'll test it anyway.

@tinybit :
You are right concerning the fake first primary partition and the first ISO image on it. But this is not my problem. I tested a second ISO image on a fake (ID 0x83) second primary partition ... and could NOT mount it as CD. But besides that, it would never work from CD directly.

So you may try again and adjust the starting-sector of partition (hd0,0) to 0, that is, starting at the MBR(!!!!)

Isolinux/isohybrid uses sector 1 (block 0) as starting point for its fake 1st primary partition. I do NOT, because "parted" complains about a "recursive partition", "fdisk" shows a queer scheme and "GParted" shows the whole drive as unallocated space and refuses to create further partitions. G4DOS (hd0) as root just ignores first 64 sectors totally, so this doesn't matter at all.

COD11

#19 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7,100 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 08 December 2009 - 02:31 PM

Isolinux/isohybrid uses sector 1 (block 0) as starting point for its fake 1st primary partition. I do NOT, because "parted" complains about a "recursive partition", "fdisk" shows a queer scheme and "GParted" shows the whole drive as unallocated space and refuses to create further partitions. G4DOS (hd0) as root just ignores first 64 sectors totally, so this doesn't matter at all.

Well, you cannot use the excuse of being limited by the tools you have available. :whistling:

If the tools you use doesn't do what you want/need, change tools or make your own ones :whistling:.

jaclaz

#20 karyonix

karyonix

    Frequent Member

  • Advanced user
  • 434 posts
  •  
    Thailand

Posted 08 December 2009 - 05:09 PM

@jaclaz #19
I think COD11 doesn't like having partition start at sector 1 (LBA 0) not because of lack of tool but because it has only adverse effects and no benefit.

#21 COD11

COD11

    Member

  • Members
  • 61 posts
  •  
    Germany

Posted 08 December 2009 - 06:29 PM

... because "parted" complains about a "recursive partition", "fdisk" shows a queer scheme and "GParted" shows the whole drive as unallocated space and refuses to create further partitions.

Sorry, my statement could be misunderstood. With sector 2 (block 1) as starting point, all mentioned tools are content, no fault messages or complaints as with isolinux. Thanks to karyonix, who cleared this.

#22 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7,100 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 08 December 2009 - 07:31 PM

@jaclaz #19
I think COD11 doesn't like having partition start at sector 1 (LBA 0) not because of lack of tool but because it has only adverse effects and no benefit.


... because "parted" complains about a "recursive partition", "fdisk" shows a queer scheme and "GParted" shows the whole drive as unallocated space and refuses to create further partitions.

Sorry, my statement could be misunderstood. With sector 2 (block 1) as starting point, all mentioned tools are content, no fault messages or complaints as with isolinux. Thanks to karyonix, who cleared this.


Thanks to karyonix my sock! :whistling: (with all due respect :thumbup:), I see some logical/lexical issues, of course nothing actually relevant, but :cheers::

Hypothesis:
  • Bios xxx yyy does not boot is a reason. (adverse effect) :cheers:
  • VM zzzz does not boot is a reason. (adverse effect) :thumbup:
  • Bios www that boots only FDD fails to boot anyway is a reason (no benefit)
  • ....

COD11 "does not like" is a (perfectly understandable :thumbup: ) preference.

"fdisk" and "GParted" don't work properly is whining. :smart:

:whistling:

jaclaz

P.S.: Back to work.
Useful links (verified):
http://web.archive.o...8936/index.html
http://web.archive.o...e/8936/use.html
http://web.archive.o...36/MULTICAT.BIN
http://hp.vector.co....d/mkbtcd102.zip

MISSING IN ACTION:
http://www.geocities...8936/makebt.zip
DEAD and NO worky cache in The Wayback Machine. :thumbup:

FOUND, see below. B)

#23 Icecube

Icecube

    Gold Member

  • Team Reboot
  • 1,047 posts
  •  
    Belgium

Posted 08 December 2009 - 07:43 PM

The ISOLINUX
A topic on the Gparted forum aobut the ISO-Hybrid format (ISOLINUX) which explains the problem with LBA 0 as starting point for its fake 1st primary partition:
http://gparted-forum...ic.php?id=13581

fdisk (linux version) may display some bogus partitions, but you can create a second partition just fine with fdisk and format it with mkfs.*
I have done this a half year ago and it did work.

This is what the developer of Syslinux says about this problem:

>>> Using the default offset 0, parted will complain about a recursive
>>> partition and will be unable to do any further work on a USB device that
>>> uses an isohybrid image created with offset 0.
>>> Setting offset to 1 will fix this.
>>
>> I will not make this the default. Rejected.
>>
>> -hpa
>
> I know it is already rejected, but here is the full explanation by cmdr about the problem:
> http://gparted-forum...ic.php?id=13581
>
> Just if anyone is interested in this topic.
>

The reason I will not make this the default is that it makes it much
harder to use the remaining space on an isohybrid disk for other uses,
since one has to mount the full device to get to the iso9660 filesystem.

Arguably the Right Thing is to add an option to the iso9660 filesystem
driver in the Linux kernel, so that it can handle partition numbers with
an offset. The only other option is to have to copies of the iso9660
metadata, one for partition use and one for hybrid use, but I would
really rather like to avoid that.

Further complicating it is that there are people who want to be able to
run with a hybrid iso9660 filesystem written to a *partition*, which we
currently do support, but which complicates things further.

-hpa

http://syslinux.zyto...ber/013572.html

#24 tinybit

tinybit

    Silver Member

  • Developer
  • 887 posts
  •  
    China

Posted 09 December 2009 - 08:31 AM

Consideration of Yet Another Kind Of Isohybrid

Offset Length ISO =>Harddrive

000000 007E00 unused =>beginning track led by MBR

007E00 000200 unused =>FAT boot sector of first primary partition &#40;hd0,0&#41;

008000 005800 Volume Descriptors =>FAT extra reserved sectors&#40;data unused by FAT&#41;

				boot catalog

				root dir of cd

00D800 010000 dummyfat =>Two FATs

01D800 002800 dummydir =>Root Dir and optionally any other subdirs

020000 ------ real data area for other files on cd =>data area for FAT filesystem

dummyfat and dummydir are files with the needed size. the 2 dummy files together with other files such as grldr and menu.lst should be placed in your iso_root directory.

next, run mkisofs to create the iso, make sure dummyfat comes first followed by dummydir followed by other files(grldr, menu.lst, etc.).

now the iso should be hexedited(or maybe you would find other ways to do this) for a valid FAT filesystem on the partition. Fill in items in dummyfat with FAT entries. Fill in items in dummydir with entries for FAT root dir and any other subdirs. All done. Note that by now only one copy of files(grldr, menu.lst, etc.) is on the media(i.e., the ISO). The files are shared by both iso9660 and FAT filesystems.

Note that you may also place grldr.mbr on the MBR track, and even may create BPB on the MBR. Optionally refer to "triple mbr" discussed elsewhere.

#25 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7,100 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 09 December 2009 - 08:37 AM

Consideration of Yet Another Kind Of Isohybrid

Yep :thumbsup:.
That's more or less what I had in mind. :whistling:

jaclaz




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users