Discussion:
Problems with upgrade.
(too old to reply)
Bernt Hansson
2018-05-30 10:48:09 UTC
Permalink
Hello list.

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?

Out of ideas.
Esa Karkkainen via freebsd-questions
2018-05-30 16:21:18 UTC
Permalink
Post by Bernt Hansson
Hello list.
Hello,
Post by Bernt Hansson
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
--
"In the beginning the Universe was created. This has made a lot of
people very angry and been widely regarded as a bad move."
-- Douglas Adams 1952 - 2001
Bernt Hansson
2018-06-08 15:23:07 UTC
Permalink
Post by Esa Karkkainen via freebsd-questions
Post by Bernt Hansson
Hello list.
Hello,
Post by Bernt Hansson
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.
ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/10.4-RELEASE/
# 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
# 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
# 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.
# freebsd-update IDS
# freebsd-update fetch
# freebsd-update install
Hope that helps.
Kind regards,
Esa
Thank you Esa for that very comprehensive answer.

Bernt.

Loading...