No replies to this topic

[deomsh]

Reply to: Wonko the Sane

Posted 22 hours ago

Good.

Since you are not (anymore) tight on space, personally I would try using a (second) copy of grub.exe, named (say) elgrub.exe with its internal (embedded) menu.lst modified with the grub4dos commands you now use.

This way you avoid the et.bat, the menu.lst/menu.new and the deleting/renaming of them.

If you want to keep just the grub.exe, I cannot see why you cannot point the -config-file in et.bat to a dedicated file (your menu.new) and leave the et.bat and menu.new alone.

Also worth a try (IMHO) is to use in et.bat directly the commands in -config-file parameters (instead of the external menu.lst), this usually works, but has to be seen if it works with your commands.

But (another possibility) why not making the superfloppy directly booting to grldr (again with the embedded menu.lst modified and renamed[1] to - say - elldr)?

This way you don't need to boot to dos to run grub.exe to have it reload dos.

About identifying the device (0xe0) there may be some (obscure) method peeking in grub4dos memory, but unofficially (0xe0) has been called "BIOS loaded CD device", so it makes sense:

http://reboot.pro/in...showtopic=17911

Wonko

[1] though officially frowned upon, it should be possible, or at least it was possible until a few versions ago, needs to be tested.

P.S. Also, something in COSMIAS may be useful?

http://reboot.pro/to...-to-g4d-images/

 

--------------------------------------------------------------------------------------------

deomsh' Reply

--------------------------------------------------------------------------------------------

 

About ET.BAT

 

I first started with A:\GRUB.EXE --config-file="map --floppies=2 ; map --mem (0xe0)26+17280 (fd0) ; map --hook ; root (fd0) ; chainloader /io.sys"

 

When more lines didn't work, I remembered the max number of chars is about 80. So I made other choices.

 

But according to the README_GRUB4DOS.txt this is the max in case of the INSTALL command, so maybe I should have used DEVICE command in CONFIG.SYS instead (4KB max, never tried).

 

I agree renaming is not desirable, I use ET.LST now with some tricks to 'activate' other lines in CONFIG.SYS/ AUTOEXEC.BAT - grubutil fat not needed anymore. Print-screens of Notepad++ are needed to see what I have made. works like a charm.

 

 

BTW changing to REM in AUTOEXEC.BAT is not needed, but first it didn't work with cat --locate=\x20 --replace=; number=1 /AUTOEXEC.BAT > nul  it took me a while to find my error .

 

About grldr:

 

There are other possibilities, but my final goal is to have the Virtual Box 7 workaround. For many reasons I always in MS-DOS first, and start grub4dos manually from the DOS command-line if needed.

 

Sometimes I have to test an adjusted GRLDR (like yaya's test version with retval64 - grub4dos 2022-10-26 and later versions), but I only succeed installing grldr.mbr.

 

About (0xe0):

 

Thanks for confirmation. I did a quick search before on reboot.pro, but missed that part of the post. Afterwards I did a long search on (0xe0) and (hd96) but there is not much. I nowhere find something like my map --mem (0xe0)26+17280 (fd0) setup. Is it tried before and maybe 'lost' (i.e. only to get with the Wayback machine)?

 

About COSMIAS:

 

Interesting, but is it possible with a PBR too, or should I try with El Torito 0x4 ?

 

Postscript

 

I found ImDisk had problems to mount 3840K floppy at Windows' startup (3840K floppy is not in the specs of ImDisk too). Also I found ImDisk' startup mounting in the Registry only, so I had to change some keys to get rid of the old startup mountings.

 

I used following workaround with two cmd's + LNK's in StartUp (one cmd will be possible too):

 

Floppy_B: imdisk -a -f D:\3840F12B.IMG -b 0 -s 3932160 -o fd -m B:

 

ISO_F: imdisk -a -f D:\34560S36.ISO -b 53248 -s 35389440 -o hd -m F:

 

BTW with -o hd ImDisk will map the 34560K floppy part inside the ISO to a hard drive. So I can reactivate my physical floppy drive .

Unmounting with imdisk -D -m drive-letter: is handy too. Also if I mount/ unmount from context-menu I always have to deal with User Account Control, in case of cmd's not - but maybe unsafe.

P.S.S.

Just found out semicolon should be working in CONFIG.SYS only, it seems in AUTOEXEC.BAT REM is the only remark method. So I am on the road. Because GRUB.EXE is the first line in AUTOEXEC.BAT, others lines will not be executed.

 

I tested AUTOEXEC.BAT without the semicolons, looks good after booting to IO.SYS with grub4dos:

 

[Wonko the Sane]

I don't think anyone used a .iso to map only a part of it via the BIOS features for el-torito emulation, otherwise the device should be mapped to a (cd) device, this approach is unconventional.

 

The COSMIAS approach needs a "usable" first sector, a PBR is not, both a hd-like (partitioned) image can do (with 446 bytes length limit for the grub4dos batch) or a .iso image (with no limits in practice as first 16 sectors of 2048 bytes each are empty/unused anyway).

 

You don't really need a hd emulation iso (0x4), as in the case of a .iso you have more than enough space.

 

I made at the time a "demo" defrag image:

http://reboot.pro/in...=17807&p=168095

(this is an unbootable, very small, partitioned image)

 

and an "install syslinux" one:

http://reboot.pro/in...showtopic=17945

 

which you can test, though cannot say if the approach can be useful in your case/use.

 

Only for the record, once said that REM is the canonical way to comment in batches, double colon :: is often better (REM lines are parsed anyway, while :: are skipped, this makes very long and heavily commented batches faster), technically the line becomes an invalid label, and you can use (if needed) some other invalid characters after first colon:

 

https://stackoverflo...dos-batch-files

 

https://www.robvande...om/comments.php

 

Wonko

[deomsh]

I had a nice time with the COSMIAS approach. It's working!

 

Although my setup with 34560S36.ISO is already mounted, I used the idea of transplanting a grub4dos batchfile, I already made, to the start of the ISO.

I believe in your ISOHDRXXX's there is a 34K start consisting of zeros. My current script transplanted is 1089 byte. Is there a maximum, or will 34K be okay too?

 

In between I changed my setup by transplanting the fat12/fat16 boot code from grldr.pbr to my own boot sector used with El Torito. With my current MENU.LST I can set default to:

0 if I want to boot into MS-DOS

1 if I want to boot into grub4dos after safely mapped the 34560K superfloppy used with El Torito

--------------------------------------------------------------------------------------------------
MENU.LST
--------------------------------------------------------------------------------------------------
timeout  0
default 0

title map --mem (0xe0) to (fd0) + reset menu.lst & boot (fd0)
map --floppies=2 > nul
map --mem (0xe0)26+17280 (fd0) > nul
map --hook
raw dd if=(fd0)/34560ET.BIN of=(md)0x300+1 > nul
raw dd if=(md)0x300+1 of=(fd0)0+1 > nul
cmp (fd0)/34560ET.BIN (fd0)0+1 > nul && echo Bootsector of (fd0) successfully changed to 34560ET.BIN ! echo Bootsector of (fd0) NOT changed to 34560ET.BIN &; echo
root (fd0) > nul
cat --locate=timeout\x20\x200 --replace=timeout\x2060 --number=1 /MENU.LST > nul
cat --locate=default\x200 --replace=default\x201 --number=1 /MENU.LST > nul
cat --locate=\x0D\x0Atitle\x20map --replace=\x0A\x23title\x20map /MENU.LST > nul
chainloader ()+1 > nul

title map --mem (0xe0) to (fd0) + reset menu.lst & boot (fd0) I
map --floppies=2 > nul
map --mem (0xe0)26+17280 (fd0) > nul
map --hook
root (fd0) > nul
cat --locate=default\x201 --replace=default\x202 --number=1 /MENU.LST > nul
chainloader ()+1 > nul

title map exchange GRLDR bootsector for MSWIN4.1 + reset menu.lst II
raw dd if=(fd0)/34560ET.BIN of=(md)0x300+1 > nul
raw dd if=(md)0x300+1 of=(fd0)0+1 > nul
cmp (fd0)/34560ET.BIN (fd0)0+1 > nul && echo Bootsector of (fd0) successfully changed to 34560ET.BIN ! echo Bootsector of (fd0) NOT changed to 34560ET.BIN &; echo
root (fd0) > nul
cat --locate=timeout\x20\x200 --replace=timeout\x2060 --number=1 /MENU.LST > nul
cat --locate=default\x202 --replace=default\x201 --number=1 /MENU.LST > nul
cat --locate=\x0D\x0Atitle\x20map --replace=\x0A\x23title\x20map /MENU.LST > nul
configfile /GRUB/MENU.LST

title commandline
map --floppies=2
commandline

title commandline + set-path=(fd0) + set-ext=.g4b
map --floppies=2
command --set-path=(fd0)
command --set-ext=.g4b
root (fd0)
commandline

(etc....)
--------------------------------------------------------------------------------------------------

BTW configfile /MENU.LST didn't work during GRLDR boot, so I used configfile /GRUB/MENU.LST - same MENU.LST but without the first three titles. If GRUB.EXE is called from the DOS command-line everything is fine.

 

Also *somehow* map --mem --unsafe-boot is not needed, as I used during experimenting with image file GRLDRBAT - copied to a (virtual) hard disk, to test the COSMIAS approach:

 

 

Thanks changing chainloader /io.sys to chainloader ()+1 Limbo X86 PC Emulator didn't go into a full reboot. Don't know why...

 

Print-screen of booting into MS-DOS:

 

 

This is how changes to /MENU.LST looks afterwards:

 

 

I used (parts) of the COSMIAS approach to save my drive-mapped-to-memory to file, maybe in a less conventional manner :

 

There are two platforms to run the batch and shutdown:

 

1) with option in MENU.LST (with Esc first, if needed to leave the grub4dos commandline):

 

title Backup (fd0)1+69119 to (hd4,0)/34560S36.IMG + halt
call (0xe0)0+16
halt

2) calling from the MS-DOS command-line with HALT.BAT: A:\GRUB.EXE --config-file="call (0xe0)0+16 ; halt"

-------------------------------------------------------------------------------------------------
CONTENT of bytes 0x0-0x441 in 34560S36.ISO
-------------------------------------------------------------------------------------------------
!BAT
#-#+ COPYA2IMG.G4B v0.2 (20230715), by deomsh
#-#+ Function: copy FILE1 to FILE2 
###debug 3
setlocal
if not exist (hd4,0)/34560S36.IMG && echo (hd4,0)/34560S36.IMG not exist && goto :eov
set /p /u "docopy=copy (fd0)1+69119 to (hd4,0)/34560S36.IMG (N=no, Y=yes)? >" && echo
###pause docopy=%docopy% Key...
if not %docopy%==Y && echo $[0x0F] Abort copying by user && goto :eov
set c=1
:copya2imgloop
set copyok=
raw dd if=(fd0)1+69119 of=(hd4,0)/34560S36.IMG seek=1 > nul ;; set /a copyok=%@retval% > nul ;; echo copyok=%copyok%
if %c%<=3 && if %copyok%==0 && set /a c=%c%+1 > nul && goto :copya2imgloop ! if %copyok%==0 && echo Abort: copy FAIL! && goto :eov
set c=1
:cmpa2imgloop
set cmpok=
cmp --skip=512 (fd0)0+69120 (hd4,0)/34560S36.IMG > nul ;; set /a cmpok=%@retval% > nul ;; echo cmpok=%cmpok%
if %c%<=3 && if %cmpok%==0 && set /a c=%c%+1 > nul && goto :cmpa2imgloop ! if %cmpok=0 && echo Abort: copy BAD! && goto :eov
echo $[0x0F](fd0)1+69119 successfully copied to (hd4,0)/34560S36.IMG
goto :eov

:eov
echo $[0x0F]Press a key to continue.... && pause
-------------------------------------------------------------------------------------------------

Print-screen of running the batch after call (0xe0)0+16:

 

 

Of course this is all a first start, can be (and will be) endlessly refined .

[Wonko the Sane]

Sure it works.

 

My doubt was whether it would have been useful for your use.

 

The ISO9660 standard puts the first 16 sectors as "not used", so you have 16x2048=32768 bytes that will never be read (by the standard complying tools/programs/etc.) and that you can use as you want:

 

https://en.wikipedia..._9660#Top_level

 

This is what is used in many so-called iso-hybrid images that are rather common in the Linux world, a same file can be burned on CD/DVD or to a block device such as a USB stick and it will work the same, to the first sector of the .iso it is written a MBR pointing to the volume that is also indexed by the normal ISO 9660 structures.

 

You can still have the MBR (without code) and the grub4dos batch at the same time, as long as this latter is shorter than 446 bytes. 

 

In theory (but it would have to be tested) you can "punch" two holes in the !BAT on first 512 bytes with #, one for the 16 bytes of first partition table entry at offset 446 and one for the two magic bytes at offset 510 so that you can have at the same time the MBR data to map the volume and the grub4dos batch longer than 446 bytes, i.e. it should be possible to embed the partition table in the (longer) batch.

 

Wonko

[deomsh]

For now the A and S of COSMIAS are useful to me, I already have almost all the parts that resided earlier in MENU.LST in a batch inside the ISO. Or can such a method be categorized as a COSMIAS' approach too?

I tried to make my ISO hybrid.
A remark before the first MBR entry didn't work, in the end I found a workaround with a 442 byte batch before the first MBR entry, and a second batch starting at 0x200.

Good to now about the 32KB, although your (?) ISOHDR's have 34KB before the CD001. I can use the whole 34KB without problems so far. I even made an extra hdd-PBR at 0xCE00.

[Wonko the Sane]

Very likely that is because the ISOHDR (not mine, it comes from the good guys at menuetos):

 

http://reboot.pro/in...ic=9916&p=86679

 

has no actual ISO volume at all and that extra sector would be the volume descriptor for that non-existing volume.

 

You should not anyway use beyond 32768.

 

Wonko

[deomsh]

Thanks for the info.

 

Sad I should not use the extra 2KB.

 

My current first batch of 442 bytes is:

!BAT
#ET1 v0.1
setlocal
debug 1
set md=(md)0x3000
echo -n > %md%+128
map --mem --unsafe-boot %md%+128 (fd100) > nul
map --hook
raw dd if=(0xe0)0+26 of=(fd100)0+128 bs=1 count=0x7000 skip=0x1800 > nul
insmod (fd100)/fat || echo No (fd100)/fat && goto :e
fat mkfile size=4608 (fd100)/ET2
raw dd if=(0xe0)0+3 of=(fd100)/ET2 bs=1 count=4608 skip=512 > nul
if exist (fd100)/ET2 || echo No (fd100)/ET2 && goto :e
call (fd100)/ET2 %*
:e
debug msg=3

Of course I can use grubutil fatmini, but then I loose function fat info I use to find if there is enough space to backup the El Torito floppy on a found FAT-disk (I use find | call :findfreefatdev), during second run of (0xe0)0+1 with ET2.

 

Another option is to use fat from the El Torito boot disk, but that's less safe in my opinion.

 

How bout my question of my project can bee seen as a COSMIAS approach?

I asked this because I started a project on Github with current About: 'COSMIAS grub4dos script to map El Torito boot disk to writable disk, with bootmenu to boot msdos or grub4dos' (and in that case I can honour you as founder of the COSMIAS approach) .

[Wonko the Sane]

Philologically, since COSMIAS is the acronym for Container Of Self Mounting Image (And Stuff), if your image is not self mounting it shouldn't count.

 

Nothing prohibits from making it mean something else, though.

 

Container Of Slick Msdos Image And Stuff?

 

I think it could be better to invent another acronym.

SINAI Superfloppy Image Not An Iso

 

or maybe better:

 

SIGMAS Superfloppy Image Grub4dos Managed And Stuff

 

No real need to cite me at all, however, the whole COSMIAS is just an idea thrown on the table, being cheap (and old and grumpy) I simply couldn't stand the waste of a few bytes .

 

Wonko

[deomsh]

As a holiday project I am working on a script to create hybrid iso's. I have some questions however.

 

Current outline of the project (sorry, no code boxes on Android/ Firefox):

=========================================================================================

:help

echo MKISOHYB.G4B v0.1.1 (20230809), by deomsh echo Function: Make no emulation ISO HYBRID on existing harddisk or file with GRLDR boot (with one existing second primary fat partition: max 4GB only); or 1-4 emulation without GRLDR

echo Use 1: MKISOHYB.G4B --emul[ation]=0-4 [--startsector=cd-sector] [--etsector=cd-sector] SOURCE TARGET [/Q]

echo Use 2: MKISOHYB.G4B --emul[ation]=0-4 [--startsector=cd-sector] [--etsector=cd-sector] --size=bytes|--sectors=N TARGET [/Q]

echo Remarks: echo Mandatory:

echo SOURCE is El Torito image, or image booted without emulation

echo $[] Obligatory: DISK or FILE (blockdevice or with full device and path) echo $[] File system FAT only. No partition allowed

echo With '--size=bytes|--sectors=N' FAT disk on TARGET created (without SOURCE)

echo $[] Created FAT: FAT12 up to 16MB, FAT16 up to 512MB, above FAT32 (max ~ 4GB)

echo $[] With 'bytes' of 'N' k, m and g allowed echo TARGET is DISK or FILE (blockdevice or with full device and path). No partition allowed. Existing target overwritten

echo Switch '--emul[ation]=0-4': 0=no emulation with GRLDR; 1=floppy max 14MB (h2, s15); 2=floppy max 18MB (h2, s18); 3=floppy max 36MB (h2, s36); 4=harddisk max ???MB (s63)

echo $[] With no emulation GRLDR must be in same folder as MKISOHYB.G4B

echo $[] With emulation=0/ s15-floppy: size rounded on 5040 sectors, except ...

echo $[] With emulation=0/ s18-floppy: size rounded on 1008 sectors, except ...

echo $[] With emulation=0/ s36-floppy: size rounded on 1008 sectors, except ...

echo $[] With emulation=0 harddisk size rounded on 1008 sectors, on .... above ....

echo $[] With emulation=1-3 NO hybrid iso made!

echo $[] WATCH: With emulation=1-3 file system FAT32 not possible

echo $[] WATCH: with emulation=0 or emulation=4 bootable disk is always on second partition (hdx,1)

echo $[] WATCH: with emulation=4 on some systems only two hard disks left, (hd0,0) is El Torito disk and (hd1,0) shifted (hd0,0)

echo Optional: echo Switch '--startsec=cd-sector': start sector of (El Torito) image (in 2KB sectors) minimum 19??

echo Switch '--etsector=cd-sector': location of El Torito specs (in 2KB sectors), minimum 18 echo Switch '/Q' for quiet operation (returns 'result=1' if succes, '0' if failure

echo On hybrid ISO's CHS/ LBA values are always balanced (rounding down)

echo On hybrid ISO's header is 1008 sectors of 512 bytes. Otherwise minimum 18 sectors of 2048 bytes

echo Example: MKISOHYB.G4B --emul[ation]=1 (fd0) (hd0,0)/12600S15.ISO

echo Example: MKISOHYB.G4B --emul[ation]=2 --startsector=26 (hd0,0)/FLOP_S18.IMG (hd0,0)/35400S18.ISO

echo Example: MKISOHYB.G4B --emul[ation]=3 (fd1) (hd0,0)/36400S36.ISO

echo Example: MKISOHYB.G4B --emul[ation]=4 --etsector=1007 (hd1,0) (hd0,0)/HDD_S63.ISO

echo Example: MKISOHYB.G4B --emul[ation]=0 (hd0,0)/FD_OR_HD.IMG (hd0,0)/MULTIHYB.ISO

echo Example: MKISOHYB.G4B --emul[ation]=0 (hd0,0)/FD_OR_HD.IMG (rd)

echo Example: MKISOHYB.G4B --emul[ation]=0 (hd0,0)/FD_OR_HD.IMG (md)0x30000+0x10000

echo Example: MKISOHYB.G4B --emul[ation]=0 (hd0,0)/FD_OR_HD.IMG (hd3)

echo Example: MKISOHYB.G4B --emul[ation]=0 --sectors=32k (hd0,0)/MULTIHYB.ISO

echo Example: MKISOHYB.G4B --emul[ation]=0 --size=128m (hd0,0)/MULTIHYB.ISO

echo Example: MKISOHYB.G4B --emul[ation]=0 --sectors=256k (hd0,0)/MULTIHYB.ISO

echo Example: MKISOHYB.G4B --emul[ation]=0 --size=4g (hd0,0)/MULTIHYB.ISO =========================================================================================

 

My questions:

 

1) According to the El Torito specifation it seems only the CD001 entry on 0x8800 is mandatory. I wonder if there is a minimum ISO-header size? For now I think the 16 empty sectors + one volume descriptor on 0x8000 + second (El Torito) volume descriptor on 0x8800 = 18 cd-sectors minimum?

 

2) I found *somewhere* the maximum attached partition is 4GB (including header size). Is this true?

 

BTW max emulation floppy sizes wrote down from memory, can not reach msfn.org...

[Wonko the Sane]

Not sure to understand (actually pretty sure I don't understand)..

 

When you make a iso hybrid, you use an existing, normal, iso, made by one of the suitable tools (let's say mkisofs), then you add to the first sector a MBR (or some other booting code), but you are not limited to "just" a MBR because you have available 16 sectors, 2048 bytes each.

Then follows 2 sectors, of which the last one is mandatory, so yes, the bare minimum is 18 sectors.

Then there are more sectors written by the iso making tool.

 

But what you are doing is seemingly something else, a hybrid non-iso (what the good Menuet OS guys did) or - possibly - something else (which I don't understand).

 

The 4 GB limit is (more or less) the same as the one in FAT32 (2^32-1), but I wonder as well what has to do with this (as you don't have a real ISO, only the header for it, without a CDFS (or UDF) filesystem.

 

In any case I cannot also imagine any reason for a hard disk emulation ISO with added a hybrid MBR (or other bootable code).

 

I am completely failing to see any use for these.

 

Wonko

[deomsh]

Thanks a lot!

 

Reading your comments it seems your 'iso' MUST include a CDFS or UDF filesystem. 

 

I My (current, maybe simplified/ crippled/ naive/ (....) - as you like) idea, an iso is an image that can mounted as an iso. 

 

II With an El Torito Booting Catalog and some bootcode, the iso can be used to boot in some virtualalized computer, with or without emulation of floppy/ hard disk. 

 

III If the iso contains a CDFS or UDF filesystem too, this can be read with the appropiate drivers (included in grub4dos or readily available).

 

IV In my idea an iso-hybrid will have some bootcode to boot the iso as a hard disk (if needed the iso must be renamed, depending on the demands of the virtualized environment). In this case the boot-code should find some bootable Partition Boot Record, at least to continue booting.

 

To get a (hopefully) universal approach, I envision following steps/ tools ('tools' as grub4dos scripts).

 

1) Writing a 'valid' iso-header with a valid El Torito Volume Descriptor and Boot Catalog with some Emulation Type.

 

2) Add a bootable image or a bootloader like GRLDR to the iso-header at the CD-sector, pointed to by the Default Boot Entry

 

3) Write a bootable Master Boot Record* to the iso-header, pointing to some bootable image inside the iso, with a non-CDFS/ UDF filesystem.

 

4) If needed/ demanded/ wished, it should be possible to add an existing CDFS or UDF filesystem to the iso. This must not be 'seen' in case of directly booting as a hard disk**.

 

Currently 'Steps 1-3' are working with 'dirty' use of a hex-editor in Windows, 'Step 4' not tried yet.

 

About the minimum size of an iso-header: included a Terminating Volume Descriptor and El Torito Booting 

 Catalog, I found needed is minimum 16 + 4 CD-sectors, so up to CD-sector 19. 

 

*According to my calculations most universal 'CHS/LBA/multiple-of-2KB balanced' hard disk startsector should be a multiple of 1008 sectors, up to 128 heads/ 63 sectors per track (different in case the image size is 'near' 4GB: 240/ 255 heads needed, etc.). Image-sizes should be (most of the time) also be a multiple of 1008 sectors (with some exceptions). Most desirable: the image can be used as a bootable (super-)floppy mapped to memory too - in case of a FAT-FS only a few changes to the bootsector needed (and to the Media Type in the fat(s) too).

 

** So far I found 'setups' with CD-ROM as first partition (without Partition ID) and the bootable image as second partiton.

[Wonko the Sane]

Sure, but what you propose is NOT a iso-hybrid, you must come out with some other name, or you will create a lot of confusion.

 

The original idea of emulation is to "delegate" to the computer BIOS the mapping of a certain area of the .iso to a floppy or hard disk "virtual" device.

 

The original idea of a iso-hybrid is that of having an image that can either be burned to CD/DVD or dd copied to a mass storage device such as a SD card or USB stick, and that essentially will behave the same no matter on which media it resides.

 

The original idea of the MenuetOS "isohdr" is (AFAICU) that of easily boot from a floppy image burned on CD/DVD without needind to create an actual .iso, i.e. without needing to run mkisofs or similar.

 

All of these have some practical use.

 

In your setup, the moment you manage (in *whatever* way) to load grub4dos, it can effectively integrate the emulation part, and you don't need a CDFS or UDF filesystem at all, you can have  (say) a FAT volume/partition (on a contiguous extent) and map it to *whatever* device you like.

 

So, it can be a "normal" hard disk image with a "hole" to host the (minimum) needed iso structures and a floppy image.

 

When you boot the image as "hard disk" it is already a hard disk image.

 

When you boot the image as "iso" it can use the 2 iso sectors to leverage on the BIOS capabilities to boot as a floppy, what is booted is grub4dos that then takes over and remaps the whole stuff as hard disk. 

 

I don't see however any advantage/practical use for this, besides the fun of it, for all it matters, if you don't liek the floppy, you could also make a "normal" (empty) no-emulation .iso loading grub4dos grldr (with the embedded menu.lst suitably modified) then modify it appending to it a volume/partition image and writing to its first sector a MBR pointing to the appended volume. 

 

Wonko

[deomsh]

Thanks a lot for all information  .

I understand better why using 'iso-hybrid' can give confusion, so I will make changes accordingly. Also using some variation of 'isohdr' seems to broad, maybe my current project should be renamed to WRIETISO.G4B because writing an El Torito bootable iso-header is the common denominator. 

 

In my current 'dirty' setup I use already 'no emulation' to boot with GLRDR directly (with modified internal menu, default entry starting a batch inside the first 32KB of the El Torito iso-header). There are three choices: boot to grub4dos command-line, booting to a writable (super-)floppy, or a writable hard disk (last two 'based' on the same FAT-image inside the iso, mapped to memory and with some changes to the PBR after mapping).

 

My concern earlier was to save changes to an image, directly usable as new El Torito bootable image. I tried your idea to place a batchfile in sector 0 before the first partition entry, which was do-able (for me) if this batch started a second batch after (CD-)sector 0.

 

I left this 'saving approach' because I found out in Virtual Box the same iso renamed to '.hdd' can be mounted parallel  to the iso (at least with FAT12). So saving changes on the image-in-memory became much easier (during booting the uuid of the FAT-image is slightly changed already). Also it should be *somehow* possible to burn this iso on a CR-ROM, or write to USB  .

 

Practical? I started all my pojects from a practical need. Only during a project I tend to 'see' more possibilities (which can be 'fun')  .

 

In this case to mount and boot to/ from a superfloppy (so above 4MB) with Virtual Box (using El Torito iso-booting and grub4dos). 

Or did you mean using El Torito to boot an iso (or a real CD-ROM) is not practical  ?

[Wonko the Sane]

Real CD-Roms (and DVD's) are a dying breed, the use of .iso images might be practical (for VM's) but it doesn't seem (to me) to offer any particular advantages (besides their read only status) over a "normal" hard disk image (or to boot some form of superfloppy, which also is, in my view, more "fun" than "practical").

 

Of course it being "fun" is in itself a more than sufficient reason  .

 

At which point (once established that you are having fun) you can use (and abuse) my underfloppy approach (special MBR code with "hidden" partiion) at the time developed to boot GPT style disks on BIOS (making use of grub4dos), again, only an idea/JFYI:

 

http://reboot.pro/to...-in-bios-to-gpt

 

http://reboot.pro/in...e=9#entry193659

 

and/or the following "floppy OFS" approach:

 

http://reboot.pro/in...e=9#entry193947

 

 (no idea if either can be of any use in your experiments).

 

 

 

Wonko

[deomsh]

Thanks a lot for new idea's/ links. Currently I don't use or need GPT, but it's always good to have something in reserve.

 

I have some problems with El Torito no-emulation boot. I tried to make a dual-boot setup for BIOS/ EFI-boot with GRLDR/ grub4efi. As such booting is working, but I do not understand were to place configuration files, i.e. menu.lst.

 

In between I made an El Torito Boot Catalog Viewer as part of my script, for easy experimentation.

In next print-screen you will see my current El Torito Boot Catalog in use:

 

 

BTW GRLDR and EFI/BOOT/BOOTX64.efi are separate, on two 600KB floppies I made (15 sectors per track). The 'Fake Primary Volume Descriptor' is needed for EFI-boot only.

 

 

In case of GRLDR-boot everything is fine if booting with emulation=1 (with GRLDR-bootcode in the PBR), root is (fd0) afterwards. With no-emulation booting I have to point directly to GRLDR (floppy starts at CD-sector 0x1A and GRLDR is on the floppy at 0x1E).

 

In case of (U)EFI-boot there seems no access to the ESP (Efi System Partition) after booting. Booting with emulation not possible in this case (no-emulation is mandatory according the UEFI-specs).

 

Somehow I expected that both menu.lst's would be read-out during boot from the (no-emulation) boot-floppies. But this is not the case: after booting they have to reset to there internal menu.lst's. GRLDR or Grub4efi are finding no other device than an (empty) iso-filesystem. If I duplicate the menu.lst's by 'burning' on the iso, for GRLDR in the root and for Grub4efi in directory EFI/GRUB/ everything is fine, but that's is not what I want (for now).

 

Is all this normal behavior? I am really desperate, 'fun' is something different for me .

[Wonko the Sane]

I am not sure to understand the issue.

 

With emulation you are delegating to the BIOS to mount a floppy or hard disk image.

 

With no-emulation you are delegating to the whatever you are loading (grldr in this case) to do whatever it see fits.

 

You can modify the embedded menu.lst in grldr to map an arbitrary extent on the device, cannot you?

 

Something (loosely) similar to what we have done in the "underfloppy" approach:

map (hd0)63+1985 (fd0)
map --hook
root (fd0)
chainloader /bootmgr
boot

Or maybe the (cd) or (0xFF) or *whatever* is limited in the access to sectors?

 

Wonko

[deomsh]

Thanks for all help, I believe what I wanted is impossible.

 

With your help I edited earlier GRLDR's internal menu.lst (grub4efi has also an internal menu.lst - but not fully at the end of the file, like GRLDR). My original plan was to write a sub-routine to patch internal menu.lst, but I prefer a more flexible solution.

 

After studying the El Torito specification more in detail I was quite impressed by the possibilties of a Boot Catalog with Multiple Boot-Image Configuration, but soon I learned the hard way this is a fata morgana - on Virtual Box and VmWare only the Default Boot Entry is booted. Also it seems almost all BIOS'ses support El Torito Single Boot-Image Configuration only. Only notable exception is dual boot with UEFI, because the UEFI-specs demands support of finding a Section with EFI-Platform, so in a Boot Catalog with Multiple Boot-Image Configuration.

 

I found a Russian tool 'bcdl150z.ima' which encapsulate a sort of El Torito Bootmanager. It gives a full read-out the Boot Catalog with Multiple Boot-Image Configuration, with exception of Section Entry Extensions (starting with value '0x44').

Sadly I found this tool is not compatible with grub4dos and also the cursor on the MS-DOS command-line was not fully normal during my tests.

 

My latest idea is to 'burn' redirection-menu.lst's to the ISO, together with a floppy image containing the full menu.lst's. I used 'folder2iso'. In the root of the ISO standard menu.lst for GRLDR. In EFI/GRUB/ on the ISO the menu.lst for grub4efi's BOOTX64.efi with same menu entry in standard menu.lst.

 

The Default menu-entry I used for testing purposes:

title load image to (rd) and configfile
find --set-root /FD2880.IMG
map --heads=2 --sectors-per-track=36 /FD2880.IMG (rd)
configfile (rd)/MENU.LST

BTW I used a 2880K floppy image with 36 sectors per track.

 

Of course (rd), or the whole image can be mapped to a floppy, say (fd2), for protection. Root can be set accordingly - currently I used simply (rd).

 

This seems to work for both GRLDR and BOOTX64.efi. See first two print-screens:

 

 

BTW I took just some image, so the other files are not important.

 

Also I can easily get write access to the floppy image REDIRECT.IMG if the *iso is renamed to *.hdd and mounted as hard disk. To have easy access to the right sectors on the ISO I noted them in an extra Section, using the Bios String and the bytes reserved for Vendor Information in the respective Section Entries:

 

 

BTW should be a valid Boot Catalog too, with exception of Section entry 3 of course (untested yet).

I tried to add some functionality to my script LIST.G4B to read-out images and block-lists (almost finished):

 

 

BTW it can be seen I rounded the two menu.lst's on the ISO at 4KB, so editing and copy back with dd should be possible. Also extra files on the two El Torito images seems to be useless now (only if GRLDR is booted with emulation, the menu.lst will be useful)

 

By the way, do you know any source with more, detailed information about El Torito's Section Entry Extension? In the specs are related settings in the Section Entry they should belong to, mentioned.

[Wonko the Sane]

I have no idea how Multiple Boot-Image Configuration is handled on current BIOSes, but it used to be a thing (though, as you found out, BCDL was sometimes needed).

 

The fact that is mentioned on Winiso that made a "special" image format for these, should mean that it still largely works? 

Or maybe, since the feature is not much used anymore, the good guys developing the BIOSes of VM's forgot about its existence?

 

About BCDL:

http://bootcd.narod.ru/index_e.htm

http://bootcd.narod.ru/bcdl_e.htm

 

it is a long, long time since I used it, but while it may well be incompatible with grub4dos AFAICR it never had any issues with "normal" DOS, in any case (no idea if it changes anything) there was a later version than 1.50Z, the 2.01a, which you can still find (courtesy of Dencorso) here:

https://msfn.org/boa...&comment=947812

 

I will try and look if I have (or can find) some detailed ISO/El-Torito/Boot Catalog related stuff, but don' tcount too much on it, I seem to remember a "simplified" ISO9660 guide, but really I cannot remember where it came from nor when I coulf have stored it.

 

Wonko

 

 

 

[deomsh]

I came across WinIso during my extended inter search. Their *bifx-format looks really interesting, but I found no examples if it is used for burning, or for saving images FROM an iso to a bifx-file.

 

I found somewhere QEMU does not support multiple images, no documentation in case of Virtual Box or WMware.

 

Only strange thing is that inside the Guest Additions file 'VBoxService.exe' there seems to support *somehow* full El Torito Multiple Boot-Image Configuration seeing following strings inside the file (watch the typo's too):

VERR_ISOMK_IMPORT_BOOT_CAT_ENTRY_CONTINUATION_EOS    A boot catalog entry in the import ISO sets the continuation flag when we reached the ned of the boot catalog secotr.
VERR_ISOMK_IMPORT_BOOT_CAT_ENTRY_CONTINUATION_WITH_NONE A boot catalog entry in the import ISO sets the continuation flag when using NONE as the selection criteria type.   
VERR_ISOMK_IMPORT_BOOT_CAT_EXT_ENTRY_END_OF_SECTOR  A boot catalog extension entry in the import ISO indicates more entries when we reached the end of the boot catalog sector. 
VERR_ISOMK_IMPORT_BOOT_CAT_EXT_ENTRY_UNDEFINED_FLAGS        A boot catalog extension entry in the import ISO uses undefined flags which will be lost.   
VERR_ISOMK_IMPORT_BOOT_CAT_EXT_ENTRY_INVALID_ID     A boot catalog extension entry in the import ISO was either flagged incorrectly in the previous entry or has an invalid header ID.  
VERR_ISOMK_IMPORT_BOOT_CAT_DEF_ENTRY_INVALID_BOOT_IND       The default boot catalog entry in the import ISO an invalid boot indicator value.   
VERR_ISOMK_IMPORT_BOOT_CAT_MISSING_FINAL_OR_TOO_BIG The boot catalog in the import ISO is larger than a sector or it is missing the final section header entry. 
VERR_ISOMK_IMPORT_BOOT_CAT_ENTRY_UNKNOWN_IMAGE_SIZE A boot catalog entry in the import ISO has an image with an indeterminate size. 
VERR_ISOMK_IMPORT_BOOT_CAT_ENTRY_IMAGE_OUT_OF_BOUNDS    A boot catalog entry in the import ISO points to a block after the end of the image input file. 
VERR_ISOMK_IMPORT_BOOT_CAT_ENTRY_USES_UNUSED_FIELD      A boot catalog entry in the import ISO is using the unused field.   
VERR_ISOMK_IMPORT_BOOT_CAT_ENTRY_RESERVED_FLAG  A boot catalog entry in the import ISO has reserved flag set.   
VERR_ISOMK_IMPORT_BOOT_CAT_DEF_ENTRY_INVALID_FLAGS  The default boot catalog entry in the import ISO has invalid flags set. 
VERR_ISOMK_IMPORT_BOOT_CAT_INVALID_BOOT_MEDIA_TYPE      A boot catalog entry in the import ISO has an invalid boot media type.  
VERR_ISOMK_IMPORT_BOOT_CAT_UNKNOWN_HEADER_ID    A boot catalog entry in the import ISO has an unknown type. 
VERR_ISOMK_IMPORT_BOOT_CAT_BAD_VALIDATION_CHECKSUM  The boot catalog validation entry in the import ISO has an incorrect checksum.  
VERR_ISOMK_IMPORT_BOOT_CAT_BAD_VALIDATION_KEYS  The boot catalog validation entry in the import ISO has incorrect keys. 
VERR_ISOMK_IMPORT_BOOT_CAT_BAD_VALIDATION_HEADER_ID     The boot catalog block in the import ISO has an incorrect validation header ID. 
VERR_ISOMK_IMPORT_BOOT_CAT_BAD_OUT_OF_BOUNDS    The boot catalog block in the import ISO is out of bounds

Thanks a lot for the v2.0a1 files: this version of 'bcdl.ima' is compatible with grub4dos. In Virtual Box I managed to use this image as Default Boot Entry on my test-iso: the full boot catalog can be used. I combined some print-screens with help of IrfanView:

 

 

BTW below left you can see the cursor is dos was the strange 'thing' I mentioned earlier, but does not seems to do any harm.

 

In VMware the iso won't boot with 'bcdl.ima' as Default Boot entry, but is taken as floppy:

 

 

BTW on VMware the dos command-line looks fully normal, so will be a Virtual Box 'thing'

 

But BCDL.BIN inside 'bcdl.ima' does not take a Section Entry Extension but repeats the string before:

 

 

Also BCDL.BIN  won't find non-bootable entries, starting with '00', but take them simply as some sort of End-of-Booting-Catalog-marker.

 

Post Script: BCDL.BIN does not seem to check the checksum inside the Validation Header. Virtual Box BIOS' is tolerant too, but in case of efi-boot the checksum must be valid. On VMware checksum must be valid always, but no problem if BCDL.BIN is boorted from the floppy image 'bcdl.ima'. Luckily i managed to write a sub-routing to calculate the ckecksum .

[deomsh]

I came across WinIso during my extended internet search. Their *bifx-format looks really interesting, but I found no examples if it is used for burning, or only for saving images FROM an iso to a bifx-file.

 

I found somewhere QEMU does not support multiple images, no documentation found for Virtual Box or VMware.

 

But I doubt 'the good guys developing the BIOSes of VM's forgot about its existence' in case of Virtual box. Inside their Guest Additions file 'VBoxService.exe' there *somehow* seems to be support of the full El Torito Multiple Boot-Image Configuration, seeing following strings inside the file (watch their typo's too ):

VERR_ISOMK_IMPORT_BOOT_CAT_ENTRY_CONTINUATION_EOS    A boot catalog entry in the import ISO sets the continuation flag when we reached the ned of the boot catalog secotr.
VERR_ISOMK_IMPORT_BOOT_CAT_ENTRY_CONTINUATION_WITH_NONE A boot catalog entry in the import ISO sets the continuation flag when using NONE as the selection criteria type.   
VERR_ISOMK_IMPORT_BOOT_CAT_EXT_ENTRY_END_OF_SECTOR  A boot catalog extension entry in the import ISO indicates more entries when we reached the end of the boot catalog sector. 
VERR_ISOMK_IMPORT_BOOT_CAT_EXT_ENTRY_UNDEFINED_FLAGS        A boot catalog extension entry in the import ISO uses undefined flags which will be lost.   
VERR_ISOMK_IMPORT_BOOT_CAT_EXT_ENTRY_INVALID_ID     A boot catalog extension entry in the import ISO was either flagged incorrectly in the previous entry or has an invalid header ID.  
VERR_ISOMK_IMPORT_BOOT_CAT_DEF_ENTRY_INVALID_BOOT_IND       The default boot catalog entry in the import ISO an invalid boot indicator value.   
VERR_ISOMK_IMPORT_BOOT_CAT_MISSING_FINAL_OR_TOO_BIG The boot catalog in the import ISO is larger than a sector or it is missing the final section header entry. 
VERR_ISOMK_IMPORT_BOOT_CAT_ENTRY_UNKNOWN_IMAGE_SIZE A boot catalog entry in the import ISO has an image with an indeterminate size. 
VERR_ISOMK_IMPORT_BOOT_CAT_ENTRY_IMAGE_OUT_OF_BOUNDS    A boot catalog entry in the import ISO points to a block after the end of the image input file. 
VERR_ISOMK_IMPORT_BOOT_CAT_ENTRY_USES_UNUSED_FIELD      A boot catalog entry in the import ISO is using the unused field.   
VERR_ISOMK_IMPORT_BOOT_CAT_ENTRY_RESERVED_FLAG  A boot catalog entry in the import ISO has reserved flag set.   
VERR_ISOMK_IMPORT_BOOT_CAT_DEF_ENTRY_INVALID_FLAGS  The default boot catalog entry in the import ISO has invalid flags set. 
VERR_ISOMK_IMPORT_BOOT_CAT_INVALID_BOOT_MEDIA_TYPE      A boot catalog entry in the import ISO has an invalid boot media type.  
VERR_ISOMK_IMPORT_BOOT_CAT_UNKNOWN_HEADER_ID    A boot catalog entry in the import ISO has an unknown type. 
VERR_ISOMK_IMPORT_BOOT_CAT_BAD_VALIDATION_CHECKSUM  The boot catalog validation entry in the import ISO has an incorrect checksum.  
VERR_ISOMK_IMPORT_BOOT_CAT_BAD_VALIDATION_KEYS  The boot catalog validation entry in the import ISO has incorrect keys. 
VERR_ISOMK_IMPORT_BOOT_CAT_BAD_VALIDATION_HEADER_ID     The boot catalog block in the import ISO has an incorrect validation header ID. 
VERR_ISOMK_IMPORT_BOOT_CAT_BAD_OUT_OF_BOUNDS    The boot catalog block in the import ISO is out of bounds

Thanks a lot for the v2.0a1 files: this version of 'bcdl.ima' is compatible with grub4dos. In Virtual Box I managed to use this image as Default Boot Entry on my test-iso: the full boot catalog can be used, if the Default Boot Entry is chosen the Boot Catalog will come up again.

 

I combined some print-screens with help of IrfanView:

 

 

BTW below left you can see the cursor is dos was the strange 'thing' I mentioned earlier, but does not seems to do any harm.

 

In VMware the iso won't boot with 'bcdl.ima' as Default Boot entry, but is taken as floppy:

 

 

BTW on VMware the dos command-line looks fully normal, so will be a Virtual Box 'thing'.

BTW2 I used the field of Vendor ID for a title, but I had to change temporarily the Default Boot Entry for use on VMware...

 

But BCDL.BIN inside 'bcdl.ima' does not take a Section Entry Extension but repeats the string before:

 

 

Also BCDL.BIN  won't find non-bootable entries, starting with '00', but take them simply as some sort of End-of-Booting-Catalog-Marker.

 

Post Script: BCDL.BIN does not seem to check the checksum inside the Validation Header. Virtual Box BIOS' is tolerant too, but in case of efi-boot the checksum must be valid. On VMware checksum must be valid always, but no problem if BCDL.BIN is booted from the floppy image 'bcdl.ima'.

 

Luckily i managed earlier to write a sub-routine to calculate the ckecksum .

[deomsh]

Update of FATINFO.G4B https://github.com/deomsh/FATINFO.G4B

 

Version 0.3
Bugfixes
Tests related too CHS/LBA (indicative)
Test of FSLastFree on fat32 (indicative, always PASSED)
Fatinfo on a blocklist
Switch for hex view of bootsector(s) and first sector of FAT1/FAT2

 

In print-screen new function is shown: using FATINFO.G4B on a blocklist to get access to the EFI bootimage on a Windows10.iso. The blocklist is showed in parentheses, in fact mapped to (rd). After use there is direct access to all files, showed with list -s (rd)/

 

 

If the blocklist starts with a MBR and contains partition(s), FATINFO.G4B can be used with switch --partitions=0-62 - in print-screen partition 0. To show what is going on in the background, FATINFO.G4B /T (test) is done on (rd,0) - *somehow* I found out (rd) takes partitions (no info on reboot.pro ):

 

 

BTW if partition number is unknown, or no success, first try with Wonko's tool: mbrview.g4b (rd)

[deomsh]

New release v0.4 https://github.com/deomsh/FATINFO.G4B

 

Bugfix: if volume name contains wrong FAT-version
Offset in bytes with argument '--skip=N'
DISK supported with arguments ''--start=sector|--skip=N' for offset
Argument '--partition=p' supported on FILE
Only mapping to (rd) with argument '--partition=p'
Better compatibility with grub4efi: argument '--partition=p' NOT supported

Partly detection of partition: 'volume' in output if not

 

BTW about grub4efi: while testing I found out a partitioned ram-disk is not supported. So grub4dos only!