It seems to me that there are a few misunderstandings/misconceptions in this thread that maybe I can contribute to clarify.
In his original post, th0ghts
asked three things in the same sentence:
how can i custom the size, make it bootable and be able to mount it using memdisk?
Let's see them one by one:
how can i custom the size
No problem, done.
Now that one method (approximated to the megabyte) has been proved to be successful, one could use other methods to create a file (empty, but mountable in Qemu) of any given size.
There are several utilities that can do that, please find here:http://www.911cd.net...showtopic=15843http://www.911cd.net...showtopic=15481http://www.911cd.net...w...=14189&st=8
links to some of them, to which you can add filedisk:http://www.acc.umu.se/~bosse/
and IMDISK, already seen
how can i make it bootable
A number of options have been given, done.
how can i be able to mount it using memdisk
Now this is the remaining point.
Here we need to digress a little and talk a little about theory of RAM disks.
More technically prone members will surely pardon me
if I use some improper or over-simplified terminology or similitudes to explain myself better (hopefully)
First thing is to understand that RAM disks do NOT actually exist.
I mean, unlike a floppy drive, a hard disk or a USB Mass Storage Devices, they cannot be connected
, dropped on the floor
, touched, smashed
They are VIRTUAL devices that are created, temporarily and "on-the-spot" by RAMdisk drivers
, using a portion of the RAM memory inside the computers.
There are basically two types of RAMdisk drivers:
1. OS INdependent RAMdisk drivers, generally BOOTABLE
2. OS dependent RAMdisk drivers, divided in in two subcategories:
2.a OS dependent BOOTABLE RAMdisk drivers
2.b OS dependent NOT bootable RAMdisk drivers
Some known examples of each category:
1. OS INdependent BOOTABLE RAMdisk drivers:
2.a OS dependent BOOTABLE RAMdisk drivers:
Microsoft Server 2003 SP1 or later RAMDISK.SYS (specific to NT based Systems)
Diskless Angel driver wdsys.sys (specific to NT based Systems)
2.b OS dependent NOT bootable RAMdisk drivers:
(specific to NT based Systems)
a number of other ones, a partial list is here among "FILEdisk" ones:http://www.boot-land...?showtopic=1507
(specific to DOS):
Microsoft DOS RAMDRIVE.SYS
Franck Uberto's xmsdsk.exe:http://www.geocities...rv/fu_rd19i.htm
What is the difference between the 1.OS INdependent and the 2.OS dependent ones?
Basically the moment in which they come "into play".
OS INdependent ones create the RAMdisk BEFORE any Operating System is booted, and do this even if NO operating system is present.
OS dependent ones create the RAMdisk AFTER the Operating System, or at least a small part of it, has already being loaded.
In other words, OS INdependent Ramdisk drivers "hook" on the BIOS of the machine, whilst OS dependent ones "hook" on the Operating System.
From the above, it would appear that an OS INdependent RAMdisk can be used to boot ANY Operating System, but unfortunately this assumption is WRONG!
To remain in the restricted area of the most used Operating Systems, DOS and any dos based version of windows, like Win95, Win98 and Me, Linux in all his flavours and distributions and NT based windows, including NT, Win2K, WinXP, 2003 and Vista, one can draw a line (not necessarily between "good" and "bad", simply a line to separate them) with DOS/Linux on one side and NT based systems on the other one.
Without entering too much in the details and differences, DOS and Linux "trust" the information given by the BIOS (and thus any information "filtered" by the "hooked" upon the BIOS memdisk or grub/grub4dos) whilst NT based systems DO NOT, or to be more exact, do not trust the info in it's entirety/have peculiar ways to use it.
In the case of memdisk/grub/grub4dos, the RAMdisk driver creates the RAMdisk allright before the OS boots, but while DOS/Linux do use the information they give about the created RAMdisk while booting, NT based systems need a specific driver to take advantage/use this already created RAMdisk.
As per today, and as far as I know, this approach does NOT work with NT based systems.
In other words, whilst it is possible to boot NT based systems using syslinux/isolinux (from Peter Anvin, same author of memdisk) and grub/grub4dos to chainload "REAL" devices, like a disk partition, a floppy disk, a CD or disk images (also those of NT based systems, but limited to the "dos" initial part of booting) the same thing is not possible with "NOT REAL" or "VIRTUAL" devices such as a RAMdisk is.
On the contrary, and rather obviously, 2.a OS dependent BOOTABLE RAMdisk drivers, like the specific ones that were listed above can boot without any problem NT based systems, with two limitations:
1) Size of the image, 500 Mb max for MS RAMDISK.SYS and 4 Gb!
2) Total amount of RAM physically present on the machine
Some further ideas/considerations can be found here:http://www.boot-land...?showtopic=1441
Now, back to the original request, Recovery Console is something in between the "dos" part of NT based systems booting and a "full" (with GUI) NT based system booting, so it could maybe possible
, though personally I would NOT be so sure about it, that Recovery Console can be booted through either memdisk or grub/grub4dos.
Out of the three mentioned projects, the one more "NT friendly" is grub4dos, so it is strongly suggested to follow windrv
's suggestion and try with it, as there are more probabilities
it might work.
Otherwise, I have to point you to the "Common Sense" advice given together with Board Rules:http://www.boot-land...?act=boardrules
letter f., with particular regard to f.1 and f.2
and, if you wish, you can try a RAMdisk boot approach using Server 2003 SP1+ RAMDISK.SYS or the diskless angel one.
maybe, it would be possible to chainload through grub4dos an image containing RAMDISK.SYS ?