Victor Chew wrote:
Well, regarding the assigned drive letter, it comes from the fdubcd dos scripts, so that's one aspect you could review to change the letter assignment.
No, it comes from the drive emulation. For memdisk, the emulated HDD is pushed to become the first HDD in the chain (much like emulated CDROM drives). For grub4dos, I added some commands to replicate this behaviour so that the mapping is the same under both memdisk and grub4dos.
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.
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.
It seems we are trying to have some workaround to some grub4dos assumed limitation ("assumed" because we haven't found the adequate grub4dos parameters, but that doesn't mean the limitation exists), but the goal is not achieved anyway and we have also negative effects generated by this change. Not a good trade IMHO.
Well, the fact is this is the only working solution so far. The alternative is to remove grub4dos/fdubcd support (since FDUBCD ISO booting does not work under grub4dos).
In the VM example I posted, there is only one hdd, and 3 cd drives. Accessing the hdd content is indeed possible, and the ISO image that contains UBCD is also accessed. The problem is (and AFAIK was before too) that the content of additional optical drives (ISO images) can't be accessed.
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. When booting with syslinux/isolinux, the mentioned access was already achieved, and with the new method there are negative consequences (drive letter shift, bigger size, maybe bigger ram requirements).
Since the current main grub4dos developer was unable to help (or unable to understand the situation), but chainloading grub4dos to syslinux is possible, then I would suggest changing the approach.
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".
In the meantime, maybe someone will eventually find the correct parameters for grub4dos to work as desired (if such parameters or commands exist, we don't really know).
Also, I would like to hear from the others whether the shift in drive letters that much of a problem? From my testing, you can still access the HDD content even when you have two HDDs attached (eg. partition managers), and the hardware level diagnosis apps can find the physical HDDs as well.
As I said, each and every hdd can be accessed; that's not a problem. Accessing the content of additional optical drives (whether as ramdisks or not) seem to be a problem. And the letter shift is not going to be a problem for those of us involved here. The problem may come from simple users, where "c:" is the drive already known under Windows and usually assumed to be the same "c:" when booting with UBCD (or "the first drive" when booting with anything). This confusion is not rare among users. The wrong assumption about which specific drive letter represents a specific drive (or partition, or volume) could potentially lead to, for example, wiping the wrong partition. It wouldn't be the first nor the last time.
On another matter, would you be updating UBCD with the latest pmagic available (with the latest boot menu available) before releasing the final ubcd v.5.2?
a2 already has 2012_11_30 and its boot menus available, which is the latest release. If a new version becomes available, I will definitely update.
There are development versions of pmagic. I understand that you may not want to use development versions, and that's a very valid point.
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.
BTW, HDClone 5.2.2 is out.
A little typo of mine; it is actually new version 4.2.2. Sorry.