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

#61 Post by Victor Chew » Tue Dec 11, 2012 5:24 pm

The "official" dban image uses the boot prompt. In my customized UBCD I use UBCD main boot menu -> dban boot menu (instead of cli). So I don't understand what you meant with your first point.
I was referring to this:
dban.png
dban.png (7.6 KiB) Viewed 122787 times
i.e. the isolinux menu.

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

Re: UBCD V5.2 discussion

#62 Post by ady » Thu Dec 13, 2012 2:00 am

Victor, I'm sorry I still don't understand the problem. We start discwizard or cpustress without the need to use memdisk. My comment is about starting dban in a similar way.

If the problem is the specific boot screen, I can reproduce the same first boot screen for dban as you posted (with cli boot prompt), and with a single "enter" the user gets to a syslinux menu, which is also able to show the same help texts. Or, it can start directly with the menu and go back to the help screens (with or without cli prompt). The same methods that are used in the official dban can still be used.

I apologize for extending the discussion topic with this little detail. Hopefully I'll get to understand the exact problem so to try to come up with a solution.

The above comments are related to the syslinux/isolinux menu only. For the second point, the alternative grub4dos menu, we would need someone else to come up with an equivalent solution.
Attachments
Alternative or additional DBAN boot
Alternative or additional DBAN boot
dban_menu.jpg (15.06 KiB) Viewed 122763 times

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

Re: UBCD V5.2 discussion

#63 Post by Victor Chew » Thu Dec 13, 2012 11:18 am

Correct me if I am wrong, but to reproduce DBAN's menu, we will have to chainload DBAN's isolinux.cfg, no?

So to reproduce this for grub4dos, we will need to translate the isolinux menu to grub4dos, no?

And for all that trouble, what exactly do we gain?

For DiscWIzard, I don't think we had a choice, since ISO emulation didn't work for that app.

For cpustres, the menu is not isolinux-based. So the discussion does not apply.

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

Re: UBCD V5.2 discussion

#64 Post by ady » Thu Dec 13, 2012 12:43 pm

Victor Chew wrote:Correct me if I am wrong, but to reproduce DBAN's menu, we will have to chainload DBAN's isolinux.cfg, no?

So to reproduce this for grub4dos, we will need to translate the isolinux menu to grub4dos, no?

And for all that trouble, what exactly do we gain?

For DiscWIzard, I don't think we had a choice, since ISO emulation didn't work for that app.

For cpustres, the menu is not isolinux-based. So the discussion does not apply.
The analogy with discwizard and cpustress is related to the location (out of the images directory). The way to chain to dban's cfg is equivalent to what you already do for pmagic.

About the potential gain; it is not having to use memdisk, and the additional alternative easier menu (instead of just cli). If you use memdisk, adding a menu is less tempting (the small the content of the image, the better, and you use the original image).

Your last post is about grub4dos menu chaining to dban (instead of chaining to memdisk). The part that I didn't understand before (and I still don't) is what you were referring to with your first point:
1) If we load dban.bzi directly, we miss the main menu
. But since that's just one of the two points, I'll put my curiosity aside now so we can move on.

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

Re: UBCD V5.2 discussion

#65 Post by Victor Chew » Thu Dec 13, 2012 4:52 pm

UBCD V5.2a2 is available for download:

http://ubcd.mirror.fusa.be/ubcd52a2.iso
md5sum: 4c3f6201b92693f9ac537c94e62fc8b2
sha1sum: 0fedba0e39471192495740eea7815ce65d12817f


Changelog:

- Re-added raw boot image for AleGr MEMTEST V2.00. Thanks to Don Manuel for his contribution.
- Re-added Super Grub Disk based on ady's feedback.
- Added PCISniffer manual to /ubcd/images.
- Changed to using "linux.c32" instead of "LINUX" command because the former can deal with memory holes better. Thanks to ady for the suggestion.
- Added comments about UBCD2ISO_ARGS to ubcd2iso.cmd and ubcd2iso.sh.
- Added support for "kblang" parameter in UBCD FreeDOS at Don Manuel's request for the OmniBoot project. \level1\keybrd.cab\bin\Keybrd.bat was modified for this purpose.
- Due to problems mounting FDUBCD ISO under grub4dos, this version introduces booting FDUBCD as a HDD image to work around this problem.
- Fixed Mersenne Prime Test "ubcdcmd" to "mprime27".
- Moved !BIOS to a boot image of its own because it can't be made to work with FDUBCD.
- Updated Parted Magic to 2012_11_30.
- Updated UBCD FreeDOS to V1.46. Updated KERNEL.SYS to Build 2041.

The updated index page is available here:

http://www.ultimatebootcd.com/v52/index.html

The biggest change in this release is moving FDUBCD + DOSAPPS to a HDD image. This gets around the problem of grub4dos not being able to mount the emulated FDUBCD ISO with ELTORITO.SYS. Now FDUBCD + DOSAPPS resides in a 50MB HDD image and gets mounted as "C:", while the original UBCD CDROM gets mounted as "T:".

The HDD image can be modified using DiskExplorer or WinImage. Unfortunately, I have not found an easy way to shrink or enlarge the image.

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

Re: UBCD V5.2 discussion

#66 Post by Don Manuel » Fri Dec 14, 2012 1:51 am

Congratulations Victor to the next mile-stone!

Since you are still in alpha-phase, may I point to the floppy-tools section that I also added in the OmniBoot-mod of fdubcd.iso? They are all free tools and have a tiny size. Of course these are vintage applications, but I have the strong feeling, as if the UBCD is aside of its top up2date applications also a favored tool for vintage-fans. But you must have seen them and never mentioned it, so I guess, you have your doubts about those tools.

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

Re: UBCD V5.2 discussion

#67 Post by ady » Fri Dec 14, 2012 8:32 am

Don Manuel wrote:may I point to the floppy-tools section
I personally like to use those types of tools when I need them, but I think that they are NOT for the original UBCD. Customizations and spins-off have their useful place, and UBCD has it's purposes. There are many similar or related tools that are not part of ubcd ("too many" Dell tools come to mind as an example, and "too big" antivirus scanners too); and rightly so. Let's also keep in mind that pmagic's size gets bigger and bigger too, and Victor has no control about it. As I said, customizations and spin-offs have their nice useful place.

Victor Chew wrote:Unfortunately, I have not found an easy way to shrink or enlarge the image.
@Victor,

What exactly do you mean? Are you thinking about the original size? Or how to dynamically change it? Or is it about a script?

I just downloaded the new 52a2, so I have not tested it yet, but if you could explain more precisely what you meant (your goal), we might find a solution.

TIA,
Ady.

drizzle
Posts: 2
Joined: Fri Dec 14, 2012 12:33 pm

Re: UBCD V5.2 discussion

#68 Post by drizzle » Fri Dec 14, 2012 12:43 pm

Would it be possible to update the Western Digital disk diagnostic from v5.19 to v5.20?
http://support.wdc.com/product/download ... =2&lang=en

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

Re: UBCD V5.2 discussion

#69 Post by Victor Chew » Fri Dec 14, 2012 5:09 pm

Don Manuel wrote:Since you are still in alpha-phase, may I point to the floppy-tools section that I also added in the OmniBoot-mod of fdubcd.iso? They are all free tools and have a tiny size. Of course these are vintage applications, but I have the strong feeling, as if the UBCD is aside of its top up2date applications also a favored tool for vintage-fans. But you must have seen them and never mentioned it, so I guess, you have your doubts about those tools.
Definitely. Will check them out for a3.
ady wrote:What exactly do you mean? Are you thinking about the original size? Or how to dynamically change it? Or is it about a script?
The HDD image is 50MB. FreeDOS + DOSAPPS takes up 13MB. There is no easy way to shrink down the HDD image (eg. to 20MB), or to enlarge it (eg. to 100MB), AFAIK, while maintaining structural consistency.
drizzle wrote:Would it be possible to update the Western Digital disk diagnostic from v5.19 to v5.20?
http://support.wdc.com/product/download ... =2&lang=en
Will do. Thanks!

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

Re: UBCD V5.2 discussion

#70 Post by ady » Fri Dec 14, 2012 6:03 pm

Victor Chew wrote:The HDD image is 50MB. FreeDOS + DOSAPPS takes up 13MB. There is no easy way to shrink down the HDD image (eg. to 20MB), or to enlarge it (eg. to 100MB), AFAIK, while maintaining structural consistency.
I'm sorry but, what do you mean with "structural consistency"? Just as we did with the floppy image, which is still 2880KB but with more free space than a typical one, we can use similar techniques now. I have several “uncommon” images, and I have no problems with them as long as they live as ram disks.

But before I get to the hdd image, I need to report my experience with it. I tested ubcd52a2 in a VM with several images connected simultaneously (as if I had more than one cd drive, plus one local HDD). Once in VC, I can see the additional drive letters, but I can't open their contents. This is while booting with isolinux menu. So, what I am doing wrong? I though that "each, any and all" drives would be seen now, but the behavior I see is the same as before. Could someone please point me in the right direction?

Additionally, I shall repeat a report about lower case. All the files in fdubcd must be upper case, including cab files and also their contents.

I'd appreciate some help about VC access to all drives, so I can really test the new fdubcd and report back.

TIA,
Ady.

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

Re: UBCD V5.2 discussion

#71 Post by ady » Sun Dec 16, 2012 9:39 am

ady wrote:
Victor Chew wrote:The HDD image is 50MB. FreeDOS + DOSAPPS takes up 13MB. There is no easy way to shrink down the HDD image (eg. to 20MB), or to enlarge it (eg. to 100MB), AFAIK, while maintaining structural consistency.
I'm sorry but, what do you mean with "structural consistency"? Just as we did with the floppy image, which is still 2880KB but with more free space than a typical one, we can use similar techniques now. I have several “uncommon” images, and I have no problems with them as long as they live as ram disks.

But before I get to the hdd image, I need to report my experience with it. I tested ubcd52a2 in a VM with several images connected simultaneously (as if I had more than one cd drive, plus one local HDD). Once in VC, I can see the additional drive letters, but I can't open their contents. This is while booting with isolinux menu. So, what I am doing wrong? I though that "each, any and all" drives would be seen now, but the behavior I see is the same as before. Could someone please point me in the right direction?

Additionally, I shall repeat a report about lower case. All the files in fdubcd must be upper case, including cab files and also their contents.

I'd appreciate some help about VC access to all drives, so I can really test the new fdubcd and report back.
Although there is still no comment to my question about getting access to additional drives, I want to comment on the new memdisk hdd c: drive.

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). The second issue is the "shift" on drive letters, that could easily confuse users (generating potential disasters, like wiping the wrong drive).

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)? A superfloppy image of about 42MB is capable of containing the current fdubcd, including all the files expanded too. MEMDISK should be capable of booting such superfloppy too, it would waste less space and it would not shift other hdd letters.

@Victor, if necessary, I can provide such empty floppy image, formatted with FAT16, together with the relevant memdisk parameters. It would need the content of fdubcd, patched to be used as (super)floppy instead of hdd. From a certain point of view, we would be going back to use fdubcd.img only, but bigger than 2880KB.

Evidently this only makes sense if someone can explain how (exactly) using a hdd (or fdd for that matter) for fdubcd is better than using the previous ISO image method.

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

Re: UBCD V5.2 discussion

#72 Post by Victor Chew » Sun Dec 16, 2012 12:56 pm

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

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

Re: UBCD V5.2 discussion

#73 Post by ady » Sun Dec 16, 2012 6:01 pm

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

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

Re: UBCD V5.2 discussion

#74 Post by Don Manuel » Mon Dec 17, 2012 2:23 am

One information would make it easier to understand too: how did you create this 50MB hdd-image?

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

Re: UBCD V5.2 discussion

#75 Post by Victor Chew » Mon Dec 17, 2012 12:29 pm

Since this was also happening in previous versions, then what's the gain of changing to use a hdd image for fdubcd?
It was to work around this issue with grub4dos.
One information would make it easier to understand too: how did you create this 50MB hdd-image?
It was a bit of a trial-and-error. I ended up using VMPlayer to create the image, run the FreeDOS CD to populate the image, delete the unnecessary files, move the files from FDUBCD+DOSAPPS over, then use WinImage to defrag and add the MBR.
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.
Any suggestions on how to do that would be appreciated. Of course, it will have to work with both memdisk and grub4dos.

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

Re: UBCD V5.2 discussion

#76 Post by Don Manuel » Mon Dec 17, 2012 2:07 pm

Maybe you could give linux a try

http://www.syslinux.org/wiki/index.php/Hard_disk_images

This would give you more control about the outcome I guess.

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

Re: UBCD V5.2 discussion

#77 Post by ady » Mon Dec 17, 2012 5:54 pm

Victor Chew wrote:
Since this was also happening in previous versions, then what's the gain of changing to use a hdd image for fdubcd?
It was to work around this issue with grub4dos.
Again, if we see the additional drives listed but we have no real access to their contents, then what's the gain? Moreover, the shift in drive letters is a negative effect of this change, among others.
One information would make it easier to understand too: how did you create this 50MB hdd-image?
It was a bit of a trial-and-error. I ended up using VMPlayer to create the image, run the FreeDOS CD to populate the image, delete the unnecessary files, move the files from FDUBCD+DOSAPPS over, then use WinImage to defrag and add the MBR.
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.
Any suggestions on how to do that would be appreciated. Of course, it will have to work with both memdisk and grub4dos.
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.

Regarding the (hdd) image, there are several methods to create it. Since it is only going to be used as a ramdisk, you don't really need to leave unused sectors between the MBR and the (first and only) partition (although I would still leave sectors 1, 2 and 3 unused for other reasons). You don't need 2 FAT copies either. I would recommend a cluster size of 2KB, FAT16 CHS type, and the whole hdd image should complete a full cylinder, Cx255x63 for best BIOS compatibility. Adding memdisk CHS parameters and "harddisk=#" would also improve compatibility, so different programs would identify the CHS parameters as expected, independently of BIOS.

Now, any hdd image comment above is still dependent on finding a real gain for this change. 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.

---
Victor,

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?

BTW, HDClone 5.2.2 is out.
---

drizzle
Posts: 2
Joined: Fri Dec 14, 2012 12:33 pm

Re: UBCD V5.2 discussion

#78 Post by drizzle » Tue Dec 18, 2012 9:58 pm

A beta Memtest86+ v5.00b1 has been available since May 2012 .. it is really a beta with known bugs. A big feature is multi-threaded testing ... really reduces the time if it works correctly on your motherboard.
http://forum.canardpc.com/forums/73-Mem ... cial-forum

I think it would be a nice addition to UBCD (in addition to keeping the tried and true v4.20).

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

Re: UBCD V5.2 discussion

#79 Post by Victor Chew » Tue Dec 18, 2012 10:05 pm

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

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.
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.
BTW, HDClone 5.2.2 is out.
Noted. Thanks!

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

Re: UBCD V5.2 discussion

#80 Post by ady » Wed Dec 19, 2012 3:12 am

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.
Noted. Thanks!
A little typo of mine; it is actually new version 4.2.2. Sorry.

Post Reply