# unsupported relocation type 37 in non-PTL relocation



## BB_ (Jan 2, 2021)

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,


----------



## Selin (Mar 18, 2021)

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?


----------



## eternal_noob (Mar 18, 2021)

Selin said:


> trying to downgrade 12.2 to 12.1


Why? 12.1 is EOL and not supported anymore.









						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
				











						Unsupported FreeBSD Releases
					

FreeBSD is an operating system used to power modern servers, desktops, and embedded platforms.




					www.freebsd.org


----------



## Selin (Mar 18, 2021)

eternal_noob said:


> Why? 12.1 is EOL and not supported anymore.


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.


----------



## eternal_noob (Mar 18, 2021)

Selin said:


> On weekend I'm going to do full backup and reinstall 12.1 from scratch to complete "rolling back" to 12.1.


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.


----------



## Selin (Mar 18, 2021)

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.


----------



## eternal_noob (Mar 18, 2021)

Selin said:


> But I prefer RELEASE versions, so, probably, will stay with 12.1 until 13 becomes RELEASE.


13.0 becomes release in 12 days. It's not a long time.








						FreeBSD 13.0 Release Process
					

FreeBSD is an operating system used to power modern servers, desktops, and embedded platforms.




					www.freebsd.org


----------



## Selin (Mar 22, 2021)

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.


----------



## Mjölnir (Mar 22, 2021)

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...


----------



## zirias@ (Mar 22, 2021)

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.


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).


----------



## Selin (Mar 22, 2021)

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.


----------



## Mjölnir (Mar 22, 2021)

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.


----------



## Mjölnir (Mar 22, 2021)

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.


----------



## Selin (Mar 22, 2021)

Mjölnir said:


> DO NOT USE PORTMASTER !!!


Why?
If the portmaster is so bad - why then the Handbook tells about it?


----------



## Mjölnir (Mar 22, 2021)

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.


----------



## zirias@ (Mar 22, 2021)

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 (Mar 22, 2021)

So you tell 1+1=1 and in the next sentence correct to 1+1=2...


----------



## Mjölnir (Mar 22, 2021)

Selin said:


> Why?  If the portmaster is so bad - why then the Handbook tells about it?


Please file in a bug report.  The vast majority of developers don't like portmaster either, because of the reasons told.  PM is evil crap.  Period.


----------



## zirias@ (Mar 22, 2021)

Mjölnir said:


> So you tell 1+1=1 and in the next sentence correct to 1+1=2...


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?


----------



## Mjölnir (Mar 22, 2021)

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.


----------



## zirias@ (Mar 22, 2021)

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


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.


----------



## Mjölnir (Mar 22, 2021)

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?


----------



## Selin (Mar 22, 2021)

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:

```
"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


----------



## Mjölnir (Mar 23, 2021)

If you have ZFS why the hell don't you use bectl(8)?


----------



## Selin (Mar 23, 2021)

Thanks for this info - will read about it and try to use next time.


----------



## zirias@ (Mar 23, 2021)

Mjölnir said:


> 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?


It is off-topic here, but as you still misunderstand a few things, I wrote a lengthy explanation in your original thread:








						Do not use ports-mgmt/portmaster and other tools who build in the main system
					

Is there a way to have synth not build already-installed build or run dependencies?




					forums.freebsd.org
				




(in a nutshell, dependecy graphs in make are for the build process itself and have nothing to do with library dependencies of the software built.)


----------

