LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Software
User Name
Password
Linux - Software This 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


Reply
  Search this Thread
Old 04-16-2015, 09:31 AM   #1
grant or not
Member
 
Registered: Nov 2004
Posts: 31

Rep: Reputation: 0
trouble cloning flash boot disk with dd


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
Code:
dd if=/dev/sda of=disk.bin
dd if=disk.bin of=/dev/sdb
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:
Code:
dd if=disk.bin of=/dev/sdb bs=446 count=1
dd if=disk.bin of=/dev/sdb bs=512 skip =1
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!
 
Old 04-16-2015, 11:02 AM   #2
business_kid
LQ Guru
 
Registered: Jan 2006
Location: Ireland
Distribution: Slackware, Slarm64 & Android
Posts: 16,633

Rep: Reputation: 2391Reputation: 2391Reputation: 2391Reputation: 2391Reputation: 2391Reputation: 2391Reputation: 2391Reputation: 2391Reputation: 2391Reputation: 2391Reputation: 2391
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
 
Old 04-16-2015, 11:20 AM   #3
grant or not
Member
 
Registered: Nov 2004
Posts: 31

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by business_kid View Post
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...
 
Old 04-16-2015, 11:39 AM   #4
veerain
Senior Member
 
Registered: Mar 2005
Location: Earth bound to Helios
Distribution: Custom
Posts: 2,524

Rep: Reputation: 319Reputation: 319Reputation: 319Reputation: 319
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.
 
Old 04-16-2015, 11:49 AM   #5
grant or not
Member
 
Registered: Nov 2004
Posts: 31

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by veerain View Post
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.
 
Old 04-16-2015, 12:03 PM   #6
veerain
Senior Member
 
Registered: Mar 2005
Location: Earth bound to Helios
Distribution: Custom
Posts: 2,524

Rep: Reputation: 319Reputation: 319Reputation: 319Reputation: 319
Quote:
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.
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.
 
Old 04-16-2015, 12:11 PM   #7
grant or not
Member
 
Registered: Nov 2004
Posts: 31

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by veerain View Post
There is no need to shrink the partition at all. As for the start there is no partition at all as you said.
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?
 
Old 04-16-2015, 12:14 PM   #8
rtmistler
Moderator
 
Registered: Mar 2011
Location: USA
Distribution: MINT Debian, Angstrom, SUSE, Ubuntu, Debian
Posts: 9,890
Blog Entries: 13

Rep: Reputation: 4934Reputation: 4934Reputation: 4934Reputation: 4934Reputation: 4934Reputation: 4934Reputation: 4934Reputation: 4934Reputation: 4934Reputation: 4934Reputation: 4934
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.
 
Old 04-16-2015, 12:56 PM   #9
grant or not
Member
 
Registered: Nov 2004
Posts: 31

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by rtmistler View Post

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?
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?
 
Old 04-16-2015, 01:00 PM   #10
rtmistler
Moderator
 
Registered: Mar 2011
Location: USA
Distribution: MINT Debian, Angstrom, SUSE, Ubuntu, Debian
Posts: 9,890
Blog Entries: 13

Rep: Reputation: 4934Reputation: 4934Reputation: 4934Reputation: 4934Reputation: 4934Reputation: 4934Reputation: 4934Reputation: 4934Reputation: 4934Reputation: 4934Reputation: 4934
Quote:
Originally Posted by grant or not View Post
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.
 
Old 04-16-2015, 01:09 PM   #11
grant or not
Member
 
Registered: Nov 2004
Posts: 31

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by rtmistler View Post
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....

Last edited by grant or not; 04-16-2015 at 01:16 PM.
 
Old 04-16-2015, 01:17 PM   #12
rtmistler
Moderator
 
Registered: Mar 2011
Location: USA
Distribution: MINT Debian, Angstrom, SUSE, Ubuntu, Debian
Posts: 9,890
Blog Entries: 13

Rep: Reputation: 4934Reputation: 4934Reputation: 4934Reputation: 4934Reputation: 4934Reputation: 4934Reputation: 4934Reputation: 4934Reputation: 4934Reputation: 4934Reputation: 4934
Quote:
Originally Posted by grant or not View Post
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.
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.
 
Old 04-16-2015, 01:22 PM   #13
grant or not
Member
 
Registered: Nov 2004
Posts: 31

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by rtmistler View Post
Actually you did say PCMCIA card. So ... wow! Either case, you can't add a second reader/writer and have that work?
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...
 
Old 04-16-2015, 01:30 PM   #14
rtmistler
Moderator
 
Registered: Mar 2011
Location: USA
Distribution: MINT Debian, Angstrom, SUSE, Ubuntu, Debian
Posts: 9,890
Blog Entries: 13

Rep: Reputation: 4934Reputation: 4934Reputation: 4934Reputation: 4934Reputation: 4934Reputation: 4934Reputation: 4934Reputation: 4934Reputation: 4934Reputation: 4934Reputation: 4934
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.
 
Old 04-16-2015, 04:05 PM   #15
jefro
Moderator
 
Registered: Mar 2008
Posts: 22,047

Rep: Reputation: 3632Reputation: 3632Reputation: 3632Reputation: 3632Reputation: 3632Reputation: 3632Reputation: 3632Reputation: 3632Reputation: 3632Reputation: 3632Reputation: 3632
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.

Last edited by jefro; 04-17-2015 at 03:06 PM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Linux Boot disk won't start - after cloning the drive in Windows 8 clueless1 Linux - Newbie 1 03-19-2014 09:47 AM
Boot time kernel panic after cloning distro to differnt disk linux_marine Linux - Newbie 3 06-19-2007 10:46 AM
Boot time kernel panic after cloning distro to differnt disk linux_marine Mandriva 3 06-16-2007 01:38 PM
Cloning boot disk using DD vanibhat Linux - Hardware 3 12-01-2004 03:35 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Software

All times are GMT -5. The time now is 03:53 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration