I use CFC's to boot industrial CPU boards on various machines, and have done for many years.

All was well using WinImage until the CFC's got over 1 gB, and after that it was problematic.

Then the CFC's changed and only the Industrial versions were bootable.(on Windows)

Simply creating a vhd image and then writing it onto another didn't work anymore.

Now I am in situation where the 2gB CFC's are no longer available, so I need to read a 2gB CFC and rewrite

it to a 4gB.

So, discovered RMPrepUSB, and downloaded the latest version, but there are some problems.

Reading the source CFC with "Drive -> File" and picking various formats (vhd,img , raw etc) does not transfer the second partition when you use File->Drive and select the .vhd you just created. Strangely the .raw image is

the right size , but it writes nothing to the target CFC with "File->Drive"

The detail of the source CFC.

WinXP embedded

HORM protected C: as primary partition.

Second partition as D: used for changable files.

I selected / used the following options in RMPrepUSB

Bootloader WinPE , NTFS, Boot as HDD

There has to be a better and simpler way to do this.

Can SKS tell me how make a 4gB bootable CFC with two partitions from a source CFC that is less then 4gB.

Whenever possible, try to be explicit, please, it is a board, not a SMS.

Now seriously, if you have an "original" (of *whatever*), it can always be "cloned", though RMPREPUSB is not necessarily the most suitable tool.

What you need is *any* dd-like tool, depending on the specific OS you are running, there may be "better" (in the sense of "easier") or "worse" (in the sense or "slightly more complex") tools, both command line or GUI.

Assuming you are running a Windows OS of *some* kind, I would suggest you Clonedisk, which is GUI and has quite a few additional features:

same applies to 7 and later though you might as well on these take the disk (the destination one) "offline".

In dsfi/dsfo disks are numbered exactly like in Disk Manager, so, example:

dsfo \\.\PhysicalDrive5 0 0 c:\CFImages\mynice2Gb.img

will make an image of the CF Card mounted as disk 5, while:

dsfi \\.\PhysicalDrive6 0 0 c:\CFImages\mynice2Gb.img

will deploy it to disk 6.

The only possible issue with CF Cards (when used with Windows) specifically is that they may be seen as "Removable" or as "Fixed" (some old models had a tool to change this setting, but I doubt that it will still work for newer ones), there may be the need for a filter driver (there are a few different ones available), but this won't affect a "dd-like" operation.

Well, there is actually no real need for USB support to boot a DOS (or FreeDOS) from a Compact Flash card, not even if the CF card is connected through an USB bus, as it is the BIOS that provides (if it has it) USB support.

And there are however DOS USB drivers, though they tend to be "picky", thus the y may or may not work in your specific case.

Maybe if you describe in more detail what you are actually doing/what your needs are it is possible to find a different solution from XP Embedded, which JFYI, is not necessarily XPe, which is (or maybe was) an (optional) GUI applied to a PE (Pre-install Environment) to make it more similar to a "full" XP:

Still JFYI, re-reading your post, the actual reason of the issues you had with RMPREPUSB derive from an old time misnaming of things.

A hard disk drive (or a hard disk drive like device, i.e. any device which first sector is a MBR) is often called wrongly "drive" (while it should be called "disk") and the *thing* to which DOS or Windows assign a drive letter is often called wrongly "drive" (while it should be called "volume").

To recap (think of diskpart items):

disk=the "whole" thing=\\.\PhysicalDrive <- rather confusing

partition=a part of the disk which contains a volume, which, IF it is a primary partition. in practice is the same as a volume

AND same as a "drive" i.e. the *thing* to which a drive letter is assigned=volume or "LogicalDrive"

Well, what I suggested earlier was more or less (or at least was posted meaning):

DO NOT use Winimage (it is not suited for the task because it deals mainly with Volumes and NOT Disks, and the rebuilding of hidden sectors often is "queer")

DO NOT use RMPREPUSB (it is not suited for the task at hand because it has way too many options )

