On Sun, Oct 29, 2006 at 04:58:24PM -0600, Eric Haszlakiewicz wrote:
> 
> More seriously: if this is available through pkgsrc, why does it need
> to be in the base system?  Aren't we trying to go the other direction,
> and just have sysinst install some packages?

Yesterday, we moved the disks from one of the NetBSD Foundation servers
into a new replacement machine.  As it turned out, the new machine had
network controllers that were not supported by the kernel on the disks
from the old machine, but nobody was present where the new machine was
by the time we realized this.

We had a serial port, but no serial communications software; so to get
a new kernel on the machine so we could use the network, I had to split
a uuencoded g-kermit into many pieces and upload it with cu.  It seems
to me we should ship a recovery tool like this as part of the system,
because it was certainly not feasible in such a situation to get some
external software from pkgsrc and install it!

I have a network switch with Linux-based firmware.  This firmware has a
3-stage boot process in which, as it turns out, all _three_ stages
include the option to abort the boot and upload a replacement next-stage
by x, y, or zmodem.  This has been invaluable to me on several occasions
when I have toasted the firmware, and at one point the second-stage boot
loader, trying to boot NetBSD.  What it boils down to is that if you
have access to the console, you can fix the machine.  We could use minirz
for this, too, but G-Kermit is hardly any larger and the kermit protocol,
in my experience, is a lot more robust over difficult serial connections,
e.g. through ssh, then through conserver, with a DDB escape character
you also have to not send, with no working flow control... you get the
idea.  And G-Kermit can transmit, too, which minirz can't do, so you can
get files off the hosed machine, to examine or patch them.

Thor