The strange thing is I remember getting HDDErase to run before on the same machine from a USB drive. I recently reformatted my internal hard drive using DBAN. Could that have anything to do with the problem?

I don't see an option in BIOS setup to select the USB boot mode. There's a "USB Emulation" section that has "Enabled" and "Off" options and is currently set to "Enabled". This is on a Dell Inspiron 6400 if that's any help.

I tried activating the USB drivers under FreeDOS with various combinations of settings, but none of them worked.

Like Icecube mentioned in his previous post, run "drd" from the DOS command prompt. If your USB drive is not assigned a drive letter, you will have problems with all FreeDOS-based apps (not just HDDErase).

In this case, you will need to find a way to get your USB drive to be recognized under FreeDOS (try adjusting the BIOS options, or run "usb" and tweak the various USB options).

It works fine for me in qemu and VirtualBox. I don't need to select anything special. But I am not able to see the qemu/VirtualBox CD drive.

Thanks for fdubcd.iso.gz. Got it working under VMWare (Player 3.0.1) with the same behaviour (T: => emulated CDROM drive; cannot see physical CDROM drive).

I can see the difference is that fdubcd.iso.gz uses isolinux as the bootloader, which in turn boots fdubcd.img using memdisk, whereas my fdubcd.iso uses fdubcd.img as the boot image. My tiny brain is exploding under all this complexity. Do you know why the former assigns T: => emulated CDROM drive, while the latter assigns T: => physical CDROM drive?

Quote:

I found a bug in the implementation of mdiskchk.com in autoexec.bat

Got it! Updated autoexec.bat.

Anyway, I think this approach has potential for those booting from USB CDROM drives or memory stick but have problems getting their source devices recognized under FreeDOS. There might be side effects though that will require further testing, plus we need to write scripts to generate fdubcd.iso.gz, plus we need to settle on the steps to add customized FreeDOS apps so that upgrading to a new version of UBCD is as easy as possible, so let's explore this in the next release.

I can see the difference is that fdubcd.iso.gz uses isolinux as the bootloader, which in turn boots fdubcd.img using memdisk, whereas my fdubcd.iso uses fdubcd.img as the boot image. My tiny brain is exploding under all this complexity. Do you know why the former assigns T: => emulated CDROM drive, while the latter assigns T: => physical CDROM drive?

When you make an ISO with floppy or hard disk emulation, the floppy or hard disk will be booted end the rest of the ISO will be invisible. AFAIK this is by design. When you use no-emulation on your ISO, you see the full iso (ISOLINUX, GRUB(4DOS)).

Victor Chew wrote:

Anyway, I think this approach has potential for those booting from USB CDROM drives or memory stick but have problems getting their source devices recognized under FreeDOS. There might be side effects though that will require further testing, plus we need to write scripts to generate fdubcd.iso.gz, plus we need to settle on the steps to add customized FreeDOS apps so that upgrading to a new version of UBCD is as easy as possible, so let's explore this in the next release.

Who is online

Users browsing this forum: No registered users and 4 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum