For the first time in a long time today, I died during an update of
current. It was a salutary lesson in being sure your script(s) to do an
upgrade from a build.sh state do not depend on shared libs, or the
targets being replaced. I think I've glibly assumed I was safe, because
I hadn't (until now) tripped over a change in something (libc?) which
affected the running tools.

I think /rescue should be in the default single-user PATH, probably
before other path elements.

I am probably very confused, but I don't understand why /bin/sh
and /sbin/init depend on the shared libs, but didn't die during the
upgrade. Is there something special about their COW state or something
else which prevents this? -After the upgrade completed (via /rescue) I
was hosed at reboot, /sbin/init wasn't having any of it, and I had to
recover via a backup /root instance, and saved tarballs. -So there is a
difference between crapping over the disk during single-user, and then
afterwards. Probably, any fork/exec boundary into /bin/sh was deadly
for me, but for... loops embedded in the running shell we fine, which
is why I was able to continue to shoot myself egregiously in the foot
after I stomped on the libc or other runtime loadables.

I also notice grep isn't in /rescue. It was the only element of my
script which wasn't available there. I know this quickly descends into
a bikeshed, but I wondered if grep wasn't perhaps a /rescue-worthy tool?

I'm re-working my 'safe install single-user' script a bit (a LOT) now
to run from /rescue explicitly.

(looks like I made a dirty libc somehow. I can't see a CVS fix or
anyone else complaining, so I really do think I fired the six-shooter
at my own toes.)

-G