Hi all,

I have an old bootable flash card (PCMCIA, FAT16, no partition) that I want to clone. When inserted into my diagnostic device, the card makes it boot a different OS.

The original disk (sda) is 32mb, my target disk (sdb) is 128mb. First I tried
It copies everything fine but doesn't work, and then I realized the partition table must be screwed up because of the size difference. So I tried to first make a 32mb FAT16 partition on sdb and then copy just the bootloader in the first block (attempting to preserve the partition table I wrote to it) and then everything else later:
The first command seems to destroy the partition table, and the files don't stay intact. I've also tried to format the card with the device and using the above code, to no avail.

Are my commands correct? If so, can an MBR and/or VBR (I'm not entirely clear on the distinction) be a different size than 512? How can I find out how big the MBR is?

I'm guessing I should get a 32mb card to see if this doesn't alleviate some headaches, but I'd like to figure out how to work with a bigger drive. Any advice would be awesome!

dd only works for disks of the exact same geometries, and sizes. By that I mean you can only read down into the directories of a disk copied with dd if the geometries are identical.

Yours clearly are not. If it has a distro there, even the booting arrangements could be different between usb and PCMCIA

I'm not quite sure what you mean by geometries, but in this case I'm cloning a pcmcia card to another pcmcia card, so it's really just a size issue, and I've gotten around that in the past. The partition is identical in size to the original disk.

One difference is that the original card had no partition, whereas I'm trying to force a partition, so I guess the bootloader may address a primary partition differently than a formatted drive. But I'm not even there yet because replacing the first 446 bytes destroys the partition table. So I'm wondering if there's some nonstandard way of writing an MBR that only my device would be programmed to recognized and, if so, how I'd go about reading that...

First check about the presence of partition with 'fdisk -l /dev/sda'.

If it does not then probably the device thinks it as large floppy disk ( or may be even something else ).

Also may be the device wants a fixed sized disk???

You should copy the disk as whole as you did.

If there are partitions you can make new one in the new disk with fdisk and format it with mkfs.fat to make fat16 filesystem and mount and copy over the files.

These specific devices may have specific requirements.

The original device has no partition, so yes, the device thinks it's just a disk. If it wants a fixed size, one thing I didn't try is my first dd command (whole disk) and then shrinking the partition. But maybe it reads the entire disk size.

But looking at this again, here's what's really bugging me: I make a FAT16 partition with Linux and am able to destroy it by overwriting the first 446 sectors. Just doesn't make sense.

There is no need to shrink the partition at all. As for the start there is no partition at all as you said. MBR is used to store partitions. In your case there would be only a boot sector (first sector of 512 bytes). And after that fat16 filesystem.

That's what I thought originally and so I tried a straight dd, but since this didn't work in my device I thought maybe my device requires a 32mb disk.

What other types of requirements could be in place in the device that I'm not taking into consideration?

There's a big problem here and something I've posted about in the past a number of times.

Source = some disk of some size

Fact: Not all disks of "that size" are equal. They generally are > "that size" by some amount.

What happens is dd takes every block when you do if=/dev/sd<letter>, which really is what you have to do.

OK: A solution you've used was to "of" it to a clearly larger disk. This should work actually and I do not understand why not. Have you check the number of blocks in/blocks out and run fdisk on both the original and the copy?

A result is that you've created a disk which matches the original size. In the operating case, it will not employ use of the extra space, but maybe you don't care. Fine. Right?

Next time you dd, the "if" is that /dev/<letter> and THAT detects the full sized disk, caring nothing about the fact that 50% is unused. Therefore you now are required to use larger sized disks always, at least with that binary file you've made.

Variations:

1. Use the same sized disk as your target:
   1. Target disk is slightly larger than the source, so it works
   2. Target disk is slightly smaller than the source, so it doesn't work
   3. You decide to limit because 8 Gig is 8 Gig and that's what the spec of the disk is, so that's all you want. Dd doesn't know, nor care what blocks it's supposed to not use, it follows logic that it agrees with, and copies never work because critical disk information is near the very start or end where dd happens to also decide to cut out the blocks
   4. You now employ a start or end limit and size limit and things improve. You encounter a disk smaller than even the size limit or the end block number exceeds blocks available on that particular disk, the dd command fails.
2. A better system disk duplication procedure is recommended

Personally I make sure when I do that that I fully understand the partition requirements, and can duplicate them, then I can install the bootloader. After that installation of the kernel is "placement" of one file and installation of the RFS is an archive copy of an existing RFS that I previously saved. On the subject of previously saving an RFS, I have a procedure to copy that entirely into a larger file, then I use a resize file system utility to minimize the file system to the minimum space actually required.

Just my humble opinion. I use scripts to perform the whole setup of a disk and part of one is the reverse where it copies the kernel file and RFS off of a known good system disk so I can create an archive of a system. Portions of some of these scripts are in my blog under my BASH discussion.

This is exactly how I envisioned it, yes, and it's worked for me before.

OK, to reiterate: What other requirements could my device have that I'm not meeting? One thing I noticed when I benchmarked the card speeds is that my new card reads a bit faster than the old one, even though I made sure to get a type II 16-bit card. Could that be bothering my device? Or, could the hardware in the card be engineered with protection somehow?

Yeah, newer disks can have some manipulations in the original partition table to provide their private-ware. But ... dd of the whole disk should obliterate that. If possible, I'd recommend the dd using "if=" original, and "of=" target disks, don't use the file as an intermediary.

I mean manipulations at the hardware level, for instance shorting two pinouts and having the device's reader expect as much. Anything like that ever implemented?

I don't have two PC card drives, so not possible... but I'm not seeing how the file intermediate should matter. EDIT: not saying it doesn't matter but that I'd just need an explanation to understand it if so....

I don't think so at the hardware level. Sure everything is technically constructed differently, but they need to match the definition of a disk first and foremost. How about buying a USB connecting external multi-card reader/writer. That's what we have.

And ... PC Card? Meaning what? SD Card, Compact Flash? PC card is like a very old definition of those cards that used to plug into laptops to add a modem or Ethernet connection if the main unit did not have one.

Actually you did say PCMCIA card. So ... wow! Either case, you can't add a second reader/writer and have that work?

Really my recommendation is to develop a system disk management process. But if this is a one-of and very non-occasional, whatever. I never found it to be sustainable, but then I usually end up having to make numerous copies once we start shipping.

Yeah, it's a type II 16-bit PCMCIA card. I bought an external reader but am hesitant to buy another one (if you saw my edit, I'm just truly curious about why it my help). I could try hooking it up to an old laptop with a PCMCIA slot, I suppose. But I'm wary because I just burned $8 to find out that a PCMCIA-to-PCI card was hardcoded for modems only. Still, maybe worth a shot if somehow the file intermediary is the problem. But it really seems at this point that the disks are identical, save for extra space at the end...