You can use CloneDisk (though it is not needed and provides way too many options) BUT what you SHOULD really use is the dsfo/dsfi or *any* similar, simple DD-like tool capable of doing an exact clone of the disk, the additional advantage of using a command line tool is that its sintax and beaviour are easily describable and repeatable, whilst GUI tools may be more difficult to deal with (when it comes to describe their usage/settings)

You have to grasp this concept of making an exact copy of the whole disk or \\.\Physicaldrive , in this contents "read source" means nothing, you may well be reading just the volume (or writing just the volume).

The result with Winimage may boot, but likely you have an invalid filesystem extending beyond the actual size of the CF card.

The result of Clonedisk (even if it doesn't boot) is likely to be more accurate, but again there are many options in that tool that you don't really want/need and that may have led to the issue.

The result of RMPREPUSB means that you somehow managed to write the wrong bootsector to the volume (Windows NT/2K/XP bootector will look for NTLDR whilst the Vista and later bootsector will look for BOOTMGR).

It is possible that different CF cards, particularly when "switching" from 2 Gb to 4 Gb expose a different geometry to the BIOS (or the BIOS "expects" a different geometry).

Usually (FAT12/16) this is not an issue, but if you use XP or later and either FAT32 or NTFS, there may be this issue about the checking for geometry at boot time, which can be solved by adjusting geometry or patching the bootsector CODE, see:

Open a command prompt, navigate to where you unzipped the dsfo/dsfi, let's say C:\DSFOK and run:

dsfo \\.\PhysicalDriveN 0 0 my2GB.img

make DOUBLE sure that the N is the numebr corresponding to the CF card.

The C:\DSFOK\my2GB.img is now an exact, dd-like or "forensic sound" image of the "original".

Then try to deploy it to a new CF card, insert it and make sure that the Disk N is still the same and run:

dsfi \\.\PhysicalDriveN 0 0 my2GB.img

Now the "new" CF card is IDENTICAL, byte by byte, sector by sector to the "original", up to the max size of the "original" of course.

Whether this EXACT "clone" will boot (like the "original" did) or not may now depend on the way the target machine BIOS "sees" the device, and adjustments to the bootsector CODE (as said before) or to the actual CHS DATA in the MBR may be needed.

While you are at it, issue also this command:

dsfo \\.\PhysicalDriveN 0 51200 myfirst100.img

the myfirst100.img is a copy if the first 100 sectors, containing the MBR and (supposing you created the partitioning on XP) also of the bootsector of the first partition which is usually the active/booting one.

Compress the myfirst100.img to an archive like myfirst100.zip and either attach this file to your next post or upload it somewhere and provide a link to it, so that I can have a look at it contents and maybe understand where the issue may lie.

These CF cards are (as it is normal) used as hard disks, but what you posted is the beginning of the image of a volume (or if you prefer of a "super-floppy") as it's first sector is a boot sector.

The bootsector has (among the rest) these data:

Sectors Before=63 <- this means that the volume is intended to be first volume of a hd-like device partitioned on XP or earlier, i.e Cylinder aligned

Sectors per cluster=1 <- this may mean that this small cluster size was intentionally chosen when formatted or that the volume derives from "expanding" a smaller one

Sectors per Head=63 <- this is OK, and "normal"

Number of heads=64 <- this is "normal", but NOT OK, as it will make the volume not bootable on a larger device with a different geometry, such as 128 or more likely 255, this is what may be corrected by patching the code int he bootsector as said.

But I asked:

dsfo \\.\PhysicalDriveN 0 51200 myfirst100.img

and you issued INSTEAD:

dsfo \\.\e: 0 51200 myfirst100.img

Can you spot the difference?

You need to get this concept that the PhysicalDrive is the WHOLE thing and starts at absolute LBA sector 0, while the drive letter is assigned to a volume, in this case of a first volume at LBA 63.

Imagine the disk as if it was a book with several chapters.

At the beginning of the book there is the title, an index of chapters and the preface,and the book actually starts with it's chapter 1.

Your CF card has:

the very first pagesector - is called the MBR or Master Boot Record - and it contains the titleDisk SIgnatureand the index of chapterspartition table, indexed as LBA0

following 62 pagessectors are the preface (which in your case are actually blank pages), indexed as LBA1-62

on the 64th pagesector Chapter 1 (the volume) begins, it's first page sector is called PBR or VBR (Partition Boot Record or Volume Boot Record) or bootsector, indexed as LBA 63

Now, if you are tasked to make an INTEGRAL photocopy of the book, you start from it's very first page, and NOT from the first page of Chapter 1.....

Wonko, not only are you patient, but you have a sense of humour, which I like.
But your persistance is paying off, I now understand the point you have been
trying to get through.

The original image was provided by Advantech of Taiwan, whom are a Industrial computer supplier.
The image was dedicated to a PCA-6781 cpu board, which has an Intel Celeron M 600MHz (512KB L2).

From there the image was minimised to remove features I didn't want, and to make room for a partition on 2 gB cfc.
The Win XPe includes a HORM feature that protects C: from corruption or accidental deletion.
When copying the cfc's I have tried with HORM off & On, but it seems to make no difference.

1955488 KB total disk space.
746279 KB in 8340 files.
2500 KB in 847 indexes.
0 KB in bad sectors.
23258 KB in use by the system.
12304 KB occupied by the log file.
1183451 KB available on disk.

512 bytes in each allocation unit.
3910976 total allocation units on disk.
2366902 allocation units available on disk.
'------------------------------------------------------

When I read the source cfc with dsfo, it halted at around 1910 mB and after about 30 sec's an error
message appeared as per below. Yet it still created an img file.
'--------------------------------------------------------------------------------
D:\dsfok>dsfo \\.\PHYSICALDRIVE1 0 0 SOURCE.IMG
\\.\PHYSICALDRIVE1 - The request could not be performed because of an I/O device
error.
This error can probably be ignored.
OK, 2004484096 bytes, 190.485s, MD5 = 16000d6f75395b09fc5d65b288c133ab
'--------------------------------------------------------------------------------

This program patches the FAT32/NTFS boot loader to never ever
use CHS based indexing again. CHS based access is broken when
the disk geometry for heads and sectors is different from the
one stored in the BPB.

Signature not found. Not an NTFS/FAT32 or already patched.
'--------------------------------------------------------------
The Source1.img (in zip) is the read from 0 to 51200 of the source cfc.

The Target.img (in zip) is the same from the 4gB Target cfc.
I really have no idea where to go to from here.

Good.
Source.img and target.img are identical (which is good).
The error in dsfo is - if not "normal" - "common enough" and it is connected to a timing problem that can happen when transferring data, as the message says:

This error can probably be ignored.

Now to the KillCHS program.
Our good friend Dencorso with the complicity of Icecube meant well, i.e. to make a tool to help less experienced users apply the patch to the bootsector, BUT - unfortunately - failed when it came to documenting it's usage, just like the original Author :http://blog.clemens....ndows_3170.html

This program patches the FAT32/NTFS boot loader to never ever
use CHS based indexing again. CHS based access is broken when
the disk geometry for heads and sectors is different from the
one stored in the BPB.

So the four intended bytes were patched successfully and you can now issue:

dsfi target.img 32256 512 bstestmod.bin

OK, written 512 bytes at offset 32256

To get back to the book comparison, if the first page of Chapter 1 (in your integral photocopy) has a single word (or just a few words) that needs to be corrected a suitable procedure would be to make a further copy of of just that page, make the correction on this copy and then replace the single page within the book.

The issue here may be that you know that you want to copy/replace a single pagesector and that pagesector is indexed as LBA 63, whilst dsfo/dsfi know nothing about pagessectors, as they only can count wordsbytes.

Luckily enough we know that each pagesector of this book contains EXACTLY 512 wordsbytes, so we can use 63*512=32256 as offset and 512 as extents so that dsfo/dsfi are happy, dsfo can find the pagesector, and extract it, killchs is happy to find the expected target (a bootsector and not a MBR) and patches it happily, dsfi can put the modified pagesector back where it should be, and hopefully everything ends well .