Date: Fri, 8 Jun 2018 17:23:07 +0200 From: Bernt Hansson <d7o9idh8jlaj@opayq.com> To: Esa Karkkainen <freebsd.lists@zxas.fi>, freebsd-questions@freebsd.org Subject: Re: Problems with upgrade. Message-ID: <b1d40453-34ea-24bb-188b-2a5c471a78f9@opayq.com> In-Reply-To: <20180530162118.GC11983@pp.htv.fi> References: <78ec6723-1389-c1df-27ec-55f0c5b32775@opayq.com> <20180530162118.GC11983@pp.htv.fi>
next in thread | previous in thread | raw e-mail | index | archive | help
On 05/30/18 18:21, Esa Karkkainen via freebsd-questions [Masked] wrote: > On Wed, May 30, 2018 at 12:48:09PM +0200, Bernt Hansson wrote: >> Hello list. > Hello, > >> Upgrade like this 10.3R -> 11.1R -> rollback -> 10.4 >> >> Now there is issues with some libs like >> >> Shared object "libldns.so.5" not found, required by "host" >> Shared object "libheimipcc.so.11" not found, required by "libkrb5.so.11" >> >> Probably others too. Tried to build from source but...... No. >> >> Should i download 10.4 source and build userland & kernel? > That is one possiblity, but "make buildworld" might not run succesfully, > it depends how badly the operating system has been broken. > > I'm assuming you've used freebsd-update to do the updates. > > Please try > > # freebsd-update IDS > > Below is the relevant part of freebsd-update usage. > IDS -- Compare the system against an index of "known good" > files. > > You can see the freebsd-update commads usage if you run "freebsd-update" > without any arguments. > > That might help you all the incorrect files, because the IDS might be > able to tell you what files are not "known good" in 10.4. > > You can get specific files from the distribution packages like this. > > 1. You can download base.txz for amd64 architecture from: > ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/10.4-RELEASE/ > > 2. This is how you can find the specific path to the incorrect files: > > # xz -dc base.txz|tar tvf - | egrep 'libldns.so.5|libheimipcc.so.11' > lrwxr-xr-x 0 root wheel 0 Sep 29 2017 ./usr/lib/private/libheimipcc.so -> libheimipcc.so.11 > -r--r--r-- 0 root wheel 375976 Sep 29 2017 ./usr/lib/private/libldns.so.5 > lrwxr-xr-x 0 root wheel 0 Sep 29 2017 ./usr/lib/private/libldns.so -> libldns.so.5 > -r--r--r-- 0 root wheel 10032 Sep 29 2017 ./usr/lib/private/libheimipcc.so.11 > > The lines which begin with "l" character are just symbolic links, the > lines that start with "-" character show the actual files that do not > work. You can use "|egrep -v '^l'" at the end of the previous command to > exclude any symbolic links, so the command would be > > xz -dc base.txz|tar tvf - | egrep 'libldns.so.5|libheimipcc.so.11' | egrep -v '^l' > > 3. Copy or download the base.txz file to /tmp directory > > 4. Extract the files needed: > > # cd /tmp/ > # xz -dc /path/to/base.txz|tar xvf - ./usr/lib/private/libldns.so.5 ./usr/lib/private/libheimipcc.so.11 > x ./usr/lib/private/libldns.so.5 > x ./usr/lib/private/libheimipcc.so.11 > > 5. So the two shared libraries are now in /tmp/usr/lib/private > directory, now lets rename the incorrect files and copy these shared > libraries to the correct directory: > > # mv -i /usr/lib/private/libldns.so.5 /usr/lib/private/libldns.so.5.broken && cp -pi /tmp/usr/lib/private/ibldns.so.5 /usr/lib/private/libldns.so.5 > > The "cp" comand will be run only if the "mv" command was successful and > if the target file exist it will ask you "are you sure" > > You can't always overwrite files, because the file might be in use, so > the safest way is to rename the file to a diffrent name and then copy > the file to the same exact location. > > And that will not work on all files, for example "/usr/lib/libc.a" file > unless you use statically linked commands from /rescue directory, but > since you can run basically any command then the libc.a file is ok. > > You can do that by adding "/rescue" as the first diretory in your shells > path environment variable. > > This is how you add "/rescue" temporarily as the first directory of the > path using root users default shell, which is csh. > > # echo $SHELL > /bin/csh > # which mv > /bin/mv > # echo $path > /sbin /bin /usr/sbin /usr/bin /usr/local/sbin /usr/local/bin /root/bin > # set path = ( /rescue $path ) > # echo $path > /rescue /sbin /bin /usr/sbin /usr/bin /usr/local/sbin /usr/local/bin /root/bin > # which mv > /rescue/mv > # > > If that doesn't help, please try this before running "freebsd-update" > again. > > # cd /var/db > # mv freebsd-update freebsd-update.not_in_use > # mkdir freebsd-update > # chown root:wheel freebsd-update > # chmod 0700 freebsd-update > # cp -pi freebsd-update.not_in_use/pub.ssl freebsd-update > > That makes freebsd-update lose all history, so it'll start from a clean > slate. > > The you can run: > > # freebsd-update IDS > > or possibly: > > # freebsd-update fetch > # freebsd-update install > > Hope that helps. > > Kind regards, > > Esa > Thank you Esa for that very comprehensive answer. Bernt.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b1d40453-34ea-24bb-188b-2a5c471a78f9>