Solved pkg fails with mystery error after upgrade from 13.3 to 14.1

Nyantastic · Oct 21, 2024

VladiBG said:
Are you running out of memory?

I doubt that the problem was caused by a lack of computer memory.

VladiBG said:
this is i386

Yes, it's i386. I posted that information in the first post in this thread.

VladiBG said:
why don't you use amd64?

Because this computer has been running FreeBSD since 2008.

VladiBG said:
did you try to force upgrade of all pkg with pkg upgrade -f

I doubt that will make any difference.

Unixnut · Oct 25, 2024

I am not sure if this is related but I just upgraded a jail from 13.1 to 14.1, and sshd is failing for me with ld-elf.so.1: Shared object "libcrypto.so.30" not found, required by "sshd"

Unlike Nyantastic though pkg still works fine, so far I've only found sshd to be affected (of the things I've tried), the only way to get the system to work again is to rollback. My system is also amd64 and there is plenty of RAM on the system.

Also I tried pkg upgrade -f and it didn't help things for me.

Emrion · Oct 25, 2024

Around all these problems, there is a certainty about pkg upgrade -f...

It's not a matter of "It didn't help" or "I doubt that will make any difference". For a major version upgrade, it's mandatory.

See: https://docs.freebsd.org/en/books/handbook/cutting-edge/#freebsdupdate-portsrebuild

And it must be done before the third and last freebsd-update install which removes the old libraries.

Respecting this, I have never had any issues with missing libraries.

Phishfry · Oct 25, 2024

Also note that Chapter 26 says:

pkg-static upgrade -f

Emrion · Oct 25, 2024

Phishfry said:
Also note that Chapter 26 says:

pkg-static upgrade -f

I know, but pkg works unless you already deleted the old libraries.

Cath O'Deray · Oct 25, 2024

Emrion said:
third and last freebsd-update install which removes the old libraries.

Fourth – and only if prompted – according to the 14.1-RELEASE installation document:

Cath O'Deray · Oct 25, 2024

Nyantastic said:
error "pkg: Package database is busy while closing!",

It's a message with an exclamation mark, however it's not presented as an error. I mean, it's nothing to worry about. You may ignore the message.

pkg: Package database is busy while closing!

Just did a fresh install of FreeBSD 13.2 amd64. Oddly, I regularly get the message "pkg: Package database is busy while closing!" after installing stuff. Any idea what I could have done wrong?

forums.freebsd.org

Emrion · Oct 25, 2024

Cath O'Deray said:
Fourth – and only if prompted – according to the 14.1-RELEASE installation document:

Four if you update before, we don't speak of the same thing.

The upgrade process itself is three installs maximum: one for the kernel (reboot). One for the world (then, upgrade packages/ports if it's a major upgrade) and finally, remove the old libraries if it's a major upgrade.

The update before (security patches) is not mandatory.

Nyantastic · Oct 25, 2024

Unixnut said:
I am not sure if this is related but I just upgraded a jail from 13.1 to 14.1, and sshd is failing for me with ld-elf.so.1: Shared object "libcrypto.so.30" not found, required by "sshd"

Unlike Nyantastic though pkg still works fine, so far I've only found sshd to be affected (of the things I've tried), the only way to get the system to work again is to rollback. My system is also amd64 and there is plenty of RAM on the system.

Also I tried pkg upgrade -f and it didn't help things for me.

I don't think that is related.

Nyantastic · Oct 25, 2024

Emrion said:
I know, but pkg works unless you already deleted the old libraries.

The problem with pkg has nothing to do with the libraries being deleted.

Nyantastic · Oct 25, 2024

Cath O'Deray said:
It's a message with an exclamation mark, however it's not presented as an error. I mean, it's nothing to worry about. You may ignore the message.

pkg: Package database is busy while closing!

Just did a fresh install of FreeBSD 13.2 amd64. Oddly, I regularly get the message "pkg: Package database is busy while closing!" after installing stuff. Any idea what I could have done wrong?

forums.freebsd.org

pkg is failing and it produces this error. What I'm worried about is that pkg is failing, and the clue I have to solve the problem is that it produces this error. So I'm not actually worried about the text or the exclamation mark, but about pkg failing, and I'm offering this message on the forum in case it helps people to help me solve the problem with pkg.

Cath O'Deray · Oct 26, 2024

Nyantastic said:
… I'm now running pkg upgrade, and it seems to be installing all the things for freebsd-14 libraries. …

