UBCD V5.2 discussion

Discussion/announcements about test/beta releases of UBCD will be posted here.

Moderators: Icecube, StopSpazzing

Message
Author
Victor Chew
Posts: 1368
Joined: Mon Feb 21, 2005 10:59 pm
Contact:

Re: UBCD V5.2 discussion

#81 Post by Victor Chew » Wed Dec 19, 2012 5:26 pm

The problem is (and AFAIK was before too) that the content of additional optical drives (ISO images) can't be accessed.
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 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.
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.
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.
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.
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, 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.
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".
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.
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.
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.

ady
Posts: 832
Joined: Sat May 08, 2010 5:26 am

Re: UBCD V5.2 discussion

#82 Post by ady » Thu Dec 20, 2012 1:57 am

Victor Chew wrote:
The problem is (and AFAIK was before too) that the content of additional optical drives (ISO images) can't be accessed.
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 comment is related to the context. The changes introduced by the hdd image method are intended to solve a certain situation, and also introduces some negative consequences, and also leaves some other characteristics without changes. So my comment is related to the access to additional drives' content, specially when I had to specify more clearly that the problem about access is not for other hdd's content but for optical drives, and the drive letter shift is much more relevant for hdd's letters, not so much for optical drives (that can't be accessed anyway). The other relation to the current development is that the issues in question are not only related to how memdisk works as you mentioned, but also to how the scripts in fdubcd work.
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.
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.
Sure DOS has its limitations about booting with "c:" and drive letters, but it can also boot with "a:" for example (one of the advantages of the previous method and of a superfloppy image; but you say that a superfloppy image may have other booting problems). And the previous method (fdubcd.iso) was successful in avoiding the shift in hdd letters, among other advantages.

In other words, we are using a workaround just for booting with grub4dos, and I am not convinced that the potential positive effect of this workaround justifies the several negative ones. Of course the fact that I am not convinced doesn't mean much in terms of UBCD, other than expressing my concerns now, when it may count as user's feedback.

...
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.
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.
OK. Just in case it may be helpful for other users in the future... The needed vmalloc value (in those cases where the value counts) for the current stable release of pmagic should already be higher than 288MiB. The problem was recently reported, and changed accordingly (while it should had been changed before already). Changing it in UBCD too only facilitates the future custom updates of pmagic by end users. Of course, if pmagic gets updated before UBCD 5.2 gets out, then UBCD should receive this updated value too (or even higher).

___

BTW, ASTRA 6.02 is out.

ady
Posts: 832
Joined: Sat May 08, 2010 5:26 am

Re: UBCD V5.2 discussion

#83 Post by ady » Thu Dec 20, 2012 4:31 am

Victor Chew wrote: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.

Independently of my previous post, I don't understand this comment. Are you saying that in certain specific systems, when booting with grub4dos, there is no DOS program at all, from the ones inside fdubcd, that can be executed? Are you saying that certain specific programs of those inside fdubcd can't be executed? Please clarify because this really confuses me (since I have not ever experienced that the programs inside fdubcd can't be executed when fdubcd.iso was started by grub4dos).


EDIT: Forget about this misunderstanding. The reason I have never had a problem booting with grub4dos and executing fdubcd DOS programs is because during my tests with grub4dos I always had fdubcd.iso and fdubcd.img already expanded in my customized UBCD. The original non-expanded images can't run the DOS tools inside fdubcd.iso (from the original ubcd511.iso).

Victor Chew
Posts: 1368
Joined: Mon Feb 21, 2005 10:59 pm
Contact:

Re: UBCD V5.2 discussion

#84 Post by Victor Chew » Thu Dec 20, 2012 8:31 pm

The comment is related to the context. The changes introduced by the hdd image method are intended to solve a certain situation, and also introduces some negative consequences, and also leaves some other characteristics without changes.
Let's adopt this method for the time-being and see how it goes, since I think the shift in drive letters is a worthy compromise to get FDUBCD+DOSAPPS to run under grub4dos. Until someone figures out how to get FDUBCD ISO to mount under grub4dos+FDUBCD, that is.
OK. Just in case it may be helpful for other users in the future... The needed vmalloc value (in those cases where the value counts) for the current stable release of pmagic should already be higher than 288MiB.
No problem. I will change the "vmalloc" parameter for the next release. Or maybe a new stable release of Parted Magic will be out before then!
BTW, ASTRA 6.02 is out.
Noted. Thanks!

ady
Posts: 832
Joined: Sat May 08, 2010 5:26 am

Re: UBCD V5.2 discussion

#85 Post by ady » Fri Dec 21, 2012 4:29 am

Victor Chew wrote:
The comment is related to the context. The changes introduced by the hdd image method are intended to solve a certain situation, and also introduces some negative consequences, and also leaves some other characteristics without changes.
Let's adopt this method for the time-being and see how it goes, since I think the shift in drive letters is a worthy compromise to get FDUBCD+DOSAPPS to run under grub4dos. Until someone figures out how to get FDUBCD ISO to mount under grub4dos+FDUBCD, that is.
Not completely solved, but making some little progress viewtopic.php?p=24454#p24454.

@Victor, can you replicate the problem of accessing the content of additional cd drives from DOS (Volkov shows the additional drive letters correctly, but the content can't be accessed)?

Don Manuel
Posts: 34
Joined: Mon Nov 19, 2012 11:18 pm

Re: UBCD V5.2 discussion

#86 Post by Don Manuel » Fri Dec 21, 2012 6:26 am

I have today experimented with my proposed linux approach of using dd to create a smaller image. Works as intended.
I could create a 17MB image

Code: Select all

dd if=/dev/zero of=my_hdd.img bs=1M count=17
which was partitioned and formated to FAT16 by the current FreeDOS-CD in a VM (qemu) - a 16MB image would have been formated FAT12 and I didn't check how to pass by that fdisk-automatism, since the original is FAT16 anyway.
Then I sysed it and copied the current fdubcd.img-content into that filesystem. Works with mounting from Linux or using a VM with another os. This now shouldn't be booted in the VM just to test it, because the current DOS-boot process of fdubcd will rename the label of that disk-image to RAMDISK and actually write it's whole ramdisk to that disk - which will make it unusable as of the next boot!

As it is done during runtime when this image is loaded the way it currently is (via syslinux, memdisk, etc). So I think there is a behaviour not actually writing to a ramdisk but using the hdd-image as writable image! I do not think that this is really a step forward. DOS should use a "real" ramdisk and leave the boot-image untouched. However, with this behaviour it makes absolutely no sense to shrink the image because then you soon run out of memory. I tried to boot that 17MB image via syslinux and memdisk and it works as the original. Only loading a program like savepart doesn't work, because the disk is too small!

However I am almost sure, that it must be possible to get back to that ramdisk with untouched boot-image, at least I personally would definitely recommend that, no matter if the image is an iso or a hdd-image.

Victor Chew
Posts: 1368
Joined: Mon Feb 21, 2005 10:59 pm
Contact:

Re: UBCD V5.2 discussion

#87 Post by Victor Chew » Fri Dec 21, 2012 8:38 pm

I do not think that this is really a step forward. DOS should use a "real" ramdisk and leave the boot-image untouched.
I am not sure why this is happening to you. memdisk creates a RAM disk from the image. It does _not_ write back to the disk image. Check it out yourself with UBCD V5.2a2.

Victor Chew
Posts: 1368
Joined: Mon Feb 21, 2005 10:59 pm
Contact:

Re: UBCD V5.2 discussion

#88 Post by Victor Chew » Fri Dec 21, 2012 8:45 pm

@Victor, can you replicate the problem of accessing the content of additional cd drives from DOS (Volkov shows the additional drive letters correctly, but the content can't be accessed)?
From VMPlayer V5.0.1, I created a VM with 3 CDROM drives. One of them points to UBCD V5.2a2, the other two point to different ISO images. Then I launch FDUBCD via memdisk, and select option (2) "Optimal". When it comes to the CDROM dialog box, I click on "Config", then "Auto, detect all". It managed to mount all the CDROM drives. I verified the different content in all the mounted drives.

Don Manuel
Posts: 34
Joined: Mon Nov 19, 2012 11:18 pm

Re: UBCD V5.2 discussion

#89 Post by Don Manuel » Sat Dec 22, 2012 2:16 am

No, a "real" ramdisk isn't created. The image is becoming that ramdisk. As you see in the following screenshot, C: contains everything after boot (obvius e.g. through folders TMP or USR) and gets renamed to RAMDISK. So even the label changes.

Image

If I try to boot fdubcd.img as provided in UBCD V5.2a2 (unzipped of course) via qemu the boot hangs. My created image boots once (as hdd-image) in qemu, the label gets renamed and everything that had been copied to the "ramdisk" which is actually a hdd-image loaded into RAM, remains in this hdd-image, leaving it disfunctional as of the next boot. You also see the slightly smaller size in the screenshot of my hdd-image-version:

Image

Now if I load my hdd-image in qemu as hdd directly you can see again exactly this screen after first boot - (which is very slow, since - as said - everything is written to that HDD during boot. In this case no kind of RAMDISK is created, so it takes very long to boot that way)

But if I reboot from this image I get this:

Image

Can't be replicated with the current version of fdubcd.img as said, because it only boots via syslinux (no interest in grub-problems here) but not in qemu.

So if this image is only loaded via syslinux (or grub) nobody will ever have a problem with this. Only if somebody tries to load it directly as harddisk in a virtual machine, what even needs a fix right now. So not fixing it, might in this case not even be the worst idea ;)

ady
Posts: 832
Joined: Sat May 08, 2010 5:26 am

Re: UBCD V5.2 discussion

#90 Post by ady » Sat Dec 22, 2012 6:53 am

Victor Chew wrote:
@Victor, can you replicate the problem of accessing the content of additional cd drives from DOS (Volkov shows the additional drive letters correctly, but the content can't be accessed)?
From VMPlayer V5.0.1, I created a VM with 3 CDROM drives. One of them points to UBCD V5.2a2, the other two point to different ISO images. Then I launch FDUBCD via memdisk, and select option (2) "Optimal". When it comes to the CDROM dialog box, I click on "Config", then "Auto, detect all". It managed to mount all the CDROM drives. I verified the different content in all the mounted drives.
I have re-tested 5.1.1 and 5.2a2 in VBox 4.1.22 and VMPlayer 5.0.1. In VBox, I cannot access the additional optical drives (but the letters are available). In VMPLayer, I am able to access the additional optical drives, but drives "T:" and "U:" are the same (Victor, is this the same behavior you see in your tests?). Regarding this duplicated optical drive, I wonder if there is some problem when the scripts generate the ramdrive(s).

Unfortunately, currently I don't have the conditions or resources to test this on real hardware (whether an UBCD real optical media or real UFD). The different behavior in different VM software could suggest: A_ possible bugs in the relevant VM software; and/or B_ some real systems may behave as VBox and some other real systems may behave as VMPlayer showed.

Regarding Manuel's comments, either the ramdrive is "backed" by the hdd image itself, or it is a separated ramdrive that was generated by the hdd image. If the original main booting media is a read-only optical media, then it wouldn't matter (or it wouldn't work). If the original boot media is a writeable UFD, then the situation described by Manuel needs to be double-checked.

Don Manuel
Posts: 34
Joined: Mon Nov 19, 2012 11:18 pm

Re: UBCD V5.2 discussion

#91 Post by Don Manuel » Sat Dec 22, 2012 8:34 am

Exactly, only if a writable medium is used, and be it a virtual hdd-image, then this behaviour gets annoying.

And I repeat, other than that, if the current behaviour persists, the image should not be made smaller, since it's size is the size of the available "ramdisk" - for it becomes the ramdisk.

Victor Chew
Posts: 1368
Joined: Mon Feb 21, 2005 10:59 pm
Contact:

Re: UBCD V5.2 discussion

#92 Post by Victor Chew » Sun Dec 23, 2012 8:27 pm

Please see this post. For the next alpha release, I will be trying out the superfloppy method.

Victor Chew
Posts: 1368
Joined: Mon Feb 21, 2005 10:59 pm
Contact:

Re: UBCD V5.2 discussion

#93 Post by Victor Chew » Sun Dec 23, 2012 8:32 pm

I am able to access the additional optical drives, but drives "T:" and "U:" are the same (Victor, is this the same behavior you see in your tests?).
Yup. T: is claimed by the eltorito driver. You need to choose the option that says "mount all, _except_ eltorito" to get rid of the duplicate drive letter.

eltorito.sys mounts the boot CD with BIOS's support. It doesn't need to worry about the hardware interface structure (IDE,SCSI,SATA,USB etc.).

The other CDROM drivers will mount whatever CDROM drives they find with the supported hardware interfaces.

That's why you are getting drive letters mapping to the same CDROM drive.

Post Reply