Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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.
Quote:
Originally Posted by jefro
Once you have it do 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.
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
Code:
file -k disk.bin
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
Code:
dd if=/dev/sdf of=disk.bin
and
Code:
dd if=/dev/sdf of=disk_bs1.bin bs=1
by using
Code:
diff disk.bin disk_bs1.bin
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....
Last edited by grant or not; 04-16-2015 at 10:42 PM.
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.
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.
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.
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.
Quote:
Originally Posted by business_kid
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.
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.
Last edited by grant or not; 04-17-2015 at 10:37 AM.
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.
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.
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.
Last edited by grant or not; 04-23-2015 at 10:08 PM.
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.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.