New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

/usr/local/lib/libpkg.so.3: Undefined symbol "openat" after upgrade to 1.9.4_1 (FreeBSD 10.1) #1526

Closed
gglebik opened this Issue Jan 5, 2017 · 12 comments

Comments

Projects
None yet
9 participants
@gglebik

gglebik commented Jan 5, 2017

pkg has failed to run after update to 1.9.4_1 on FreeBSD 10.1
Any suggestion for fix except rollback or update to 10.3?

# pkg -v
1.9.4
# pkg update pkg
Usage: pkg update [-fq] [-r reponame]

For more information, see 'pkg help update'.
# pkg install  pkg
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
	pkg: 1.9.4 -> 1.9.4_1

Number of packages to be upgraded: 1

2 MiB to be downloaded.

Proceed with this action? [y/N]: y
Fetching pkg-1.9.4_1.txz: 100%    2 MiB   2.6MB/s    00:01
Checking integrity... done (0 conflicting)
[1/1] Upgrading pkg from 1.9.4 to 1.9.4_1...
[1/1] Extracting pkg-1.9.4_1: 100%
/usr/local/lib/libpkg.so.3: Undefined symbol "openat"

# pkg list
/usr/local/lib/libpkg.so.3: Undefined symbol "openat"

# uname -a
FreeBSD hostname 10.1-RELEASE-p41 FreeBSD 10.1-RELEASE-p41 #0: Fri Oct 21 23:03:01 UTC 2016     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
@bapt

This comment has been minimized.

Show comment
Hide comment
@bapt

bapt Jan 5, 2017

Member

The is no way you can fix using official packages. 10.1 support has been dropped on January 1rst therefor the builders have been switched to 10.3 to build packages hence that breakage.

If you want to fix you will have to build your own packages for 10.1

Member

bapt commented Jan 5, 2017

The is no way you can fix using official packages. 10.1 support has been dropped on January 1rst therefor the builders have been switched to 10.3 to build packages hence that breakage.

If you want to fix you will have to build your own packages for 10.1

@gglebik gglebik closed this Jan 6, 2017

@aduitsis

This comment has been minimized.

Show comment
Hide comment
@aduitsis

aduitsis Jan 8, 2017

I would respectfully submit that this is a problem perhaps bigger than imagined. The fact that you can pull packages from a repo that are not compatible with your base system and get not even so much as a warning, is bad.

Of course, not a problem with pkg per se, but since it has appeared here, just a thought: At present, there must be thousands of FreeBSD systems running 10.1 or 10.2, on which their owners will try to run something as innocuous as a pkg upgrade, only to find that even their basic pkg is no longer functioning. Bad surprise and gives the wrong impression about FreeBSD package management.

I understand that, when the base and kernel and everything else are packages, it will all just magically go away. But it's a shame actually, as pkg already understands major upgrades (e.g. abi 9 to 10) and proceeds to reinstall the same version of a package.

Thanks for your attention and a happy new year.

aduitsis commented Jan 8, 2017

I would respectfully submit that this is a problem perhaps bigger than imagined. The fact that you can pull packages from a repo that are not compatible with your base system and get not even so much as a warning, is bad.

Of course, not a problem with pkg per se, but since it has appeared here, just a thought: At present, there must be thousands of FreeBSD systems running 10.1 or 10.2, on which their owners will try to run something as innocuous as a pkg upgrade, only to find that even their basic pkg is no longer functioning. Bad surprise and gives the wrong impression about FreeBSD package management.

I understand that, when the base and kernel and everything else are packages, it will all just magically go away. But it's a shame actually, as pkg already understands major upgrades (e.g. abi 9 to 10) and proceeds to reinstall the same version of a package.

Thanks for your attention and a happy new year.

@bapt

This comment has been minimized.

Show comment
Hide comment
@bapt

bapt Jan 8, 2017

Member

I'm not disagreeing with your I just don't have a nice idea on how to make it understand such things as minor releases right now. yes it would be nice to make pkg grow with that knowledge. actually the thing is that most of the time it is fine until some new functions are added. (well actually I have an idea but no easy)

Member

bapt commented Jan 8, 2017

I'm not disagreeing with your I just don't have a nice idea on how to make it understand such things as minor releases right now. yes it would be nice to make pkg grow with that knowledge. actually the thing is that most of the time it is fine until some new functions are added. (well actually I have an idea but no easy)

