Date: Sun, 04 Sep 2022 19:52:25 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 266224] Could some sort of file transfer program be put in /rescue? Message-ID: <bug-266224-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D266224 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 cluef= ul 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 se= cond 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 w= ay to get files onto and off a system. I get it, scp and ssh have heavy crypto overhead, as does fetch at this poi= nt, but a fetch-lite that only spoke HTTP and FTP would be super useful, as wou= ld a copy of old school ftp. Or, you know, maybe just a statically linked scp/s= sh *is* the right answer here. (Busybox is a cool idea but it has the GPL iss= ue). There's no patch for this, it's more an enhancement request. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-266224-227>