pkg failure after upgrading pkg

J

Jur van der Burg

I'm trying to upgrade pkg:
Code: 
[root@thegate] ~> pkg upgrade pkg
Updating FreeBSD repository catalogue...
Fetching meta.txz: 100%    944 B   0.9kB/s    00:01
Fetching packagesite.txz: 100%    6 MiB   2.0MB/s    00:03
Processing entries: 100%
FreeBSD repository update completed. 25910 packages processed.
Updating database digests format: 100%
New version of pkg detected; it needs to be installed first.
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 127.4kB/s    00:20
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%
You may need to manually remove /usr/local/etc/pkg.conf if it is no longer needed.
/lib/libc.so.7: version FBSD_1.4 required by /usr/local/lib/libpkg.so.3 not found
[root@thegate] ~> pkg upgrade pkg
/lib/libc.so.7: version FBSD_1.4 required by /usr/local/lib/libpkg.so.3 not found

What happened? This is a standard 10.0 release install.

[root@thegate] ~> uname -a
FreeBSD xxxxxxxxxxxx x10.0-RELEASE-p7 FreeBSD 10.0-RELEASE-p7 #1 r269455: Sun Aug  3 13:04:26 CEST 2014     root@xxxxxxxxxxxx:/usr/obj/usr/src/sys/THEGATE  amd64
Jur.
 
Last edited by a moderator:
gkontos said:
It is an unsupported version. You need to upgrade to 10.3-RELEASE
Click to expand...

Updating to FreeBSD 10.3-RELEASE is not an immediate option for one of our production systems. That same system needed a package update and is now in limbo due to pkg1.9.4_1 being installed. Is there a work-around to downgrade pkg so we can get past this immediate issue while scheduling an upgrade path?

I don't recall, and perhaps I've just been lucky, ever being in a situation where software installed on a system rendered itself unusable.

Thanks in advance,
scotto
 
Scott O'Connell said:
Is there a work-around to downgrade pkg so we can get past this immediate issue while scheduling an upgrade path?
Click to expand...
No, because you're going to run into other problems too.

FreeBSD 10.0 has been end-of-life since February 2015 and should have been upgraded a long time ago.
 
Scott O'Connell said:
I don't recall, and perhaps I've just been lucky, ever being in a situation where software installed on a system rendered itself unusable.
Click to expand...
The system is not unusable. You simply can not upgrade your software if you don't first upgrade the system. Does this sound strange to you?
 
Well, old or not, breaking a system this way is not nice. It is an example of bad engineering.

I attempted to upgrade via the documented procedures, but at the final stage after rebooting I did freebsd-update install which hoses the system disk to the point that the filesystem is not recognized anymore. If I do a rollback of the latest zfs snapshot I can recover, but I'm still at the same point.

I will do a new install of V11.0.
 
Jur van der Burg said:
Well, old or not, breaking a system this way is not nice. It is an example of bad engineering.
Click to expand...

Not upgrading software, which includes the OS is an example of bad engineering. You rely on EOL for a production system and you blame the system for that.

Jur van der Burg said:
I attempted to upgrade via the documented procedures, but at the final stage after rebooting I did freebsd-update install which hoses the system disk to the point that the filesystem is not recognized anymore. If I do a rollback of the latest zfs snapshot I can recover, but I'm still at the same point.

I will do a new install of V11.0.
Click to expand...

You should first go to the latest patchset of the system that you are running and then upgrade. If you don't like that you can always use the source way.
 
Jur van der Burg said:
Well, old or not, breaking a system this way is not nice. It is an example of bad engineering.
Click to expand...
Erm, sorry, but you've had 2 years to upgrade. And the impending deprecation of all .0 versions has been known since the earliest versions of FreeBSD. All .0 versions expire around 3 months after the release of the .1 versions.
 
Sorry to have opened such a can of worms.

It had been my experience that FreeBSD never FORCED me into anything. It was our fault for not keeping up on when 10.2 would force a user into upgrading to keep all aspects of the system from working.

While I appreciate these things being my responsibility, we had attempted an earlier upgrade from 10.2 to 10.3 and a few aspects of our system became unusable due to the openssh changes made in 10.3. We are a small shop, and didn't have the expertise to fix the legacy problem, so we had to continue running 10.2 until ready to implement the replacement for the broken code.

We are also dependent on some commercial code that is not supported on 11, and we can't control that one, but have been working with the developer for certification.

So while it was clearly wrong, we weren't "just" lazy or purposely irresponsible, we just got ourselves into a pickle.

It's not a perfect world for everyone.

What surprised me here was that I've never been treated this way by the FreeBSD community. There has always been a best effort to help with a work-around/solution to a problem with education on what the correct way. Nothing like that here, just judgement on why it is our fault.

So, notwithstanding what the experts have pointed out, I was able to get past my issue with a temporary workaround to get the package I needed installed. I simply replaced /usr/lib/libpkg.so* with an older version long enough to fix the problem.
 
getopt said:
This sentence is an example for blaming others for one's own failure/laziness.
If you use FreeBSD privately on your own, you are free to do all the stupidest things,
but if you were an IT-professional I'd fire you right now.
Click to expand...

