The "map" commands in grub4dos are sometimes tricky.

I don't know enough about grub4dos to suggest a specific solution, but



and similar codes are frequently presented with similar questions as in this topic, in sites about booting with grub4dos. Also frequently, the solution comes in the form of changing the "hd32" by some other option, more compatible with BIOSes. Something like (0xff) , or generally "(0xMN)" where MN might be "A0", "00" and others.

I'm sorry I can't be more specific (like for example about the exact meaning or the exact consequences about each MN pair of values).

Since we are talking about at least 2 images (fdubcd.iso and fdubcd.img), maybe more "map" and more "hook" commands are necessary.

About testing with SYSLINUX/ISOLINUX, are you already using v.4.06? If it doesn't work as expected, maybe the new ifmemdsk.c32 syslinux module could be helpful? (I haven't used ifmemdsk.c32 yet, so I am not sure if it is actually useful to solve the current situation.)

I don't like being so vague, but I just thought that maybe thinking out loud may trigger some idea from someone else.

That is pretty strange. When I wrote this solution, it worked on my Fujitsu laptop (Lifebook AH531), and on VirtualBox. So I didn't believe there will be such hardware-specific errors.

Perhaps I should surrender here. And by the way, did grub4dos developers know this bug?

Tried that. (hd32) => 0xa0. Also tried 0xff, which is apparently needed for certain "evil" BIOSes. Same problem encountered.

Is it possible to check whether on your Fujitsu laptop, you get:

1) the correct drive table with etdump?
2) both drives mounted correctly when booting optimal setting and select detect all CDROM drives?

I am going to KIV this too since I don't know what else I can do. I have submitted a issue report here.

I think the correct link should be here, but maybe I'm wrong.

Probably Icecube would be able to figure this out...

I burnt a CD just for this test. (I wonder why we don't include these Bart's utilities in FDUBCD?)

FUJITSU LIFEBOOK AH531
Boot command in GRUB4DOS:

In FDUBCD, I selected "2 Boot UMBPCI (optimal)" in Memory Management
and "Auto, try to detect all" in CD-Rom configuration.

Result:
FDUBCD is mounted to drive T. UBCD is not detected or mounted. (There's no drive U.)

The etdump table: (I can't interpret this so I'll let Victor do that.)

Sorry for double post.

I also tried this (in GRUB4DOS)


And the error message "Fatal! Inconsistent data read from (0x9F)0+32" indeed appeared on my laptop.
So my usage could be wrong like Tinybit (GRUB4DOS maintainer) said in the bug report.

etdump is included in FDUBCD 1.4.5 in UBCD 5.2a1.

Your etdump table is correct! There is a device at 0xA0 (hd32) because CF=0. So FDUBCD is correctly mounted via eltorito.sys. Not sure why your physical CDROM drive is not mounted though. Does it get mounted if booted using isolinux? Or does none of the DOS drivers support your CDROM drive?

More investigation needed. I will check out Tinybit's reply.

I have created a minimal ISO for testing this issue.

More details at the bug report.

If you have been monitoring the bug report, it's currently a dead end.

Unless there are other inputs, I think we may have to remove all the FreeDOS pieces from the grub4dos menu.

Or should we remove grub4dos entirely?

While testing 52a1 in VBox, I tried isolinux -> fdubcd -> VC. The additional CD drive letters are available, but I can't access the content (iso image assigned to that drive in the VM settings).

There is a forum topic that although initially not related to this, it also touches "more-than-one-optical-drive access from grub4dos" issue: http://reboot.pro/topic/17841-make-virtual-floppy-then-boot-xp-cd-help/. It has no clear solution, but it might give at least some clue.

I wouldn't give up on grub4dos. I personally don't use it, but I know many others do. This is only one issue, and other features are working correctly AFAIK.

I think I solved the problem by moving the entire FDUBCD + DOSAPPS to a HDD image. Now both syslinux and grub4dos boots to the virtual HDD and mounts the physical UBCD HDD as T:

Still working on tying up various loose ends eg. removing the RAM drive "Q:" under this new model.

Should have a "a2" version available soon for testing!

About this ram (hard) disk, should it be set as read-only? Are you adding specific CHS values too (to memdisk)?

Additionally, why we would need to use a different drive letter? I think the ram (hard disk) drive should preserve the ram drive letter as used by fdubcd.ISO, so additional letters can be used for additional drives (like additional optical drives for example, which is the situation we are discussing in this topic). And leaving a drive letter free for a ram floppy disk (as was used until now, fdubcd.img of 2880kb) might still be useful in some situations.

It is not set to read-only, just like the floppy. The boot process needs write access, so does certain apps.

There will only be two drive letters C: and T: with this mod. There's just no need for Q: anymore, since C: will be big enough.

See http://reboot.pro/topic/17911-access-fdubcdiso-content-from-grub4dos/#entry164641

I think this works...

Yes, it is not perfect yet, but we are making progress. Changing the grub4dos entry for fdubcd.iso 5.1.1 to



(meaning, changing from "hd32" to "hd96"), grub4dos can boot fdubcd.iso in a similar way as memdisk does, at least when booting UBCD from optical media. By the time I am writing this post, more tests are needed to confirm the behavior when booting from UFD (as there were reports of "hd96" failing).

But, even if this "hd96" works so to execute DOS programs in fdubcd.iso, there are still some potential improvements I am testing, so to avoid fdubcd.iso at all.

There are still some other problems to access additional optical media, but that's another matter.

FYI - tinybit has made a new version of ElTorito.sys which seems to work well.
This new version fixes a problem of incompatibility with some BIOSes (inc emulators/VM BIOSes).
I have tested it and it seems to work.
It would be nice if someone could test it in UBCD 5.1.1 (using grub4dos menu) on lots of different PCs to see if there are any problems with it.

See http://reboot.pro/topic/17911-access-fdubcdiso-content-from-grub4dos/page-2#entry164705 for details and follow the thread.

For the next alpha release, I am going to try out booting FDUBCD as a superfloppy, as ady and others have suggested.

I have done my research again, and the only negative comment I can find is here: which is more speculative than concrete.

On the other hand, I have not found a single issue report with using reanimatolog's large floppy images. In fact, it is the "gold" standard for people who want out-of-the-box large floppy images.

I have built an 18MB image using the FAT12Build script and it works with no issue on VMWare and VBox.

I will do a bit more test on real hardware, then release 5.2a3 to for others to test.

@Victor,

As you probably know, I've been testing so to try to solve the grub4dos + fdubcd.iso method, but I have also been looking at the other possibilities, superfloppy and hdd images.

The superfloppy is my favorite for fdubcd, but you said there might be some systems that are not bootable because of the non-standard size. If you could share your concerns, maybe we could find some "best-values".

About the hdd image, I've been looking at the one you included in ubcd 52a2, and I was able to improve its format. Looking at the values you used and the specific boot codes, I wasn't able to guess what was the reasoning for the used values, or what was the exact source of the boot code for the VBR and the MBR. Since the procedure I use for hdd images is based on what I use for superfloppies, I would like to ask you if you could share this info.

TIA,
Ady.

I may add, that I personally absolutely favor the iso-variant. If fdubcd has another solution, be it hdd-image or superfloppy, it will be the only one among all those other isos that are part of the total UBCD. The iso remains also the most compatible in terms of customization for the greater public. You skip this in order to get more compatible with grub?
I keep reading about hardware having problems with memdisk. I have a collection of about 300 Systems and testing live-booting on dozens but I never came accross those problems. On the other side my decision to concentrate on syslinux as boot-base for OmniBoot is based on many bad experiences with grub-variants that I made. For me it turned out to not be worth the trouble to fix anything as to be compatible with grub too. Actually I leave grub-booting up to super-grub-disk(s) and the debian-based boot-repair-distro and don't see the use to replicate with grub-crypto-commands what syslinux does with ease.