> I get a dd: broken pipe error whenever I try to do an 'unpack.s
> tomsrtbt.raw'.
> Itried this 1.7.185, 250 and 259 with the image in the downloaded tar.gz
> file.
Definitely get 1.7.268. I have been making changes to this area.
Also, it is appreciated that you are actually using newer versions and
helping me to figure out what I am breaking.
> I fixed it changing the line
> 'dd bs=1k if=$1 skip=$O1|dd count=$Z2|gzip -d -q>$RD'
> into
> 'dd bs=1k if=$1 skip=$O1of=X
> dd if=X count=$Z2|gzip -d -q>$RD
> rm X'
That one is strange, I don't see that one. In 1.7.26x, I changed it to
use a LD_LIBRARY_PATH that will pick up the libc from the build tree, let
me know if that makes a difference. I also changed 'dd' to have an option
--retry-partial that makes it retry partial blocks until full or EOF, that
may make a difference, if you are still getting this one in 1.7.268, I'd
like you to try changing that dd option on either dd.
> I admit, I never tried unpacking /dev/fd0u1722 ...
>
> An other strange behavior I rcognised in buildit.s when using the
> loopback-device as workspace:
>
> 'cd $ID
> . ST
> umount $MP
> sed -e "/mount -o ro /c mount -o ro $FD /fl"<2/etc/rc.M>new'
>
> spat out an error when trying to execute 'unmount $MP'. Fix:
> inserted 'sync' right before the unmount-line.
>
> This two bus happened on two independant machines.
This one I saw too and did the same thing with the sync. I broke it. It
is happening because I went to an older version of umount to free up a
little space, and the older umount must not be properly doing a sync. I
did the same thing you did, I stuck a sync in right before that umount.
It is fixed (by adding the sync, and also only umounting one thing at a
time) in 1.7.268.
I will probably keep the old umount. I still feel that as long as it is
possible to make it work, and possible to umount your filesystems, it
isn't worth the extra Kilobytes to have a fancy new umount command. But I
might do more research along the development of the source and pick a
version intermediate.
-Tom