Nyantastic said:
… Everything is working, … The only problem is with pkg. …

Nyantastic said:
… to help me solve the problem with pkg.

Is pkg not working?

Or is the problem that you can't find an explanation for the past breakage?

Nyantastic · Oct 26, 2024

Cath O'Deray said:
Is pkg not working?

pkg is not working.

Phishfry · Oct 26, 2024

Can't you force upgrade pkg ?

pkg-static upgrade -f pkg

Phishfry · Oct 26, 2024

Nyantastic said:
I did try that one several times, as well as trying with pkg-static

Sorry I see you already tried this.

Cath O'Deray · Oct 26, 2024

Nyantastic said:
pkg is not working.

I see pkg-static working on page 1, so this (at least) should work:

pkg-static add https://pkg.freebsd.org/FreeBSD:14:i386/base_release_1/FreeBSD-pkg-bootstrap-14.1.pkg

Whilst that might get you no further than you got in part of your <https://forums.freebsd.org/posts/676253>, the essence is:

you should be able to add a package for any part of 14.1-RELEASE.

Phishfry · Oct 26, 2024

It sounds like a package database problem and I have never been able to overcome those.

Delete db and reinstall everything from a text file generated via pkg-origins just like recommended.

pkg prime-origins > pkg.txt

Cath O'Deray · Oct 26, 2024

Phishfry said:
It sounds like a package database problem

FWIW: at this stage, I suspect not.

Nyantastic · Oct 27, 2024

Phishfry said:
It sounds like a package database problem and I have never been able to overcome those.

Delete db and reinstall everything from a text file generated via pkg-origins just like recommended.

pkg prime-origins > pkg.txt

As I mentioned above, I've tried replacing the database with a backup from before the problems started, so I don't see how it could be a problem with a corrupted database file. I will try your suggestion just to make sure.

Nyantastic · Oct 27, 2024

Cath O'Deray said:
I see pkg-static working on page 1, so this (at least) should work:

pkg-static add https://pkg.freebsd.org/FreeBSD:14:i386/base_release_1/FreeBSD-pkg-bootstrap-14.1.pkg

Whilst that might get you no further than you got in part of your <https://forums.freebsd.org/posts/676253>, the essence is:

you should be able to add a package for any part of 14.1-RELEASE.

This is the exact output from the terminal screen. I've snipped the very long list of packages.

Code:

# pkg-static add https://pkg.freebsd.org/FreeBSD:14:i386/base_release_1/FreeBSD-pkg-bootstrap-14.1.pkg
Fetching FreeBSD-pkg-bootstrap-14.1.pkg: 100%   14 KiB  14.6kB/s    00:01   
Installing FreeBSD-pkg-bootstrap-14.1...
Extracting FreeBSD-pkg-bootstrap-14.1: 100%
# pkg upgrade

<... snip ...>

Number of packages to be removed: 8
Number of packages to be installed: 2
Number of packages to be upgraded: 47
Number of packages to be reinstalled: 779

The operation will free 385 MiB.
246 MiB to be downloaded.

Proceed with this action? [y/N]: y

<... snip ...>

Checking integrity...Child process pid=24501 terminated abnormally: Abort trap
#

Cath O'Deray · Oct 27, 2024

Nyantastic said:
I've snipped the very long list of packages.

Did you keep a record, for yourself?

Run /usr/sbin/pkg bootstrap -f –? probably superfluous (the comparable run that was shown in your opening post was successful), but it should do no harm.

Then (re)run:

pkg upgrade -f

Postscript: re-edited the first command above, to include the path to pkg. (Weird. I did add the path, maybe it was lost through switching from one page to another in XenForo.)

Nyantastic · Oct 28, 2024

Cath O'Deray said:
Did you keep a record, for yourself?

Run /usr/sbin/pkg bootstrap -f –? probably superfluous (the comparable run that was shown in your opening post was successful), but it should do no harm.

Then (re)run:

pkg upgrade -f

Postscript: re-edited the first command above, to include the path to pkg. (Weird. I did add the path, maybe it was lost through switching from one page to another in XenForo.)

Code:

# /usr/sbin/pkg bootstrap -f
The package management tool is not yet installed on your system.
Do you want to fetch and install it now? [y/N]: y
Bootstrapping pkg from pkg+http://pkg.FreeBSD.org/FreeBSD:14:i386/latest, please wait...
Installing pkg-1.21.3...
package pkg is already installed, forced install
Extracting pkg-1.21.3: 100%
# pkg upgrade
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
Updating database digests format: 100%
Checking for upgrades (826 candidates): 100%
Processing candidates (826 candidates): 100%
Checking integrity...Child process pid=48133 terminated abnormally: Abort trap
#

?

Cath O'Deray · Oct 28, 2024

Thanks,

Nyantastic said:
# pkg upgrade

It lacked the suggested force, but for now, let's not focus on that.

I have seen the child process terminated abnormally in maybe a dozen cases in recent months/years … I never took much notice, at the time, because:

I was focused on other things
essentially, it was never a true show-stopper.

If I recall correctly, in all cases I simply repeated the command until processes terminated normally.

In some cases I might have restarted the OS before the repeat. Maybe sometimes repeated with the OS in safe mode? Honestly, I can't remember the details.

Nyantastic if you would like to further debug your case …

pkg(8) does describe the --debug option, but does not mention that multiple levels are possible.

pkg -d upgrade --no-repo-update --dry-run --force
pkg -dd upgrade --no-repo-update --dry-run --force
pkg -ddd upgrade --no-repo-update --dry-run --force
pkg -dddd upgrade --no-repo-update --dry-run --force

These commands can be run as a normal user, without superuser privileges, so you need not worry about damage.

At some point – hopefully before the DBG(4) level – you might see, at or near the point of abnormal termination (i.e. the tail end), a technical reason for the abnormality.

I'm not aware of a DBG(5) level.

Side note: pkg is amazing. bapt@ and his fellow developers are unsung heroes of FreeBSD.

Nyantastic · Oct 29, 2024

Cath O'Deray said:
Thanks,

It lacked the suggested force, but for now, let's not focus on that.

I tried with -f but the output was the same. I didn't bother including that in the responses.

Cath O'Deray said:
I have seen the child process terminated abnormally in maybe a dozen cases in recent months/years … I never took much notice, at the time, because:

I was focused on other things

essentially, it was never a true show-stopper.

If I recall correctly, in all cases I simply repeated the command until processes terminated normally.

In some cases I might have restarted the OS before the repeat. Maybe sometimes repeated with the OS in safe mode? Honestly, I can't remember the details.

Nyantastic if you would like to further debug your case …

pkg(8) does describe the --debug option, but does not mention that multiple levels are possible.

pkg -d upgrade --no-repo-update --dry-run --force

pkg -dd upgrade --no-repo-update --dry-run --force

pkg -ddd upgrade --no-repo-update --dry-run --force

pkg -dddd upgrade --no-repo-update --dry-run --force

Yes I have found that option and also the undocumented levels from examining the source code. I have tried running it with that but nothing very useful seemed to appear. Running it again with the -dddd results in a file of nearly 1 million lines. Here is the final line:

Code:

DBG(3)[90052]> Pkg: add new file '/usr/local/share/texmf-dist/fonts/vf/catharsis/cormorantgaramond/CormorantGaramond-Regular-osf-t1.vf'

The previous time too it failed during adding one of the files from TeX, but since there are so many of those it may not be surprising.

Cath O'Deray said:
These commands can be run as a normal user, without superuser privileges, so you need not worry about damage.

At some point – hopefully before the DBG(4) level – you might see, at or near the point of abnormal termination (i.e. the tail end), a technical reason for the abnormality.

I'm not aware of a DBG(5) level.

It will go on and on incrementing the variable "cfg.debug_level" the more -d flags you add, but there are no debugging statements which print only when the debug level is over four in libpkg. You can check this using grep "pkg_debug(5" *.c.

Cath O'Deray said:
Side note: pkg is amazing. bapt@ and his fellow developers are unsung heroes of FreeBSD.

Yes, I didn't mind ports but pkg saves a lot of time. I used to have Haskell language installed and that took about 24 hours to compile using ports. The previous thing like pkg never worked well for me but the new version has been mostly trouble-free until now. The only caveat is never to use the -y option, since it may remove things you are using.

Nyantastic · Tuesday at 4:10 AM

After upgrading the OS to FreeBSD 14.2, I tried pkg upgrade again. This time around, it self-upgraded its major version from 1 to 2. (I don't know if that is related to the OS version upgrade since I didn't run pkg after the above events until now.) Then it proceeded to do the upgrade, which had some hiccups, but was able to overcome them by itself without intervention beyond typing "y" once more than usual.

So this is now resolved, although I don't know exactly what happened or what changed.