All I can really say is my experiences are with SD, microSD, compact flash, and USB drives. I've actually never used a "drive" which was PCMCIA but instead worked with modems, or other communications style of devices.

And I don't know nor recall whether or not it was good/bad/indifferent if I did the 4G to 8G copy via: (1)Copy 4G to file (2) Copy file to 8G and if that worked. Really I spent enough time discovering the drawbacks at just about every turn. I.e. the FIRST time you get a bootable system which shows a splash screen, they WANT it to show it to everyone, you're cringing, but you also know that if you don't give up, might as well start looking for new work. So you expeditiously copy and get away with it once or twice, then you need to make 8 more copies because the hardware guy is building the first 10 units and he just wants to "test them out with that same version you had ..." You realize you need a production grade copy method about that point. Or in my case it was applicable given that these were envisioned to go to a nationwide mobile force of thousands. OK never did, but we made a couple of hundred and it was GREAT that some technician got to sit at a terminal rather than me, making new disks.

Lets start all over.

This media if we can assume it really is bootable should be able to be copied by dd to a file. I doubt it would be sda but I don't get your wrong OS issue.

Once you have it to a file you should be able to test it on qemu. I suspect this is a pretty old distro. It was very difficult for any pcmcia to boot on linux. It only had minimal support for a few years. I'd copy this distro off to an image and see if you can boot it on qemu.