@genisd

This comment has been minimized.

Show comment
Hide comment
@genisd

genisd Jan 9, 2017

I second @aduitsis, having different package repo's for 10.1 / 10.2 would be very nice (which should freeze perhaps at the moment 10.1/10.2 are EoL)
We're also running into this problem, and 10.3 sadly has some big regressions which we're trying to figure out ;/

genisd commented Jan 9, 2017

I second @aduitsis, having different package repo's for 10.1 / 10.2 would be very nice (which should freeze perhaps at the moment 10.1/10.2 are EoL)
We're also running into this problem, and 10.3 sadly has some big regressions which we're trying to figure out ;/

@genisd

This comment has been minimized.

Show comment
Hide comment
@genisd

genisd Jan 9, 2017

As a workaround one can do the following ugly things. It's a hack though :(

  • Take an old version of pkg from /var/cache/pkg
  • Extract into /
  • pkg lock pkg which will freeze pkg package. The internal database version is incorrect, but pkg will operate and should [edit: not] mess with itself.

genisd commented Jan 9, 2017

As a workaround one can do the following ugly things. It's a hack though :(

  • Take an old version of pkg from /var/cache/pkg
  • Extract into /
  • pkg lock pkg which will freeze pkg package. The internal database version is incorrect, but pkg will operate and should [edit: not] mess with itself.
@mat813

This comment has been minimized.

Show comment
Hide comment
@mat813

mat813 Jan 9, 2017

Member

You don't need to pkg lock pkg, because you cannot upgrade anything until you update to 10.3.

Member

mat813 commented Jan 9, 2017

You don't need to pkg lock pkg, because you cannot upgrade anything until you update to 10.3.

@mat813

This comment has been minimized.

Show comment
Hide comment
@mat813

mat813 Jan 10, 2017

Member

A more correct fix would be for pkg to note on the repository metadata which OSVERSION it was using to build stuff, note what version pkg is running on, and complain, loudly, when the repository is after the local.

Member

mat813 commented Jan 10, 2017

A more correct fix would be for pkg to note on the repository metadata which OSVERSION it was using to build stuff, note what version pkg is running on, and complain, loudly, when the repository is after the local.

@glaszig

This comment has been minimized.

Show comment
Hide comment
@glaszig

glaszig Feb 18, 2017

reinstalling pkgng from the proper package repo fixes this:

# freebsd-version
10.2-RELEASE-p10
# cat /usr/local/etc/pkg/repos/FreeBSD.conf
FreeBSD: {
  url: "pkg+http://pkg.FreeBSD.org/${ABI}/release_2",
  enabled: yes
}

http://glasz.org/sheeplog/2017/02/freebsd-usrlocalliblibpkgso3-undefined-symbol-utimensat.html

glaszig commented Feb 18, 2017

reinstalling pkgng from the proper package repo fixes this:

# freebsd-version
10.2-RELEASE-p10
# cat /usr/local/etc/pkg/repos/FreeBSD.conf
FreeBSD: {
  url: "pkg+http://pkg.FreeBSD.org/${ABI}/release_2",
  enabled: yes
}

http://glasz.org/sheeplog/2017/02/freebsd-usrlocalliblibpkgso3-undefined-symbol-utimensat.html

@xdevelnet

This comment has been minimized.

Show comment
Hide comment
@xdevelnet

xdevelnet Feb 28, 2017

  1. When you can't install packages because pkg is too old is WEIRD. BTW, what could possibly important changed between pkg: 1.9.3 -> 1.10.0 ?
  2. New pkg is not working. How about some compatibility checking BEFORE it actually happens?

Damn, is it really happening with me?

Of course I know that my system is "too old" and "I should update", but for a lot of reasons I can't do that during next few months. What should I do now? glaszig's advice is not working for me.

// Going back to the old days, with ports and compilations 😡

xdevelnet commented Feb 28, 2017

  1. When you can't install packages because pkg is too old is WEIRD. BTW, what could possibly important changed between pkg: 1.9.3 -> 1.10.0 ?
  2. New pkg is not working. How about some compatibility checking BEFORE it actually happens?

Damn, is it really happening with me?

