Date: Tue, 6 Sep 2022 22:14:45 +0000 (UTC) From: doug <doug@safeport.com> To: David Christensen <dpchrist@holgerdanske.com> Cc: questions@freebsd.org Subject: Re: FreeBSD 12.2 can not be upgraded Message-ID: <ef805e3-7442-4038-d493-cfa87966c43@safeport.com> In-Reply-To: <edb6cc2a-5ba1-0c7c-8405-b7ec546d5c02@holgerdanske.com> References: <alpine.BSF.2.00.2209041200310.67914@bucksport.safeport.com> <AA1D2084-FB1A-418E-A26A-D468312A6DC5@gushi.org> <alpine.BSF.2.00.2209041352190.67914@bucksport.safeport.com> <D6FA74F6-B8C9-4CD8-B58D-27D1B01025C0@gromit.dlib.vt.edu> <edb6cc2a-5ba1-0c7c-8405-b7ec546d5c02@holgerdanske.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 4 Sep 2022, David Christensen wrote: > On 9/4/22 13:31, Paul Mather wrote: >> I don't understand your comment about /rescue/sh in the first sentence >> in the quoted paragraph above. The binaries in /rescue are statically >> linked, so I don't see how they depend on /libexec. In fact, ldd will >> even complain if you run it against /rescue/sh because it is not a >> dynamically-linked executable. Furthermore, file(1) will include >> "statically linked" in its output when run against /rescue/sh. >> (Disclaimer: I don't have any 12.x systems any more to double-check, >> but it is true for FreeBSD 13.1 and historically has been the case for >> as long as I know. See man rescue(8) for details.) > > Here is what one of my 12.3-R systems has to say about /rescue/sh: > > 2022-09-04 22:08:51 dpchrist@f3 ~ > $ freebsd-version ; uname -a > 12.3-RELEASE-p6 > FreeBSD f3.tracy.holgerdanske.com 12.3-RELEASE-p6 FreeBSD 12.3-RELEASE-p6 > GENERIC amd64 > > 2022-09-04 22:09:02 dpchrist@f3 ~ > $ ldd /rescue/sh > ldd: /rescue/sh: not a dynamic ELF executable > > 2022-09-04 22:09:04 dpchrist@f3 ~ > $ file /rescue/sh > /rescue/sh: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), > statically linked, for FreeBSD 12.3, FreeBSD-style, stripped I'm not a C guy and took the internals course a few decades ago so basically no internals knowledge here. I can only report what I experienced. The update 12.2-->12.3 introduced a copy of ld-elf.so.1 that produced various errors. In this state there was a set of commands that would not run. As this is a workstation I hit this a lot in the 9-11 versions of the system when trying to update xfce, firefox or installing something like libreoffice. With the missing ".so" files in /usr/local I was able to get by the error [sometimes] by replacing the offending module. With ld-elf.so.1 it is protected by being read-only and with the immutable bit set. So I went to single user mode and tried to update it. Basically a no-go until I deleted it. Then nothing worked so I rebooted to single user mode and tried to use /rescue/sh. That version was not [apparently] statically linked. At any rate I got the same class of error. At this point I had a rather expensive paper weight. Fairly easy to solve, boot from an iso or img file, use livefs to save my data, and start a fresh. I understand all my actions after the freebsd-update error were futile and perhaps ill-advised, but what did I have to lose?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ef805e3-7442-4038-d493-cfa87966c43>