Jump to content











Photo
- - - - -

MEMDISK Limit & creating bootable DOS image


  • Please log in to reply
4 replies to this topic

#1 JimWright

JimWright
  • Members
  • 2 posts
  •  
    United States

Posted 14 February 2013 - 05:05 AM

Hello all, I've been beating my head against this issue for a few days, and need some help here...

I'm attempting to build a bootable DOS image that will be served via SysLinux, specifically on a Windows 2008 server, using Serva to handle the PXE part.  According to the Serva docs, booting to FreeDOS is supported, and I've successfully served up an the FreeDOS 1.0 Live image, the relevant SysLinux options listed in the Serva docs for this are:

 

kernel   = memdisk
append   = initrd=NWA_PXE\$HEAD_DIR$\fdboot.img

 

I'm now attempting to build the image I need to serve, which is based on MS DOS 6.22, and will contain a number of BIOS firmware updates for various systems, the firmware updates all run via DOS.  I've successfully created a bootable USB key with everything I need, and am using this as the basis for the image that will be served.  Unfortunately, with the BIOS updates, my image is significantly larger than the average floppy, and definitely beyond the 2.88Mb size I've seen others mention.  At present the image I've created is a 256Mb volume, so, my first question is, what is the upper limit, if any on the size of an image that MEMDISK can handle?

As I mentioned, I've created a bootable USB flash drive, originally an 8Gb volume, and after some scavenging I've come up with an old 256Mb USB key, and have this booting properly.  But Windows keeps slamming shut on my fingers every time I try to build an image from a USB Key, I've downloaded a variety of tools (WinImage, OSFMount, IMGBurn) and none of these can properly make a .img or .iso of the USB key.  I finally had some luck with a utility called USB Image Tool, which did create a .img file, but when I tried to mount this in Windows (Virtual Clone Drive, OSFMount), the image didn't appear to have a valid file system, and attempting to boot any image I created resulted in a variety of amusing failures when booting via SysLinux.

So, my second question is, how can I properly create an image of my booting USB key, presumably preserving the MBR, preferably from my Windows 7 desktop?  Or is there some other way to build a bootable image that I'm overlooking?

I've discovered am amazing number of ways to create badly formed images, but unfortunately have yet to stumble across the secret recipe to create a working image under Windows.  Again, I'd ideally want a Windows based solution, as I work in a Windows shop, and when I eventually hand this off to someone else, they'll need to be able to take over.  If I need to resort to Linux for this I will, but would prefer that as a last resort, as much as I hate to say that.  ;)

 

Thanks!
 



#2 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 14 February 2013 - 10:20 AM

Lots of things.

FIrst thing is the DOS image.

Memdisk is a (real mode) RAMdisk driver, i.e. it will load the image to memory.

This means that if you need/want a 256 Mb image it will occupy 256 Mb of RAM.

The limit is the RAM you have available.

Take into account that also the image is transferred, so, since Memdisk has internal support for decompressing both Gzip and Zip compressed files "on the fly", it makes a lot of sense to use a compressed image.

 

Obviously the smallest is the "base" image, the faster the transfer (and the booting) will be.

 

The issue is not as much about imaging your bootable USB stick, but rather in having Memdisk loading it correctly.

 

And it makes a lot more sense to leave that bootable stick alone and create a "proper" hard disk image, the smaller, the better.

 

The easiest way to do so (besides a number of tools that can actually create the image, mount it and also populate it with the files) would be to use a VM.

The most suited is Qemu (+Qemu manager).

The home site is -at the moment -"down":

http://www.davereyn.co.uk

Get it from here:

http://web.archive.o...uk/download.htm

http://web.archive.o...etupqemuk70.exe

 

The use of a GUI VM like the above is pretty much straightforward, you:

  • create a new virtual machine
  • create a new virtual hard disk for it<- you want to make a RAW Hard disk
  • add as "bootable media" your install source (floppy or CD)
  • install the DOS (in your case) as you would do on a "real" machine, doing all the tests and tweaks you need
  • close the VM and use the hard disk image for Memdisk booting through PXE

There is no problem whatsoever in imaging a USB stick, though, but I believe that your current USB stick is far too large for your "real" needs and it is very possible that - as is (this depends on the exact way you patitioned/formatted it) - it may not be a suitable image for booting through Memdisk (possible CHS geometry issues).

 

If you need specific help, just ask.

 

:cheers:

Wonko



#3 JimWright

JimWright
  • Members
  • 2 posts
  •  
    United States

Posted 14 February 2013 - 04:43 PM

Wonko, thanks so much for your reply.  I've installed Qemu Manager, set up my DOS environment again, and I have a drive called DOS.raw now.  What still wasn't clear was if this file can be used directly, or if I still need to convert or rename it in some way, none of the documentation I saw online indicated that I could load an image type of .raw or .gz, but I just tested this and it did indeed work!

 

Thanks so much!



#4 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 14 February 2013 - 08:29 PM

Good. :)

 

The RAW disk means that is a RAW ;) image, if you prefer a dd-like image or a "byte by byte", "sector by sector" image of a hard disk.

 

The extension is only a naming convention, a RAW disk image is .raw  in Qemu Manager, but a more common convention is to use:

  • .ima for floppies and for non-partitioned images, super-floppies and the like
  • .img for hard disk images and partitioned media

 

You can compress this image with gzip (or use 7-zip to do this) to gzip format, usually having extension .gz and Memdisk will be able to load this compressed image and expand it on-the-fly.

You can compress this image with PKzip (or use 7-zip to do this) ot zip format, usually having extension .zip, and Memdisk will be able to load this compressed image and expand it on-the-fly.

 

The differences being:

  1. the non-compressed image will be bigger (obviously) and thus need more time to be transferred through the network, BUT it won't "load" at all the "booting PC" processor.
  2. the gzip compressed image will be smaller (obviously) and thus need less time to be transferred through the network, BUT it will "load" a bit the "booting PC" processor.
  3. the zip compressed image will be the smallest (as zip compession is usually "tighter" than gzip) and thus need even less time to be transferred through the network, BUT it will "load" a bit the "booting PC" processor.

Additionally the gzip format is a "pipable" compression format, i.e. expanded data is produced while expanding, whilst zip is not, i.e. the whole file needs to be expanded before being available.

 

A lot of factors (network speed, PC processor/bus/Ram, etc.) may determine which of the three is actually "better" and overall allow a faster booting.

I would say the faster should be the gzip one, but I would not bet on it :unsure:.

 

:cheers:

Wonko



#5 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 07 March 2013 - 05:56 PM

Update.

The Qemu Manager is available here:

http://www.sorted-sy...mu_manager.html

http://www.sorted-sy...com/qmdown.html

 

EDIT: RE-update, the links above are not working, get it through the Wayback Machine as in post #2:

http://reboot.pro/to...image/?p=167861

 

:cheers:

Wonko






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users