[Bug 266224] Could some sort of file transfer program be put in /rescue?

From: <bugzilla-noreply_at_freebsd.org>
Date: Sun, 04 Sep 2022 19:52:25 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266224

            Bug ID: 266224
           Summary: Could some sort of file transfer program be put in
                    /rescue?
           Product: Base System
           Version: 12.2-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: bin
          Assignee: bugs@FreeBSD.org
          Reporter: freebsd@gushi.org

Hey there,

I run a network of DNS servers, out there in cold unforgiving data centers in
places in the world where remote hands are hard to come by and the only
connectivity you get sometimes is a serial console.  Often you'll get clueful
techs who will reboot a machine for you but not much more.

Numerous times, I've been bitten by freebsd-update segfaulting and leaving me
with an unusable system that won't survive a reboot (either because of a
failure to replace ld.so or because of a full /var or / or other partition).

At that point you're logged in to a system over ssh, you cannot ssh in a second
time, and you need to recover the system quickly.

The only real fix is to copy binaries (or a base.txz) from another machine
using the statically linked binaries in /rescue.  And other than nc (which
works, but has no progress indicator and no real checks), there's no easy way
to get files onto and off a system.

I get it, scp and ssh have heavy crypto overhead, as does fetch at this point,
but a fetch-lite that only spoke HTTP and FTP would be super useful, as would a
copy of old school ftp.  Or, you know, maybe just a statically linked scp/ssh
*is* the right answer here.  (Busybox is a cool idea but it has the GPL issue).

There's no patch for this, it's more an enhancement request.

-- 
You are receiving this mail because:
You are the assignee for the bug.