Victor Chew wrote:
Quote:
That leads me to my next question. If fdubcd is not going to be an ISO image (with the floppy image inside), why it has to be a hdd image (with an MBR)?
Some BIOSes have problems booting non-standard floppy sizes, so a HDD image is much more compatible.I only knew about BIOS+memdisk having problems when the BIOS is set (or not) to test for the presence of a (real) fdd. I didn't know about problems regarding special sizes.
I would suggest generating a more efficient size hdd image anyway, and possibly trying to set (assign) a different drive letter instead of "c:". Adding memdisk parameters could help too.
Quote:
Quote:
The initial issue for me is that I still can't access more drives than what I was able before (so what's the point in changing it).
What's your VM drive config so that I can test it?The VM (standard PIIX3) has 1 primary master PATA hdd image of 128MB with 1 FAT16 partition; 3 optical drives with respective ISO images connected (the first one being UBCD to boot the VM), and one standard floppy image.
As I said before, I boot with the syslinux menu -> fdubcd (tested from silent to ultra-defensive, always changing the config so to check for _all_ cd drives)-> volkov. I can see all the drive letters (including the additional cd drives' letters), but I cannot access the content of the additional drives (ISO images). Since this was also happening in previous versions, then what's the gain of changing to use a hdd image for fdubcd?