I tried dd'ing without specifying the block size, and had the same
problem. I'm also copying both from and to Sandisk SDs, so unless there
is variation in size with the same manufacturer, that does not explain
the problem. I would just resize the partitions on the original SD
card, but the big one is JFS, which apparently can't be shrunk (only grown)!
Don
On 1/18/2012 4:44 PM, Mark Featherston wrote:
Don,
SD cards vary slightly from card to card. For example, I have 3
different brands of SD cards here that each say 2GB. However
according to fdisk:
ATP Industrial Grade - 2058 MB, 2058354688 bytes
A-Data Speedy SD - 2013 MB, 2013265920 bytes
Sandisk SD - 1977 MB, 1977614336 bytes
From our experience with SD cards there can be up to a 10% difference
in actual usable disk size even though they are labeled for a specific
size. All of our software images take this into account and leave a
portion of the disk unallocated.
Best Regards,
________________________________________________________________
Mark Featherston, Technologic Systems | voice: (480) 837-5200
16525 East Laser Drive | fax: (480) 837-5300
Fountain Hills, AZ 85268 | web:www.embeddedARM.com
On 01/18/2012 03:24 PM, dtucker wrote:
I recently went to make a backup of my 2GB SD card used as the Debian
file
system for my TS-7260.
dd if=/dev/sdb of=backupfile.dd bs=2048
The resulting file was 1977614336 bytes. I then attempted to write
this image
to a new 2GB SD card.
dd if=backupfile.dd of=/dev/sdb bs=2048
I received the following error:
dd: writing to `/dev/sdb': No space left on device
3842049+0 records in
3842048+0 records out
1967128576 bytes (2.0 GB) copied, 1950.22 s, 1.0 MB/s
Why wouldn't the image fit on a new SD card if it could fit on the
one I copied
it from?
Don
smime.p7s
Description: S/MIME Cryptographic Signature
|