It seems to me that there are a LOT of people/companies who are clingers to fbsd 10. I've had no problems with 11, but I wonder if it more than just 'laziness' that is causing folks to forgo the upgrade.
 
Whereas I do agree the tone of some reproaches may have been too rough, that statement on "bad engineering" sounded baseless as criticism. For both sides being able the same argument: legacy ain't always a question of choice. If there was something wrong or was found could it have been done better, "bad engineering" would be leaving the matter as-is just for the sake of legacy - which is desirable but never at any cost.

Scott O'Connell said:
I was able to get past my issue with a temporary workaround to get the package I needed installed. I simply replaced /usr/lib/libpkg.so* with an older version long enough to fix the problem.
Click to expand...

It's nice you found a solution, but I was ready to suggest building from ports then install with no need for upgrading pkg. Of course, this would keep the versioning problem untouched, but could work as a temporary fix. Building from ports was not an option? If I got it right, there was a package relying on upgraded pkg and that was all that there is about the issue. Should this package demand newer versioning itself or through dependencies, things would boil down to the starting point or almost there. Since ports, like pkg, keep being updated as well from time to time. But it could be worth a try if there were no choices available (like downgrading libs as you've done).
 
Scott O'Connell said:
Sorry to have opened such a can of worms.

It had been my experience that FreeBSD never FORCED me into anything. It was our fault for not keeping up on when 10.2 would force a user into upgrading to keep all aspects of the system from working.

While I appreciate these things being my responsibility, we had attempted an earlier upgrade from 10.2 to 10.3 and a few aspects of our system became unusable due to the openssh changes made in 10.3. We are a small shop, and didn't have the expertise to fix the legacy problem, so we had to continue running 10.2 until ready to implement the replacement for the broken code.

We are also dependent on some commercial code that is not supported on 11, and we can't control that one, but have been working with the developer for certification.

So while it was clearly wrong, we weren't "just" lazy or purposely irresponsible, we just got ourselves into a pickle.

It's not a perfect world for everyone.

What surprised me here was that I've never been treated this way by the FreeBSD community. There has always been a best effort to help with a work-around/solution to a problem with education on what the correct way. Nothing like that here, just judgement on why it is our fault.

So, notwithstanding what the experts have pointed out, I was able to get past my issue with a temporary workaround to get the package I needed installed. I simply replaced /usr/lib/libpkg.so* with an older version long enough to fix the problem.
Click to expand...

You are really confusing us here. Are you running FreeBSD 10.0-RELEASE as indicated or 10.2-RELEASE? There is a big difference.
 
gkontos said:
You are really confusing us here. Are you running FreeBSD 10.0-RELEASE as indicated or 10.2-RELEASE? There is a big difference.
Click to expand...

This system is on FreeBSD vhqerp02 10.2-RELEASE-p18.

EDIT: I just read back in the thread and saw the OP mentioned 10.0. The problem on my 10.2 is the same.
 
Similar happened to be today:

Code: 
Proceed with this action? [y/N]: y
Fetching pkg-1.10.1.txz: 100%    3 MiB   2.6MB/s    00:01
Checking integrity... done (0 conflicting)
[1/1] Upgrading pkg from 1.9.4_1 to 1.10.1...
[1/1] Extracting pkg-1.10.1: 100%
/lib/libc.so.7: version FBSD_1.4 required by /usr/local/lib/libpkg.so.4 not found

And that's it. It bricked pkg for me. Yes, I'm still on 10.0, and the reasons are beyond the scope of this discussion. I have been preferring FreeBSD as my default server OS of choice for many years but this kind of developer attitude is really discouraging.

A package manager should not be able to break itself.
 
blackhaz said:
A package manager should not be able to break itself.
Click to expand...
It's not the package manager that's broken. You're trying to run something that's specifically built for 10.3 on 10.0. All .0 versions expire 3 months after the release of .1. And both 10.1 and 10.2 have expired by now (it was already known when they would expire when they were released, so you could have seen this coming and could have planned accordingly).
 
SirDice, I would agree with you, but pkg suggested to upgrade itself. No warnings. Something that is specifically built for 10.3 should not be able to suggest to install on 10.0. So the pkg upgrade philosophy is broken somewhere. A user must be able to stay with whatever OS version he chooses, for reasons known only to himself, without fear that the current software will force to break itself. Maybe my galactic simulation code is written for 10.0? Each person has its own black holes. Pkg suggested the upgrade itself and broke itself.

There's already a related PR:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216805

The fix is planned already. I'll add a comment there.

Does anybody know how to downgrade pkg back?
 
blackhaz said:
Something that is specifically built for 10.3 should not be able to suggest to install on 10.0.
Click to expand...
It can't tell the difference. The ${ABI} string is the same so you're referencing the same repository.
 
blackhaz said:
I have been preferring FreeBSD as my default server OS of choice for many years but this kind of developer attitude is really discouraging.
Click to expand...

Same here. I've been using FreeBSD since the Linux < 2.2.19 root exploit came out in April 2001. It's increasingly difficult to properly maintain my FreeBSD systems, and an answer of "shut up and upgrade", is not acceptable if you want FreeBSD to be taken seriously.

Time to give Linux a chance again. Farewell FreeBSD, it is time to part ways.
 
You must log in or register to reply here.
Back
Top