RAM Loading

Current status
The W2k3 loading system has turned out to be a revolutionary solution for creating MS systems that load an image in RAM and start it from there.
We have been using it for quite a while to load in RAM ISO or SDI images of PE systems.
The initial boot media (which can be a cd, a usb stick, a hd,...) is, after the loading, free to be removed or to be used for other purposes.

The ISO based system results in a system where the system drive appears as a ReadOnly one, leaving the bootmedia we booted from, free for further use.

The SDI based system is preferable since on one hand the system drive is Writable and on the other it can be prepared as a NTFS compressed filesystem leaving us more free space in RAM.
The disadvantage of a SDI based system is that its creation depends on the installation in our system of an extra SDI management system (MS Windows embedded subsystem) which is unnecessarily complex to use and not easy to fully automate.


New developements
In this post we will use an excellent idea (presented in the thread of Booting Xp from RamDisk) that has been recently used in the context of loading and booting a normal XP system from RAM !!!.

Thanks to the work of euhenio, dennis123123, jaclaz, HighwayStar ...
http://euhenio.mam.by/
http://www.911cd.net/forums//index.php?s=&...st&p=127683
we now know that the w2k3 loading system is capable of loading in RAM not only ISO and SDI images but also normal disk images like those created by filedisk freeware virtual disk management utility.

Note: This finding, although independent, is actually not new.
It has been known for several months now at boot-land but this knowledge unfortunately never found its way over to 911cd.
Highwaystar has used it and even developed winbuilder scripts for this (ramboot winbuilder scripts)

It turns out that we can build systems similar to the SDI based ones that however do not have the disadvantages that were mentioned above. The creation of the disk image is straightforward and is actually fully scriptable.

In short, the process involves the creation of a disk image (we may use filedisk to create it), the copying of the files of a PE system and replacing if necessary the ramdisk.sys driver with the w2k3sp1 version.
Finally, the loader files are the well known w2k3sp1 files which allow the loading of the image in RAM.

Below is an attempt to present a step-by-step description of the logic:

Building instructions

Needed Files
1. Find a copy of RAMDISK.SYS, SETUPLDR.BIN and NTDETECT.COM from a W2k3Sp1 source cd or system
and copy them in a directory of your choice. Let us represent it with %W2k3SP1%

2. Install filedisk:
http://www.acc.umu.se/~bosse/
http://www.acc.umu.se/~bosse/filedisk-15.zip
in your system (you need to do this only once)
Preferably put filedisk.exe in your path so that is easily accessible.

3. Prepare your files for your PE system.
Use any building environment you like (pebuilder, reatogo, ubcd4win, winbuilder,..)
We need either the final output files OR the prepared iso.
Keep the size small enough, in any case < 500M.

RW RamPE systems: The procedure
4. Specify a folder that contains the PE Files.
For the sake of the presentation let us call the path to the PE Files as %PEFilesDir%

(i) %PEFilesDir% could be for example the outdir of pebuilder (e.g. c:\pe\BartPE)
(ii) In case you want to start with an ISO containing the PEFiles (e.g. c:\pe\pe.iso) you can mount
the iso file with filedisk as a drive (say I:)



and your %PEFilesDir% will be I:

5. Create somewhere in your system an initially empty disk image (say c:\pe\rampe.img) that is big enough to host the PEFiles (size<500M),
format it with NTFS compressed filesystem and mount it as a RW drive, say R:



Choose the 256M size appropriately so that it is large enough to host the files of your build and also leave some free space.
Take into account that by using ntfs compression our files occupy less space than their total uncompressed size.
The extra space you leave will appear as available writable space on your pe system disk.
In this way you can spare the use of ramdrv if you like.


6. Copy the contents of %PEFilesDir% to R:



NOTE: One may use robocopy instead of xcopy for more options

7. If your files were not generated from a W2k3-SP1 system you need to replace the ramdisk.sys with the w2k3 version
Supposing that you have the w2k3sp1 files in %W2k3SP1% dir



