It's not really sda, both cards read in as /dev/sdf; just used sda/sdb as examples.

Also, when I said "When inserted into my diagnostic device, the card makes it boot a different OS," I'm just trying to describe what the card does. Instead of the normal OS of my device, the intended purpose of the card is to make it boot to a different one.


Cool, thanks for the lead on qemu-- will try.

OK, I haven't been able to get even the original card to boot through qemu, after going through quite a few configuration options (DOS, old processors, as barebones as possible). So maybe it's not exactly a standalone OS, i.e. it's loaded on top of the device's OS?

Btw, the output of
is

disk.bin: x86 boot sector, code offset 0x3c, OEM-ID "DXA2.00 ", sectors/cluster 4, root entries 512, sectors 62592 (volumes <=32 MB) , Media descriptor 0xf8, sectors/FAT 62, heads 64, serial number 0x1535164, label: " X CARD", FAT (16 bit) DOS executable (COM), boot code

Another weird thing: When I compare the images of
and
by using
The output says "disk.bin and disk_bs1.bin differ." What?!? Either way, the bs=1 version does not work either.

I also tried clonezilla, but it gave some error about not recognizing the partition type....

Wow! this is a popular thread.

When you copy with dd you get a copy of the block, complete with a matching directory structure. When you copy on to a non identical disk, the cyls/heads/sectors emulation does not reliably transfer to a different size disk. That's what I was trying to say in post #2

From your latest post, the '64 heads' buried in the file-k output indicates to me that this thing has an older than current method of disk access.

Rsync or cp -a both copy files, not directory structures. You would then have to make the new disk bootable. But as you don't seem to know what the disk contains yet, I will leave that to the other contributors.

Interesting. I always thought cyls/heads/sectors was just antiquated nomenclature and that really it's just a string of bytes, especially in a flash card. But if there are differences in how it's all emulated across architectures, then the file intermediate written onto my hard disk platter could definitely be the problem. That might explain the difference between the bs=512 and bs=1 image, no? Btw, I dont' know if it makes a difference, but there are no directories in the card, just a couple files.

I did try to dd the first 512 bytes, and then cp the files over, to no avail... part of the reason I originally wondered if this thing has some nonstandard MBR size. I'm definitely going to need the card's original MBR.

Is this from a set top box? Are you trying to copy something you're not supposed to copy?

No, the card and device are no longer sold, I'm just trying to back up my card.

Not easy to get card to boot on qemu. Was supposed to test dd file in qemu.

Is this linux or some other OS? What is this pcmcia card anyway? We have to assume that it is an old 5V card and your adapter ought to be able to provide this voltage.

Is this a cisco card?

I tested both the dd image and the card directly. Used qemu in winXP because I couldn't install in Linux (long story). But if 1) it's hard to boot PCMCIA directly and 2) the image on my HDD is off (because of what business_kid mentions), then I'll have trouble with both ways.

The dd was done in Ubuntu 11.04. The original card is a bootable type II 16 bit PCMCIA card for a diagnostic machine. The target card I'm trying to clone to is a Compact Flash card with a type II PCMCIA adapter, and I read that they're straight adapters without compatibility issues. If I can't get it to work, the next try will be a 32mb (correct size) PCMCIA flash card.

I just tried a 32mb (correct size) PCMCIA card (correct format). No go. I really can't understand it.

I didn't try directly from PCMCIA to PCMCIA slot, but after thinking about it more it doesn't seem like it would make a difference. Or would it?

Anything else I can try? Any flags I should throw to dd? When I did a hexdump on the MBR, I noticed it's just a few characters identifying the card, followed by mostly zeros in the bootstrap code area, and then ending with the boot signature. Something tricky is going on but I don't know what.....

Buy or borrow another card reader/writer and try this process directly from card to card.

Unfortunately it didn't work going from one PCMCIA drive to another.

Are there hidden partitions or something I'm not taking into consideration??

One thing I noticed is, the original card is Hitachi and reports 32,047,104 bytes, while the target card is Samsung and is 32,112,640 bytes. There don't appear to be Hitachi PCMCIA cards for sale, but there are CF cards. Maybe it's worth trying one?

Also meant to ask: is it worth trying to spoof the original serial number? What other things could make a device picky about a disk???

This backup is approaching the cost of the original card itself, but now I'm just feeling stubborn about the whole thing.

Will try any and all suggestions, thanks.

and just to note, I also tried

to avoid system caching of the data stream....

Did that complete without any errors? Did it say the exact same number of bytes out as in?

I'm really out of ideas. Dd is 100% bit copy. But also bit copy of the available/visible space. If the original card does have a non-visible to normal file systems section, but one that is visible just to that product, then you can't copy. However I believe you said you were able to do a copy before, right?

And with the target size being slightly larger than the source, this should've worked. The problems I was citing would be the reverse where the target is a few bytes slightly smaller than the source.

Yep!

nope, never have before.

This is what I was wondering about. There's no way to scan for something like this, eh?

I would say in the case I'm thinking about, "no" because it would be an electrical thing or identity which lies outside of the available file system. For instance, jumper zero ohm resisters which indicate some settings. Not saying you should look for them either, just a possible guess. I'd say the only real way to know would be to teardown the working card and examine it's circuitry. Thereby making it a non-working card. So ... no don't do that.