Of course I know that my system is "too old" and "I should update", but for a lot of reasons I can't do that during next few months. What should I do now? glaszig's advice is not working for me.

// Going back to the old days, with ports and compilations 😡

@infracaninophile

This comment has been minimized.

Show comment
Hide comment
@infracaninophile

infracaninophile Feb 28, 2017

Member
Member

infracaninophile commented Feb 28, 2017

@bapt

This comment has been minimized.

Show comment
Hide comment
@bapt

bapt Feb 28, 2017

Member

If you are using a not supported version of freebsd the best is that you build your own set of packages via poudriere

Member

bapt commented Feb 28, 2017

If you are using a not supported version of freebsd the best is that you build your own set of packages via poudriere

@GwynethLlewelyn

This comment has been minimized.

Show comment
Hide comment
@GwynethLlewelyn

GwynethLlewelyn Mar 23, 2017

It seems that the Web is full of references to this very same error, occurring over and over again, and like some of you have mentioned, upgrading blindingly a remotely running server with an uptime of over two years is often not feasible or not so easy as it sounds... while upgrading packages is always a less riskier option, either by using pkg or really compiling them from the ports tree.

In the case of one FreeBSD server I've been co-managing, and where we always opt for compiling everything, falling back to installing pre-compiled packages if things do not compile, at some point, a very complex dependency list was found for git (why on Earth it needs to install graphic fonts and/or X11 is really totally beyond me...), and while digging through the many python dependencies (which I mention here because so many people have reported elsewhere that this particular issue pops up somewhere when fixing python dependencies), it started with pkg 1.9.X (I can't remember exactly what it was), decided that it wasn't happy with the current pkg version and upgraded it to 1.10.0, but one dependency branch didn't like it and tried instead to install a very slightly different version (1.10.0_2 instead of 1.10.0...), and of course stumbled somewhere half-way when copying files and figuring out that they already existed... failing with the error that the new package was writing files over the old one... and resulting in a 'broken' libpkg.so.4.

After reading about this issue here, I just did the following...

  1. cd /usr/ports/ports-mgmt/pkg
  2. make clean deinstall reinstall -D ALLOW_UNSUPPORTED_SYSTEM

Amazingly, this really removed all 'bad' libraries (namely libpkg.so.4), downloaded 1.10.0_2, compiled it flawlessly, and I got it working again... and could finish compiling the remaining dependencies for git as well.

Note that, fortunately, during this nightmare, pkg-static never stopped working; kudos to those who created pkg-static thinking that it was a good idea not to rely on possibly broken dynamic libraries and have an alternative...

GwynethLlewelyn commented Mar 23, 2017

It seems that the Web is full of references to this very same error, occurring over and over again, and like some of you have mentioned, upgrading blindingly a remotely running server with an uptime of over two years is often not feasible or not so easy as it sounds... while upgrading packages is always a less riskier option, either by using pkg or really compiling them from the ports tree.

In the case of one FreeBSD server I've been co-managing, and where we always opt for compiling everything, falling back to installing pre-compiled packages if things do not compile, at some point, a very complex dependency list was found for git (why on Earth it needs to install graphic fonts and/or X11 is really totally beyond me...), and while digging through the many python dependencies (which I mention here because so many people have reported elsewhere that this particular issue pops up somewhere when fixing python dependencies), it started with pkg 1.9.X (I can't remember exactly what it was), decided that it wasn't happy with the current pkg version and upgraded it to 1.10.0, but one dependency branch didn't like it and tried instead to install a very slightly different version (1.10.0_2 instead of 1.10.0...), and of course stumbled somewhere half-way when copying files and figuring out that they already existed... failing with the error that the new package was writing files over the old one... and resulting in a 'broken' libpkg.so.4.

After reading about this issue here, I just did the following...

  1. cd /usr/ports/ports-mgmt/pkg
  2. make clean deinstall reinstall -D ALLOW_UNSUPPORTED_SYSTEM

Amazingly, this really removed all 'bad' libraries (namely libpkg.so.4), downloaded 1.10.0_2, compiled it flawlessly, and I got it working again... and could finish compiling the remaining dependencies for git as well.

Note that, fortunately, during this nightmare, pkg-static never stopped working; kudos to those who created pkg-static thinking that it was a good idea not to rely on possibly broken dynamic libraries and have an alternative...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment