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.

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.

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

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?

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.

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

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

Quote:

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.

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.

(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.

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.

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.

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum