unsupported relocation type 37 in non-PTL relocation

B

BB_

Hi,
I tried a pkg rollback and as a result I had the following error message:
"ld-elf.so.1: /lib/libc.so.7: Unsupported relocation type 37 in non-PTL relocation

Enter full pathname of shell or return for /bin/sh"

I tried to press "Enter" and several options and I have the same result.
Could you help me to restore my system?

Thanks,
 
Got the same error after trying to downgrade 12.2 to 12.1 with help of freebsd-update ...
Is there any chance to recovery broken system?
 
Selin said:
trying to downgrade 12.2 to 12.1
Click to expand...
Why? 12.1 is EOL and not supported anymore.

forums.freebsd.org

Topics about unsupported FreeBSD versions

The FreeBSD Forums cater primarily to end-users and systems administrators. As such, the Forums focus almost exclusively on FreeBSD versions that are officially supported according to the official FreeBSD website. Since resources are scarce, the FreeBSD Forums strongly suggest that anyone asking...
forums.freebsd.org forums.freebsd.org
www.freebsd.org

Unsupported FreeBSD Releases

FreeBSD is an operating system used to power modern servers, desktops, and embedded platforms.
www.freebsd.org www.freebsd.org
 
eternal_noob said:
Why? 12.1 is EOL and not supported anymore.
Click to expand...
Unfortunately, after updating to 12.2 I hit big performance degradation of the virtual machines being run on that system (bhyve).
I didn't find any reason of such degradation except the FreeBSD version updated.

BTW I returned my system to alive by booting from the LiveCD 12.2 and replacing /lib/* and /libexec/* with files from that CD + copied kernel from /boot/kernel.old.
At least - that gave me the ability to boot the system properly.
After that I did freebsd-update fetch -F and then freebsd-fetch install. Now everything works somehow.
On weekend I'm going to do full backup and reinstall 12.1 from scratch to complete "rolling back" to 12.1.
 
Selin said:
On weekend I'm going to do full backup and reinstall 12.1 from scratch to complete "rolling back" to 12.1.
Click to expand...
I recommend you find the bug and install 12.2 or even 13.0 if you do a full backup anyway.

13.0 has a lot of performance improvements and it might fix your problem.
 
Thanks for the suggestion. But I prefer RELEASE versions, so, probably, will stay with 12.1 until 13 becomes RELEASE.
Maybe will try 12.3 when (if?) it becomes available.
 
Sorry, but... Again - I think it worth waiting for at least the first update for the new Release.
Moreover - I know 12.1 performance for my case. But I don't know 13.0 performance for it.
So anyway I'll need to test it first and only then try to upgrade to 13.0.
 
It seems that your update went wrong... The performance degradation you experienced might most likely be caused by some library mismatch, i.e. trying to use the libraries from the previous release on the new, updated system. Usually, on reboot, the system performs ldconfig(8) (in /etc/rc.d/) to update the system's library paths & the libs therein. Please check freebsd-update IDS. EDIT Likewise, do not hesitate too also pkg upgrade, since old ports(7) may expect & insist to use previous library versions...
 
Mjölnir said:
The performance degradation you experienced might most likely be caused by some library mismatch, i.e. trying to use the libraries from the previous release on the new, updated system.
Click to expand...
That's – not very likely. Not exactly impossible (like when e.g. the meaning of some flags changed or whatever), but still highly unlikely. The common outcome is something either works exactly as before, or not at all.

Furthermore, it's an interesting position to avoid a version because it's not yet supported for the next couple(!) of days and at the same time prefer a version that will never be supported again (which includes no fixes, not even for security reasons, no official packages, among other things).
 
I tried freebsd-update IDS, but it reveals only config files.
I'm using ports and following this approach after upgrading FreeBSD: Rebuilding all ports with portmaster, with minor update - do portsnap fetch update and then fix ports versions in the list of installed ports if needed before the last step.
 
EDIT 2: NEVER NEVER AGAIN copy single entities from /boot/kernel.old/ to /boot/kernel/ like you did with the kernel... (!!!). This let's me strongly guess that you did the update procedure like you thought it could be done, instead of following the Handbook and/or the manual page or /usr/src/UPDATING etc. You might have overlooked some important step... Please thoroughly, critically & honestly check yourself.
 
DO NOT USE PORTMASTER!!! IT IS NOT SOUND!!! There is absolutely no good reason to not use packages unless you have to change some ports' configuration knobs. If you still want to build ports yourself, use poudriere or synth to build in a clean environment. I could tell you the mathematical reasons why self-called portmaster(1) is crap, but that doesn't fit here.
 
Read the respective threads incl. the well known "Recursive Make Considered Harmful". portmaster(8) treats the set of ports of your existing live system at the time of the build as the preset to calculate the ports' dependencies -- but the set of ports on your system is a moving target. That's not sound. In contrast, ports-mgmt/poudriere and ports-mgmt/synth build each port in a fresh, clean jail/chroot. Stil not ideal, but much better than to build in the host system.
 
Portmaster has nothing, absolutely NOTHING, to do with recursive make. The ports tree itself uses recursive make, because for orchestrating builds of OTHER software, each with their own build system, using make, this is simply the only choice there is. Portmaster doesn't use that infrastructure and instead calculates dependencies itself and builds the ports individually.

I agree it's not the best solution, but that's for a different reason: On the live systems, the software built *might* pick up any dependency found on that system by accident and e.g. link against a library it was never supposed to do.

Anyways, as bhyve only concerns base, portmaster is not only unlikely to be the problem with "worse performance", it's practically impossible.
 
Mjölnir said:
So you tell 1+1=1 and in the next sentence correct to 1+1=2...
Click to expand...
Nope. But I guess you really didn't fully understand the difference (and this mixing in of recursive make and its potential problems is really wild). What *can* happen with Portmaster is that a software built might link a library it isn't supposed to, creating an actual dependency nobody knows about, IF the software itself has "automagic" dependencies, which sometimes happens by accident. This kind of error is rare, but it can happen, and it's the main reason why building in a clean environment is better. That doesn't mean Portmaster would be completely unusable. The problem here has most certainly nothing to do with Portmaster, so why even bring on that subject?
 
I'm not mixing up nothing. You wrote yourself (not literally, but you know that the following is correct) that the ports tree unfortunately does not allow for a sound, clean & correct handling of the dependency-graph (that would require a gigantic Makefile that nobody would ever be able to write & maintain; no programmable/automatic solution exists, because the ports tree's dependency graph is not free of cycles (some ports can't be installed together)). That's the root cause of all problems that regularly portmaster runs into. Building in a fresh, clean environment is the 2nd best we can do to address that problem. Anyone except a few <censored> know that.
 
Mjölnir said:
You wrote yourself (not literally, but you know that the following is correct) that the ports tree unfortunately does not allow for a sound, clean & correct handling of the dependency-graph
Click to expand...
No, I didn't, and sure it does. Sorry, but you still don't get the difference between that and some build of some software picking up some library it shouldn't.
 
How can it pick up some dependency that it shouldn't when the dependency graph is correct & is handled correctly? Electronic vodoo? Open sourced sorcery? Magic make(1) mystery?
 
I'm afraid we run too far from the initial topic.
Maybe it is reasonable to back to the initial question?
Just what to know - what is the best approach to revert the FreeBSD version back?
Let's go with minor reverts only - e.g. 12.2 -> 12.1.
What I did (from the very beginning):
Initially, I had FreeBSD 12.1 with the latest updates (including ports, etc.).
1. freebsd-update -r 12.2-RELEASE upgrade
2. freebsd-update install
3. reboot
4. freebsd-update install
5. portmaster -Faf
6. pkg delete -afy
7. rm -rf /usr/local/lib/compat/pkg
8. portsnap fetch update
9. cd /usr/ports/{PORTS I NEED} && make install clean
10. freebsd-update install
11. reboot
12. freebsd-update fetch
13. freebsd-update install
14. reboot
15. zpool upgrade zroot
16. gpart bootcode -p /boot/boot1.efifat -i 1 nvd0 && gpart bootcode -p /boot/boot1.efifat -i 1 nvd1 (I have zraid1 and UEFI boot)

Here I tried to run my bhyve VMs and notice performance degradation...
Looked for the proper way to rollback the upgrade - no luck (
Tested rollback on a virtual machine: installed 12.1, updated it to 12.2 the same way, and then rollback using freebsd-update -r 12.1-RELEASE upgrade - it went well. But on physical machine something went wrong and after reboot I saw the error:
Code: 
"ld-elf.so.1: /lib/libc.so.7: Unsupported relocation type 37 in non-PTL relocation
Enter full pathname of shell or return for /bin/sh"
And that was it.
So I tried to boot from the Live-CD 12.2, mounted my zpool, replaced kernel/* with kernel.old/*, replaced /lib/* and /libexec/* with files from that CD and tried to boot once again - it worked.
To complete re-rolling back to 12.2 I run freebsd-update fetch -f and then install again.
After that, I run freebsd-update IDS to check the system integrity and it shows only config files, so I ended up with that.

If anyone knows or has an idea what I missed with that rollback - please, tell me.
Or any other solution for the error I got after the downgrade.

Thanks
 
You must log in or register to reply here.
Back
Top