8. Unmount any filedisk drives


9. Prepare W2k3 loading system (need files from a w2k3 with at least SP1)
The details depend on the boot media.
Below we describe two common cases where we boot from CD and from a USB stick.

9a. Boot from CD and load in RAM

Create a folder/file structure (upper case) in some folder, say RamPE




The contents of winnt.sif is



Build an iso out of this by running mkisofs with a commandline similar to next code (we assume we are running from the directory that is the parent folder of RamPE folder of step 9a)



Burn the RAMPE.ISO and test your new boot cd.

9b. Boot from a properly formatted USB stick/disk

Format your USB (flash) drive with a utility (e.g. with standard XP format, HP utility, pe2usb, ...)
(we need a drive with standard MBR calling NTLDR)
Note: For better compatibility format with FAT16

Copy in the root of the USB stick the following



The contents of winnt.sif is



Boot with this USB drive and test.




Hope you find this guide usefull.

Regards

Thats pretty cool, can't wait to play with it.

Nice to see a solution that is freeware, not controlled by MS, other then still needing the ramdrive from 2k3.

Thats a diffirent idea and simple.Thanks.I have two copy of pe with sdi ram load 55.mb and 119 mb. with network support.I'll try this maybe better.



Sdi mounter - maker in embedded studio already free to use.Pe is not free is you don't have one copy of windows xp.Another option Live slax for me

VERY good!

With this and XP Ramboot we finally got "freed" from the SDI "legacy" and it's "custom" format.

I know I repeat myself, but while I do like a lot filedisk, I have found that it has on some machines some problems and moreover it's installation procedure is more complicated than needed, as an alternative you can use Ken Kato's VDK and DSFOK toolkit fsz, see my post here for more insight:
http://www.911cd.net/forums//index.php?sho...19056&st=49

Quick guide:

Just put fsz, vdk.exe and vdk.sys in the same directory



will create the file



will install the driver, start it and mount the image



will link the letter R: to the image



will format it

Once you have finished



will unlink the drive letter, stop the driver and unnstall it.

Once it is formatted, the image can be re-mounted with:


(mapped to the first available driveletter)
or

(mapped to the R: driveletter)


jaclaz

I'm really glad that you are not tired of repeating extremely useful info .

I am also biased towards vdk and once I verify the procedure with vdk I will bind your instructions in my first post.

Thanks

Thanks aec and jaclaz, at first I dropped the procedure due to the filedisk installation requiring reboot, but now it seems much easier.
I will experiment this new (for me) to boot PE system.

Well I just try vdk and get this error :

D:\Multiboot\Tools\dsfok>vdk OPEN 0 vdktest.img /RW
Virtual Disk Driver for Windows version 3.1
http://chitchat.at.infoseek.co.jp/vmware/

Installed the Virtual Disk Driver.
Failed to start the Virtual Disk Driver.
Impossible to create already existing file. <= translated message which seems to come from the OS.

Of course previously I already create vdktest.img with fsz successfully.

Update: I try on my other machine and all works well. So the problem appears on my main machine. But how to solve this problem? On this machine
I usually use vfd without any problem.

Update #2: I found that I have to use suite of commands:
vdk install
vdk start
vdk open 0 vdktest.img /RW
vdk link 0 0 R:
== other commands here
vdk close r:
vdk stop
vdk uninstall

so that vdk work on my main machines.
Typing directly the command "vdk open 0 vdktest.img /RW" failed on my machine with no vdk installed.

I thought 500mb was a limit of sdi - is it a limit of w2003, or just advice?

Quite strange.

Some Registry permissions?

R: letter already mapped (and remained "sticky" in the DosDevices enrtry in Registry)?

The "vdk OPEN" command should be a "shortcut" to the "proper" series of commands "INSTALL, START, OPEN" as well as "REMOVE" should be the same as "CLOSE, STOP, UNINSTALL".

However, if the right series of command appears to be working, it is still better than the reboot required by filedisk, assembling them in very small CMD file is trivial.

Have you tried my pseudo-GUI for it?
http://home.graffiti.net/jaclaz:graffiti.n...ts/VDM/vdm.html
(it uses the command line "vdk OPEN * imagefile /RW" for the "ezMount feature)

jaclaz

There are different images.

XP embedded sdi image: a hard disk image with a header.
8 sector header: sector zero of a hard disk. And partion geometry use CHS 63 sectors.
Therefore boot sector of first partition is at sector 71.
A hd sector contains 512 byte data.

71*512=36352
Idea:
Windows 2003 SP1 setupldr.bin read imageoffset and jump to a partition boot sector.

Image x:\img250.img contains a partition. This image start with a boot sector: offset is zero.BartPE does boot. This is a sdi ramloader without the sdi driver.
"/rdimageoffset=0" is not required and may be abandoned


A Kent Kato vdk.sys vmware image contain boot sector at 128.
Be aware, there are different vmware images.
128*512=65536Loading failed. Maybe a different offset or CHS translation.

NO, actually vdk defaults to a geometry of Nx64x32 on RAW images, so bootsector is on sector 32 or CHS 0/1/1 with that geometry, see my post here:
http://www.911cd.net/forums//index.php?sho...19056&st=49

for the trick of using .pln files to "force" Nx255x63 geometry.

jaclaz

Yes you are probably right, when the driver installs I have MS Windows Defender (MS anti-spyware) notifies me of the action. As I set Windows Defender to wait for me to validate any unknown change to the system by unknown program (e.g. registry change), maybe there is a timing problem for following commands.

I am used to command line, so as far as it works, no problem, and vdk is better then filedisk (reboot required).

Yes I take a look at the GUI version vdm.cmd. There is no vdkread.txt so I rename readme.txt to vdkread.txt.
Personally I'll use the command line, seems for me to be faster (also with command recall).

@jaclaz
How can I mount the bartpe.iso with vdk ? Using normal "vdk open 0 bartpe.iso" then mount it gives drive not ready.
filedisk has /cd parameter on mount operation. What is the equivalent for vdk ?

There is none.
VDK has not .iso support, it is a feature I requested some time ago to Ken, but until now it was not implemented.

Not that it is really missing, besides filedisk there are several other "Virtual CD" apps, including Microsoft own VCDcontroltool:
http://support.microsoft.com/kb/916902/en-us

Or the one that I normally use:
VirtualClonedrive
http://www.elby.ch/en/fun/software/index.html

That one usually have installed anyway to "peek" into .iso's.

For the record, the version of filedisk by Gilles Vollant:
http://www.winimage.com/misc/filedisk64.htm
also supports .bin images. (don't be fooled by the "64" reference, the download has 32 bit exe too)

jaclaz

Just finished my first vdk images according to jaclaz instructions and they boot just fine.
Also no special rdimageoffset is needed.

Furthermore, as far as I know, there are already solutions for installing filedisk service without rebooting.
- There is a driver installer utility (instdrvw.exe).
- I also remember vb and autoit script solutions.
I will search for the links but in case someone has them handy, please post them.
In any case I think I could easily compile a similar utility in c.

regards

For your information, I followed aec's procedure, and the rampe.img loaded just fine with my key.

Cannot say if it helps, but some time ago I made a small related search, results are here:
http://www.boot-land.net/forums/index.php?...c=461&st=16


cdob post above made me realize that the " /rdimageoffset=" is just, as the name implies, an offset from the beginning of "disk" (actually file being a disk image) to the bootsector, I had never fixed my attention on SDI file format.

This opens the possibility of using a "full hard disk" image, either with the Nx255x63 or Nx64x32 geometry, including MBR, hidden sectors and possibly other partitions too, though I cannot say how it could be useful, unless we can do, on USB sticks, some kind of multiboot that allows the editing of WINNT.SIF, but maybe some other member can find some use for the possibility.

Also, as soon as one verifies the position of the bootsector on .vmdk images, reported as 128 by cdob, it will open the possibility of using directly VMware disks or, with a 6 sectors offset, virtualbox ones:
http://www.911cd.net/forums//index.php?sho...19155&st=22

jaclaz

Tests with flat and sparse VMWare vmdk disks.

Two disk images (flat and sparse, size 256M), were created with VMWare WS 5.5.3.
From within a virtual machine they were prepared with 1 primary partition and formated with NTFS +compression.
They were mounted/unmounted with VMwareDiskMount.exe


Results
Flat (preallocated space):
rdimageoffset=32356 [63*512]
BOOTS OK

Sparse (growable):
rdimageoffset=97792 [(128+63)*512] (has an 128 sector header)
DOES NOT BOOT


regards

Note that the filedisk /mount command requires an absolute path to the disk image.
Without the absolute path (or even with .\disk.img) it will report file not found !
Currently I use filedisk over vdk since on my system vdk has intermittent problems (failure) to start or to open (link) image file.

As some members might know, I am collecting all RAMdisk/FILEdisk related links I can find here:
http://www.boot-land.net/forums/index.php?...=1507&st=0#

The new link for IMDISK is this one:
http://www.ltr-data.se/opencode.html




jaclaz

Links updated.

Looks like a very interesting tool, thanks jaclaz for pointing out this software. Source provided: excellent!

Thanks jaclaz!

More interesting stuff to play with.

Filedisk installation without reboot link #1 by Bilou Gateux

post #4
link found by Jaclaz and posted @ MSFN.org board

link #1 installer based from my own post on MSFN.org
link #2 The page cannot be displayed

@bilou_gateux

Thanks for the links.

For the unaccessible link#2 I've found the alternative link
FileDisk uA - Virtual Disk Driver.

Also here is the link for vb code by pcuser
pcuser's vb code

and finally pcuser's ISO image extractor utility (based on filedisk)
unisofs: an ISO image extractor by pcuser.

Thanks again

Wow - works like a charm

start /wait fsz rampe.img 312000000
start /wait vdk open 0 rampe.img /rw /p:0 /l:y:
start /wait format Y: /FS:NTFS /C /V:RAMPE
start /wait xcopy BartPe\*.* Y:\ /E /H /R /Y
vdk close 0

boah

Making junctions from X to anywhere !!!

To avoid those vdk errors make sure vdk is some where in your path - best system32 - and do not load it locally whenever possible.
Sometimes vdk gets a lttle nasty when it is launched from changing places.

Reposting links by Jaclaz
http://forum.winimage.com/viewtopic.php?p=938

Links to IMDISK:
http://www.ltr-data.se/opencode.html

updated in post #20

The tool has greatly improved in the three months since original post, with more features added.

The author, Olof Lagerkvist, is VERY open to suggestions, ideas, features requests, and, of course, eager to receive bug reports (if any) and contributions.

A new thread to this effect has been started here:
http://www.boot-land.net/forums/IMDISK-by-...vist-t2072.html

and will probably soon become a dedicated sub-forum.


jaclaz

Is using a sparse vmware disk possible? I saw in a previous post that this was attempted, but failed. Does anyone know why it would have failed?

Thanks,
Galapo.

@Galapo
Most probably sparse image are NOT, like "normal" ones, simple RAW images with prepended a certain number of sectors, or, as I suspect from the fact that you need a "special" tool like mksparse to create a sparse file, it is a feature or attribute of the file under the NTFS filesystem that gets lost when copied to RAM.

Besides, at least theoretically, even if they would boot (and they do not, as cdob reported) they won't be of much use.

I mean, and correct me if I am wrong, you have, say, a growable image sized 100 Mb (that with NTFS compression already holds some 170÷210 Mb of data) the image is copied to RAMDISK, which of course allocates enough memory for the image AS IT IS, no more.

Then you add some data to the image, it grows, only two possibilities exist:
1) either some data "slips" off the image (as in a LIFO or FIFO stack) and thus the filesystem gets corrupt
2) the RAMDISK needs to dinamically resize itself while already containing data and running the OS from itself, which is something that I don't think is even possible, just think about all locked files, files in use, etc.

