Let's be clear about this. This is a problem with FDUBCD itself. It is not a problem _introduced_ by the HDD image method, right? If so, why is it coming into this discussion?The problem is (and AFAIK was before too) that the content of additional optical drives (ISO images) can't be accessed.
DOS assigns drive letters to the floppy disk drives and hard disk drives it finds at boot time in a fixed sequence, You cannot change this sequence. You can only change the drive letters for installable device drivers like CDROM drives etc.The scripts were setting drive letters for fdubcd.iso before, but I know the method used for such assignment is different regarding ISO images (optical drives with respective drivers) than when used for hdd images.
There are two problems with this. First, DOS will only boot from C: . I tried mounting FDUBCD as the second HDD, but it wouldn't boot. Second, even if DOS will boot from non C: devices, there is no way to figure out how many HDDs the target system has and insert the emulated HDD at the end. For example, if the target system has 1 HDD, "harddisk=1". But if the target system has 2 HDD, then "harddisk=2". Same problem with grub4dos.But I insist, memdisk has the "harddisk=#" parameter. And since the current "c:" drive is a ramdisk too, there should be a way to use a different drive letter, just as there was a specific ramdrive letter before.
No, when booting FDUBCD ISO via grub4dos, the emulated ISO cannot be mounted as T:, hence none of the CAB files in DOSAPPS can be accessed, which means none of the FDUBCD DOS apps will work.So, again, the _only_ case we are "solving" (not by a real solution but as a workaround), is the simultaneous access to both ISO images and/or drive(s) (fdubcd.iso and ubcd*.iso) when booting with grub4dos.
No, the workaround will be to chainload memdisk to mount the image, but that defeats the purpose of including grub4dos in the first place, because grub4dos has different device emulated logic from memdisk, which allows it to work on some systems that memdisk has problems with. If we chainload memdisk to emulated the device, then there is no point in keeping grub4dos.Instead of inserting this workaround to solve a grub4dos-related problem, the workaround could be to answer "just chainload to the syslinux menu and boot fdubcd from it".
The original values from Parted Magic 2012_11_30 syslinux.cfg is "vmalloc=288MiB". I will use the original value until it is changed in the latest (non-development) release.I actually have a specific reason to my question. In the pmagic boot menu, the value for all "vmalloc" should be higher. In my custom menu I am already using "320MB" for some time, and now the development version of pmagic is also using that same value. I would suggest changing this parameter in every entry of the pmagic boot menu where it is used, before the final release of UBCD 5.2.