[Soekris] dd and the dangers.
tvo at EnterZone.Net
Mon Jan 20 20:00:26 UTC 2003
On Mon, 20 Jan 2003, Chuck Yerkes wrote:
> Quoting John Fraizer (tvo at EnterZone.Net):
> > 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.
> yes, and that assumption is the source of my reaction to messages
> telling people to pull down thus and such image and dd it to their
Actually, when I started working with my Soekris box, I had great
difficulty finding an image that I could just dd to the CF and as such, I
had to find a way to create my own images. I suppose that with more and
more of the boxes in the wild now, the availability of images is also
> tar doesn't generally maintain hardlinks and *can* blow sym links.
> restore doesn't do this. rsync can be told not to do this.
I hadn't really though about this too much. It does make perfect sense
> When I'm using a crunchgen'd image, those hardlinks are sort
> of critical. I have ONE large image that stands in for 30 binaries.
> Getting 30 large binaries means it won't fit on the 8MB CF.
Very good point. Is this something like busybox or the like?
> As I said, dd is fine when I'm in a production mode and have a
> case of, say, 50 CF's that I bought at once and have to get into
> 50 machines. I *know* they will work right.
I just found it #1 be easy and #2 be pretty quick.
> More, when my client has a soekris with one of these, I can send
> them an image and have them use dd or a rawwrite type windows
> app to upgrade themselves.
This was my motivation. I wanted to make sure that I could do easy field
> As a counter for your ten step technique, I'd offer that dd isn't
> gainging you anything. Once the new cf is labeled, mount it and
> rsync -al /source/dir/ /new/cf/
> And you can skip several of your steps. (creating a vn device,
> tarring and untarring, etc).
Actually, the reason I use the vn device is several fold.
(1) It allows me to mount the filesystem and tinker with it without
burning up write cycles on the CF.
(2) It allows me to run fsck, etc on the image without having to do so on
the CF itself.
I do like the idea of using the rsync though to preserve the links.
So, here we go with the newly improved simple way to get a bootable image
on your CF unit:
(1) Blast the partion information on the CF
dd if=/dev/zero of=/dev/rad[n] bs=1k count=20
(2) Create an image file the same size as our CF
dd if=/dev/zero of=/usr/flash-image.bin -bs=512 count=`disklabel -rwn \
ad[n] auto | grep "sectors/unit" | cut -d : -f 2 -s`
(3) Mount our new image file as a vn device so we can disklabel it and put
a filesystem on it.
vnconfig -s labels -c vn0 /usr/flash-image.bin
(4) Put the proper disklabel on it.
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
(5) newfs our vn0 device so we can mount it and rsync our distrib to it.
newfs -b 8192 -f 1024 -U /dev/vn0a
(6) Mount our newly created filesystem.
mount /dev/vn0a /mnt
(7) Rsync our distribution onto the filesystem.
rsync -al /source/dir/ /mnt/
(8) Unmount our newly created/written filesystem.
(9) Write our new image to the CF unit.
dd if=/usr/flash-image.bin of=/dev/rad[n] bs=8k
Wow! We took a step off of the procedure and dropped the tar archive for
rsync so we preserve links properly. What does everyone think of this
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