[Soekris] dd and the dangers.

John Fraizer tvo at EnterZone.Net
Mon Jan 20 17:17:27 UTC 2003

On Sun, 19 Jan 2003, Chuck Yerkes wrote:

> I keep seeing people throwing around "dd" as a way to build
> or make disks work.
> It's a lovely notion that has some real restrictions.
> dd works well when the disks are PRECISELY THE SAME GEOMETRY.
> Just like with DOS's "rawwrite", dd works well with floppies
> and duplicate disks.

This makes the assumption that the user is simply dd'ing an image to the
CF blindly.

The following procedure will verify that you have the appropriate geometry
for your CF and still allow you the ease of using DD to write the CF.

(1) Tar up an archive of what you want on your CF.

(2) Delete any partition information that may be on the CF we want to

dd if=/dev/zero of=/dev/rad[n] bs=1k count=20

(3) Use disklabel to get the number of sectors on your flash card.

disklabel -rwn ad[n] auto | grep sectors/unit

(4) Create a disk image file the same size as your CF.

dd if=/dev/zero of=/usr/flash-image.bin bs=512 count=[number of sectors on your CF]

(5) Use this disk image file as a vn device so we can disklabel it

vnconfig -s labels -c vn0 /usr/flash-image.bin

(6) We need to partition our flash-image

disklabel -Brw vn0 auto
disklabel -e vn0

Find the line that starts with c: and duplicate it, changing the c: to a:
and the fstype to 4.2BSD

(7) newfs and mount our CF "image" file so we can put our files on it.

newfs -b 8192 -f 1024 -U /dev/vn0a
mount /dev/vn0a /mnt

(8) Untar our filesystem archive onto our "image":

cd /mnt
tar xfvzP [name of your archive]

(9) Unmount the "image" we have created.

cd /
umount /mnt

(10) Finally, we write our newly created image to our CF.

dd if=/usr/flash-image.bin of=/dev/rad[n] bs=8k

This is the method that I use and it has not given me any problems at all.

Writing to a new CF size (and using all available space) is as simple as
these ten steps.  Since we're obtaining our disk geometry as part of the
process, manufacturing changes don't tend to bother us.

This method also limits the number of writes to the CF compared to trying
to install directly to the CF.

I hope this helps someone out there.

> However, unlike harddrives, CF's are most often made for cameras
> and other consumer devices.  If a manufacturer can save $0.01 by
> changing something, they will - it saves plenty in multi-million
> dollar alotments.  Small savings do not warrant a new label (the
> label change my offet the savings).
> That 128MB CF you bought last week may be almost unrelated to the
> one you bought 3 months ago.

We take that into consideration in the steps above.

> While you CAN "dd" onto a larger disk, if you "DD" a 32MB image
> onto a 64MB disk, you'll have a 32MB disk to work with.

We create an image the same size as the CF.  No wasted space.

> dd can be a shortcut, but it's not the Right Answer for longer term
> production.  I've long used a diskless boot to let machines build
> themselves, generally a process that does what the previous paragraph
> describes with the installation of data being done via restore(1).
> Rsync can also do this, while more slow, it has advantages of resetting
> existing file systems to "known state" more quickly.

I beg to differ.  Using the process I outlined above, there is no reason
why you can't develope in a "jailed" environment and then write changes to
your CF-archive.  When you want to commit the changes to the CF media,
simply go through the steps above.

Note: For simple changes, I simply mount the ad[d] device rw with noatime
and replace/add/delets the files I need to modify.

Like I said, I use the procedure I outlined above and it works just fine.

John Fraizer              | High-Security Datacenter Services |
President                 | Dedicated circuits 64k - 155M OC3 |
EnterZone, Inc            | Virtual, Dedicated, Colocation    |
http://www.enterzone.net/ | Network Consulting Services       |

More information about the Soekris-tech mailing list