access fdubcd.iso content from grub4dos

LABEL FDUBCD
LINUX /boot/syslinux/memdisk
INITRD /ubcd/images/fdubcd.iso.gz
APPEND iso raw

title FDUBCD\n
map --mem /ubcd/images/fdubcd.iso.gz (hd32)
map --hook root (hd32)
chainloader (hd32)

Try

Issue has already been reported http://www.ultimateb...pic.php?p=24354

I copied the contents of UBCD 5.1.1 ISO to a USB Flash drive and installed grub4dos (using RMPrepUSB).

Then booted it in QEMU and selected the UBCD FreeDos R1.44 (Based on NwDsk V3.40) entry

I was then given a Boot UMBPCI menu which I allowed to timeout

It then started unpacking files and finally gave me a pop-up box with Launch / NwDisk / Help / Browse options

Launch produces a 'no CD' error

NwDisk - List all drives lists A:  Q: and C:  (no T: drive which should be the virtual CD!)

If I then install Syslinux, Launch works and I get  a choice of CD applications - NwDisk lists T:

I then tried this entry

title FDUBCD WITH STEVE'S FIX!
map --mem /ubcd/images/fdubcd.iso.gz (0xff)
map --hook
root (0xff)
kernel /memdisk iso
initrd (bd)/ubcd/images/fdubcd.iso.gz 

title UBCD FreeDOS R1.44 (Based on NwDsk V3.40)\n FreeDOS boot disk used to run many of the other DOS apps on the UBCD. Revised\n version of Eric Veermans' FreeDOS NwDsk 3.40. Addresses many bug fixes,\n performance enhancements and compatibility issues. 
kernel /boot/syslinux/memdisk iso 
initrd (bd)/ubcd/images/fdubcd.iso.gz

Hmmm.

ady, can you specify the name and path of the .lst from which you took the grub4dos menu entry you posted?

There is IMHO little (of none at all) sense to load the whole ISO to memory.

Wonko

A better alternative is to get memdisk from the USB drive directly

Original HBCD entry in  \ubcd\menus\grub4dos\main.lst - does not find CD when FreeDos boots from ISO...

title UBCD FreeDOS R1.44 (Based on NwDsk V3.40)\n FreeDOS boot disk used to run many of the other DOS apps on the UBCD. Revised\n version of Eric Veermans' FreeDOS NwDsk 3.40. Addresses many bug fixes,\n performance enhancements and compatibility issues.
map --mem /ubcd/images/fdubcd.iso.gz (hd32)
map --hook
root (hd32)
chainloader (hd32)

title UBCD FreeDOS R1.44 (Based on NwDsk V3.40)\n FreeDOS boot disk used to run many of the other DOS apps on the UBCD. Revised\n version of Eric Veermans' FreeDOS NwDsk 3.40. Addresses many bug fixes,\n performance enhancements and compatibility issues.
kernel /boot/syslinux/memdisk iso
initrd (bd)/ubcd/images/fdubcd.iso.gz 

When booting fdubcd.iso from the syslinux/islonux menu, the entry (which works correctly) is:

LABEL FDUBCD
LINUX /boot/syslinux/memdisk
INITRD /ubcd/images/fdubcd.iso.gz
APPEND iso raw

When booting fdubcd.iso from the grub4dos menu, the entry (which boots fdubcd.iso correctly but doesn't allow the expected access to its content once in DOS) is:

title FDUBCD\n
map --mem /ubcd/images/fdubcd.iso.gz (hd32)
map --hook root (hd32)
chainloader (hd32)

 

title FDUBCD
  map --mem /ubcd/images/fdubcd.iso.gz (hd96)
  map --hook root (hd96)
  chainloader (hd96)

(hd96) does not work - still no CD...

 (0xff) or (0a0x) do not work either.

I also unzipped the ISO and tried this (no -mem)

map /ubcd/images/fdubcd.iso (hd96)
map --hook root (hd96)
chainloader (hd96)

./ubcd/menus/syslinux/main.cfg
./ubcd/menus/grub4dos/main.lst

title UBCD\n
map --mem /ubcd/images/fdubcd.iso.gz (hd32)
map --hook
root (hd32)
chainloader (hd32)

No, this is what I a m missing.

the ./ubcd/menus/grub4dos/main.lst in the copy of ubcd511.iso I have has these contents:

color cyan/black black/light-gray green/black yellow/black

title BIOS
configfile /ubcd/menus/grub4dos/bios.lst

title CPU
configfile /ubcd/menus/grub4dos/cpu.lst

title HDD
configfile /ubcd/menus/grub4dos/hdd.lst

title Memory
configfile /ubcd/menus/grub4dos/memory.lst

title Others
configfile /ubcd/menus/grub4dos/others.lst

title Peripherals
configfile /ubcd/menus/grub4dos/periph.lst

title System
configfile /ubcd/menus/grub4dos/system.lst

title UBCD FreeDOS R1.44 (Based on NwDsk V3.40)\n FreeDOS boot disk used to run many of the other DOS apps on the UBCD. Revised\n version of Eric Veermans' FreeDOS NwDsk 3.40. Addresses many bug fixes,\n performance enhancements and compatibility issues.
map --mem /ubcd/images/fdubcd.iso.gz (hd32)
map --hook
root (hd32)
chainloader (hd32)

title User-defined
configfile /ubcd/custom/custom.lst

title
pause

title Reboot\n Reboot the PC.
reboot

title
pause

title ISOLINUX/SYSLINUX menu\n This entry will bring you back to the ISOLINUX/SYSLINUX menu.
chainloader /boot/isolinux/isolinux.bin || chainloader +1

Let us for the moment assume that you have burned a "real" CD, the CD will be boot disk, and it contains /ubcd/images/fdubcd.iso.gz which is mapped to (hd32) i.e. to a grub4dos "virtual" CD drive.

If I get it right you are using the ubc511.iso on a USB stick or similar, how exactly do you access/boot from it?

Or are you copying the contents of the ubcd511.iso to the root of the stick?

Or what?

Wonko

See post #2 - the contents of the HBCD ISO are copied to a USB stick.

@ady - Yes, It could be that memdisk when loaded after a grub4dos map --mem command, obliterates the grub4dos virtual CD image (held in memory), but if memdisk is used by grub4dos and then memdisk is used again by the syslinux FDD image, it just adds a second virtual image and the first virtual drive CD loaded by grub4dos is not lost.

The idea is not to boot fdubcd.iso with MEMDISK, as it is already done from the syslinux/isolinux menu. The goal is to have an alternative method to boot fdubcd.iso (from grub4dos), instead of using (isolinux ->) memdisk, so to give this alternative for some case where, for whichever reason, memdisk won't work as expected in a certain system/BIOS/whatever. I should have presented these "conditions" (fdubcd.iso and grub4dos without memdisk) clearly.

...
0.4.2 has introduced a new variable, memdisk_raw, to simulate the
memdisk-like raw mode. If the BIOS has no int15/87h, or if it has
buggy int15/87h support, you should set this variable before any
memdrives are used. ...

In any case, the fdubcd.img floppy image inside fdubcd.iso is also booted with memdisk, so if memdisk fails to boot the iso image in a certain system, there is still the potential conflict of the same memdisk booting the floppy image in the same problematic system. Once the first fdubcd.iso can be booted by grub4dos (without memdisk) and used correctly in DOS, the next step would be to also provide an alternative boot method (other than memdisk) to the fdubcd.img inside fdubcd.iso.

I am wondering if the boot of the fdubcd.img floppy image by means of memdisk (after using grub4dos for fdubcd.iso) might have some influence on grub4dos or on DOS recognizing the content of fdubcd.iso as drive "T:"; or if, instead, it is just the DOS mode itself (independently of the fact that DOS is booted from - or resides in - fdubcd.img).

If the problem for grub4dos to retain the content of fdubcd.iso is generated by memdisk or by fdubcd.img, that's one thing that might have some workaround. If the problem is the DOS mode itself, then the problem (and potential solution) is completely different than just a few adjustments to the boot entry or a specific grub4dos version.

It is not clear to me why grub4dos can "open" fdubcd.iso, use the content to boot fdubcd.img inside it, but then when the system is already in DOS the same content of fdubcd.iso is "lost" (or, in other words, it is not available for DOS to be used). Since I am not a developer, I probably wouldn't understand the technical details, but I would like to know if there is a solution related to grub4dos (specially if it depends on the menu entry commands or on the specific grub4dos version).

See post #2 - the contents of the HBCD ISO are copied to a USB stick.

This is what YOU did.

I am asking to ady what HE does (possibly exactly).

Wonko

@ady - Yes, It could be that memdisk when loaded after a grub4dos map --mem command, obliterates the grub4dos virtual CD image (held in memory), but if memdisk is used by grub4dos and then memdisk is used again by the syslinux FDD image, it just adds a second virtual image and the first virtual drive CD loaded by grub4dos is not lost.

Yes, It could be that memdisk when loaded after a grub4dos map --mem command, obliterates the grub4dos virtual CD image (held in memory),...

Edited by ady, 20 December 2012 - 07:20 PM.

Yes, but if you try (and other people try in the attempt to help you) n different settings approaches and what not, there will not be n solution but either one or a few solutions for "unidentified" environment or no solutions at all.

I would propose a "plan".

Let's see what happens ONLY with the ubcd511.iso mounted as CD in a VM. (and solve *somehow* this).

Then (and only after a solution for this environment, replicable by everyone, has been found) go to next step, contents of the ubcd511.iso copied "flat" to a USB stick (what Steve6375 was testing) then, once a solution to this has been found, let's tackle the next ordeal, the ubcd511.iso mapped to (0xff) or (hd32).

Wonko

QEMU.

ubcd511.iso mounted as CD

booted from floppy disk loading grub4dos

MANUAL COMMANDS on command line:

root (cd)

chainloader

boot

in "main" Isolinux menu choose "grub4dos menu"

in grub4dos menu choose UBCD FreeDOs ...

text menu choose 7 Boot No UMB (ultradefensive)

The detection of CDROM fails and you have drive letters A: and Q:

"Exit" and type cdrom

Choose config, set "Fixed" and then "ATA", save, OK.

The CDROM is now detected and mapped as T:, it is accessible, you can list files on it, etc. etc.

Type ubcd

Then "Launch"

Error saying that there is NO cdrom (while there is one, and you can access it allright).

Preliminary conclusion:

the CDROM detection routine is flawed (TWICE), first one because it cannot find the CDROM and load it's driver, the second because after having loaded the driver and mounted the cd-rom to drive letter T: the CDROM is still not detected by the "Launch".

If booted directly to CD the first autodetection works, but the second still fails (but not always, in a few tests it "went through", meaning that possibly there is additionally a timing problem of some sort ) 

I take back last sentence, mistake on my part, sorry.

Wonko

Yes, but if you try (and other people try in the attempt to help you) n different settings approaches and what not, there will not be n solution but either one or a few solutions for "unidentified" environment or no solutions at all.
I would propose a "plan".
Let's see what happens ONLY with the ubcd511.iso mounted as CD in a VM. (and solve *somehow* this).
Then (and only after a solution for this environment, replicable by everyone, has been found) go to next step, contents of the ubcd511.iso copied "flat" to a USB stick (what Steve6375 was testing) then, once a solution to this has been found, let's tackle the next ordeal, the ubcd511.iso mapped to (0xff) or (hd32).

title test
map --mem (bd)/ubcd/images/fdubcd.iso (0xff)
map --hook
root (0xff)
map --mem /fdubcd.img (fd0)
map --hook
root (fd0)
chainloader /kernel.sys

This also fails and there is no memdisk or syslinux involved.

Indeed the syslinux/isolinux -> memdisk method successfully uses "iso raw" for fdubcd.iso. I don't know if grub4dos has some similar or equivalent command or parameter, or if it is even necessary for grub4dos and fdubcd.iso. If such command exists, I'll appreciate someone suggesting it here.
...
And what about a grub4dos equivalent to the "append raw" used with "isolinux -> memdisk -> fdubcd.iso"? Again, when I say "grub4dos", I mean without using memdisk.

title test
map --mem (bd)/ubcd/images/fdubcd.iso (0xff)
map --hook
root (0xff)
map --mem /fdubcd.img (fd0)
map --hook
root (fd0)
chainloader /kernel.sys

This also fails and there is no memdisk or syslinux involved.

title test
# Might as well use the same drive number as MEMDISK
map --mem (bd)/ubcd/images/fdubcd.iso (0xE0)
map --hook
root (0xE0)
map --mem /fdubcd.img (fd0)
map --rehook
# Should be two entries
map --status
root (fd0)
# Let it boot itself as MEMDISK would
chainloader +1

The detection of CDROM fails and you have drive letters A: and Q:
"Exit" and type cdrom
Choose config, set "Fixed" and then "ATA", save, OK.
The CDROM is now detected and mapped as T:, it is accessible, you can list files on it, etc. etc.

Regarding testing eltorito.sys, I am not sure what or how to test (advice?). The dosutils are already used in fdubcd.

Please re-read my quote from the README_GRUB4DOS.txt file. But it's the default mode in GRUB4DOS anyway, so it won't help here, unless disabling it makes a difference. (Worth a try.)

 I think perhaps you might've meant --rehook in there:

title test
# Might as well use the same drive number as MEMDISK
map --mem (bd)/ubcd/images/fdubcd.iso (0xE0)
map --hook
root (0xE0)
map --mem /fdubcd.img (fd0)
map --rehook
# Should be two entries
map --status
root (fd0)
chainloader /kernel.sys

 

I was thinking of ETTool and ETDump and FindCD.

Please re-read my quote from the README_GRUB4DOS.txt file. But it's the default mode in GRUB4DOS anyway, so it won't help here, unless disabling it makes a difference. (Worth a try.)

I think perhaps you might've meant --rehook in there:

title test
# Might as well use the same drive number as MEMDISK
map --mem (bd)/ubcd/images/fdubcd.iso (0xE0)
map --hook
root (0xE0)
map --mem /fdubcd.img (fd0)
map --rehook
# Should be two entries
map --status
root (fd0)
# Let it boot itself as MEMDISK would
chainloader +1

Tried this and a few variations - none worked.

You can use hook twice (or more than twice). A map --status showed me that both hook and rehook work. 

Rehook does not have to be used after one hook has been done, I think rehook just sorts out the hook map and gets rid of unnecessary mapping (e.g. a-b-c after a rehook becomes a - c)  .

I also tried mapping to (rd) as this is supposed to be equivalent to memdisk, but that doesn't seem to work either...