freebsd stable - Aug 2007 - update from RELEASE to STABLE changed /dev/ad or geom behavior?

Hello all,

To fix a bug in PF I recently updated my home firewall platform (a
shrunk-down install of FreeBSD 6 on a CompactFlash card mounted
read-only as /dev/ad0a) from the RELENG_6_2 to the RELENG_6 branch. All
went very well there and the PF problem is resolved, but now I've run
across a new issue.

Previously, when updating my CompactFlash image "in the field", I
would
boot the system into single-user mode via serial console, setup a small
memory filesystem big enough to hold gzip, dd, and reboot (and their
required libraries, with LD_LIBRARY_FLAGS set appropriately), copy the
new flash image to the mfs, and run (from the MFS) "gzip -dc <flashimage
| dd of=/dev/ad0 bs=8k" and then run "reboot -lnq" to reboot into
the
new image.

This all worked well and good until the update to RELENG_6, and now I
see the following when I try to dd the new image:

# sysctl kern.geom.debugflags=16
kern.geom.debugflags: 0 -> 16

# gzip -dc <flashimage | dd of=/dev/ad0 bs=8k
dd: /dev/ad0: Invalid argument
298+1 records in
298+0 records out
1220608 bytes transferred in 1.330433 secs (917452 bytes/sec)


With the above kern.geom.debugflags sysctl, I thought I would have the
ability to directly write to /dev/ad0 via dd, and this was the case with
RELENG_6_2. Is this no longer the case? Didn't see anything in
/usr/src/UPDATING to indicate any sort of change, and I'm not sure where
in the RELENG_6 code this would exist (GEOM perhaps)?

Anyone have any ideas or suggestions as to why this doesn't work anymore?



Thanks!
-Proto

Michael Proto wrote:
> Hello all,
> 
> To fix a bug in PF I recently updated my home firewall platform (a
> shrunk-down install of FreeBSD 6 on a CompactFlash card mounted
> read-only as /dev/ad0a) from the RELENG_6_2 to the RELENG_6 branch. All
> went very well there and the PF problem is resolved, but now I've run
> across a new issue.
> 
> Previously, when updating my CompactFlash image "in the field", I
would
> boot the system into single-user mode via serial console, setup a small
> memory filesystem big enough to hold gzip, dd, and reboot (and their
> required libraries, with LD_LIBRARY_FLAGS set appropriately), copy the
> new flash image to the mfs, and run (from the MFS) "gzip -dc
<flashimage
> | dd of=/dev/ad0 bs=8k" and then run "reboot -lnq" to reboot
into the
> new image.
> 
> This all worked well and good until the update to RELENG_6, and now I
> see the following when I try to dd the new image:
> 
> # sysctl kern.geom.debugflags=16
> kern.geom.debugflags: 0 -> 16
> 
> # gzip -dc <flashimage | dd of=/dev/ad0 bs=8k
> dd: /dev/ad0: Invalid argument
> 298+1 records in
> 298+0 records out
> 1220608 bytes transferred in 1.330433 secs (917452 bytes/sec)
> 
> 
> With the above kern.geom.debugflags sysctl, I thought I would have the
> ability to directly write to /dev/ad0 via dd, and this was the case with
> RELENG_6_2. Is this no longer the case? Didn't see anything in
> /usr/src/UPDATING to indicate any sort of change, and I'm not sure
where
> in the RELENG_6 code this would exist (GEOM perhaps)?
> 
> Anyone have any ideas or suggestions as to why this doesn't work
anymore?
> 
I found a solution to this problem that I'd like to share with the list.

Here's my problem:

# gzip -dc <flashimage | dd of=/dev/ad0 bs=8k

For some reason, this particular command works fine in 6.2-RELEASE when
the underlying filesystem is being overwritten, but not in 6-STABLE
where it dies shortly after the command is started. To correct it, I
have to completely uncompress the image first and then run it through
dd. I changed the sequence of events in my update script as follows:

# gunzip flashimage.gz ; dd if=flashimage of=/dev/ad0 bs=8k

Bingo! no more "invalid argument" error when writing to /dev/ad0.

I don't know what has changed in between 6.2-RELEASE and 6-STABLE to
cause this, but since this isn't likely "supported" behavior of dd
(writing an image to the root filesystem, mounted read-only, with some
mfs and LD_LIBRARY_PATH hacks) my workaround seems to do the job nicely.
FYI for those in the future who may run across this particular problem.


-Proto