However I would be interested to know WHY you would need such a feature, I am completely failing at finding a practical use for it, and I don't see why you cannot have a fixed size boot image (either vmdk or RAW) and then hardlink to it as many growable images as you like...

jaclaz

Hi jaclaz,

My reason is this: that we could create a sparse disk, say 500mb, load on say 200mb of files, which would leave 300mb of free space. When loaded into ram, the image would initially only take up 200mb, but would allow for the additional writing of files. It would thus overcome the limitations of the fbwf which is limited to 128mb. The benefit is that it allows for the possibility of free space without having to have this automatically reserved like if a 500mb flat image was created.

Does this make sense? It may not be possible though it seems.

Thanks for your response.

Galapo.

Still don't get the advantages of not having the smallest possible BOOT image and hardlink to it a separate fixed or growable image residing on USB device and never loaded into RAM.

And why yould you use fbwf on a RAMDISK?

Though as said, as far as I know I don't think that it is possible, I am really interested to understand the need for such a setup, expecially since the recent evolutions of IMDISK and the new "direct" channel established with it's author "might" render this possible in a (hopefully near) future time.

Also, we might start to reconsider the preoccupation (which I contributed to spread ) about write cycles of Flash mamory of USB sticks, due to a few factors:
1) bettered wear leveling techniques implemented in newish USB stick controllers
2) increased number of write cycles of newish Flash memory chips
3) amazing lowering of the price of the devices, a "No Name" 1 Gb USB stick can be found currently for less than 15 Euros apiece, in some cases nearer the 10 Euros border

As in a RAMDISK booting the volume that really gets thousands of write cycles is the System one and it is in RAM, the "storage" volume on the stick gets a lot less writing operations, and will probably have a more than satisfactory operating lifetime.

So, maybe, one could start to see USB sticks like a floppy, once it does not work anymore, you throw it away and get a new one.

jaclaz

This is utterly awesome.

To think, all the agro I went through to get an automated SDI system going!!!

Now all solved with this technique and a script 'a la' Sanbarrow's post above.

I can also see the day (soon) that I'll be using Imdisk instead of Daemon Tools. Right now, for shell integration in DT, you need 3rd party stuff.

About this:


Do we have any ideas about a suitable replacement for this file (heading towards a full non dependency on MS product)?

Rock 'n' Roll!!

d

Wow! This is awesome. I have to admit I was frustrated for a while, none of the resultant ISO's would boot in VMWare, kept saying that it failed to load the image. After farting around for a few hours I finally realized I didn't allocate enough RAM to the VM to actually LOAD the image. Allowing it 1 GB made it run fine.

I am stuck with one niggling problem. I have a fat juicy 8GB USB stick that will not initialize a BartPE built with Reatogo, I keep getting a "Session5_initialization_failed CODE STOP 0x00000071" BSOD. I thought the RAM load might help it but it does the same thing. I tried to rem out the "start /wait xpeinit -9" in init0.cmd but it doesn't help. I see a few other posters have the same problem and no answers yet. It WILL boot on a BartPE created with UBCD4Win or Winbuilder on the same 8GB stick. Any ideas?

I haven't been using it on sdi images etc, only on iso images loaded into ram so that I have a writable system drive. The advantage of the fbwf is that although you can set the cache size, it isn't actually used until files are written to the drive. In other words, the fbwf is comparable to a growable disk.

Galapo.

@Galapo
I see, but you must understand that here we are trying to "evolve" from the problems that RAMDISK .iso booting causes, as I see it the path is as follows:
1) "Classic" RAMDISK .iso booting:
- size limit of the image 512 Mb, max contents of the image 512 Mb
- read only or need to use FBWF
- only possible with PE based systems that accepts a read only filesystem

2) "SDI" RAMDISK booting:
- size limit of the image 512 Mb, max contents of the image, if using NTFS compression roughly doubling to 1024 Mb
- system is R/W
- no need for FBWF
- possible to use it with non PE systems, possibly including NT and W2K
- makes uses of XP embedded components or however proprietary tools not easily/legally available to a large number of people

3) "Filedisk or VDK" RAMDISK booting:
Same advantages of #2, but using FREEWARE tools
- using NTFS filesystem it is possible to create links to other filesystem images, thus the booting image can be very small (read VERY FAST when booting) and allows using it on systems with a limited amount of RAM

4) "IMDISK" RAMDISK booting - (in development):
Same advantages of #2, with additional capabilities, exceptionally useful for emergency recovery....

And in between the listed alternatives, there are "mixed" settings for particular builds.

Please, anyone, feel free to correct me and/or suggest additions to the above "evolution tree", I will readily modify the post to include them.

@Rootman
Definitely your problem appears to be Reatogo related.
If I were you I would post it where it belongs:
http://www.911cd.net/forums//index.php?showtopic=18609
I guess that Siegfried is the one that can possibly share some light on the matter.


jaclaz

Hi jaclaz,

Yes, I see the progression and development.

My personal setup at the moment has all programs located in a vmdk image which is itself located in a compressed and encrypted isz image. This allows a) the essential stuff to load into ram quickly and boot; and to have commercial software encrypted. Upon boot, a password is required to mount the isz image to y: and then the vmdk image is mounted to z:. I have an environment variable %programs% set to z:.

What would be good for me is if sparse images cannot be made to boot that they instead could be mounted into ram (a la the imdisk flat files), thus not having to "grow" on a disk. In this way, the boot image could be kept small, booting quickly and not taking up too much ram, but also since the image loaded into ram is a sparse file it would also not initially take up too much ram, even though it could be say a 500mb disk.

Galapo.

While I didn't post in that thread but had on a few others with the same subjects. There seems to be a few others having the same problem and no one has any answers.

Can anyone see anything glaringly wrong with this?



I keep getting the missing / corrupt txtsetup.sys error when I boot the rampe.iso

The same build works fine if I let pebuilder create the iso by itself

d

Some "semi-ramdom" thoughts:
1) it would be better if you used full paths, i.e. C:\BartPE instead of Bartpe and (say) Y:\RAMPE rather than RAMPE, by reading your batch I cannot say WHERE things come form or WHERE they go to
2) CHECK cases, they are known to create trouble:

3) This (or however first line when using echo command:

should be like this:

(otherwise on subsequent runs the lines will be appended)

...and you mean txtsetip.sif, not txtsetup.sys, don't you?

jaclaz

Thanks for that - a fresh pair of eyes is a great thing.

So now I have



Still not working, but nice to have a tidier set of command lines

Maybe it's something in the xcopy??

And yes I did mean txtsetup.sif !

@Captain Dan

I got missing / corrupt txtsetup.sif at random in the past too. I've no true explanation.

Currently I suspect either disc CHS geometry or txtsetup.sif location.

Try format image again.
Copy BartPe\I386\ files first, no subfolders.
Copy BartPe\I386\*\ subfolders next.


Added:

Remember different drivers are involved:
At RAM Image creating, ntfs.sys writes filesystem.
At RAMPE booting, setupldr.bin loads image to RAM and reads a NTFS partition.

Partition may be valid at ntfs.sys, but setupldr.bin may not recognice the same NTFS partition.
Missing txtsetup.sif indicates, setupldr.bin can't find txtsetup.sif. A invalid NTFS partition maybe one reason.

Try a FAT partition for testing purposes.


More random ideas:
Xcopy is not reliable in conjunction with compressed NTFS Images.
Did xcopy copied files to compressed NTFS partition without a error message?
What about if you insert a pause after xcopy? Wait some seconds and close image next.
Or use sysinternals sync.exe to close write cache.

To avoid these issues by xcopy and NTFS compression we're using "zcopy" custom developed by nikzzzz - you can find a small description and download link here: http://www.boot-land.net/forums/index.php?showtopic=1580

Also includes a few more tools for creating efficient images.

1st: I have to say "Many thanks to you, all guys, for this idea!"

2nd: The idea only, not tested by me, but it could work: If this BARTPE.IMG will be stored on read/write media (like hdd, usb flash), i think it could be possible to save some/all settings from running BartPE. When i customize something, i can export registry to the original BARTPE.IMG allready mounted.

What do you think about this idea?

Pavel

Maybe useful ...

We use a post-processing script that creates a regular BartPE, one version that loads into a 200MB vdk-mounted image an one that loads into a 300 MB vdk-mounted image.
Works quite reliable with 2k3-sp1 and higher.

It comes with the moa-built - here is the batch-link only
http://sanbarrow.com/moa21/makeall-moa21-016v2.zip

If you use it with regular bartpe - you need to comment out all the vmware-related stuff.

I really love the variant with the 300 MB image - this gives me 110 MB free in X: - I use no fbwf or ramdisk - instead of the regular ramdisk I mount my USB-disk as R: - so when I run my Moa-bartpe I have 110 MB free in systemdrive and 80 Gb free in %temp% and home and programs. That really rocks ;-)




Pavel - you do not actually change the image itself - you change the copy of the image in RAM - so it doesn't matter where the original image is coming from.

At captainDan

your script - we used the same for a while - is unreliable.
When copying files to the img-file you should copy slowly.
Xcopy is too fast - it gives false results on available space and skips files without notice.
We use robocopy instead now - if robocopy thinks the image is already full - it waits some seconds and then tries again.
Try something like this:
robocopy.exe %bpedir% Y:\ /E /R:3 /W:7 /ZB /COPY:DAT

Y: should be replaced with what ever you mount that img to

Thanks to all who had ideas and input.

I solved it.

Ready.....?

I had the wrong SETUPLDR.BIN (golf clap)

2 files are needed from W2k3 sp1 - not just ramdisk.sys

Nevertheless, I have learnt how to tidy up my command lines now and have got a better understanding of a few other things.

I have it going now and also in a better way thanks to some of the other code I saw lying around in this thread (sanbarrow, jaclaz)!

Onward!

d

@sanbarrow



No, my idea is different. Loading BARTPE.IMG to RAM (as read/write image) and mount it as read/write (for example) as drive I: (like Image). When customise something in running BartPE (in memory, so bartpe.img in ram), export this settings to original image file (stored on read/write media) allready mounted as drive I:, then unmount.

Is it clear?

Pavel

Yes, what is needed is a "commit changes" command that copies back the contents of the image in RAM (modified) to the image phisically on disk.

If the actual file, say, myboot.img is not "locked" or however "busy" I guess that one can mount it with filedisk/vdk/imdisk to another letter and simply copy files from one to the other, but most probably a number of files inside the RAM mounted image are locked?

Otherwise one would need something like a "memory dumper".

This elder image driver:
http://www.p-nand-q.com/download/diskfile.html
came with such an app, "pdisk" but as said my guess is that there will be problems with files "in use".

jaclaz

Or....perhaps the kind of technology that allows a 'live' backup to another place....like Volume Shadow Copy.

I think DriveImage XML uses that service.

@jaclaz


Uh, i think about changes in registry only. This way, you can export registry changes (via sysinternals regmon), then mount registry from mounted file as drive I: to local registry, then import registry changes to mounted registry and then unmount registry to I: drive (mounted as read/write). Uff, difficult to describe it...

Pavel

I see, but why self-reducing the possibilities?

If the "full" way is possible, one could also add programs, personalize the desktop, change icons...in one word work interactively like on a HD based system.



I am not at all familiar with that technoogy, but it seems like a good idea.

jaclaz