Unable to boot after update to release 12.2

P

Pixa

Hello,
From a clean and working system on release 12.1, I did a freebsd-update fetch + upgrade -r release-12.2 + install.
After this when running program from command line, an error "ld-elf.so.1: /lib/libc.so.7: Undefined symbol" was thrown.

So, I decided to rollback the update with freebsd-update rollback.
NowThe system is stuck and each command returns "ld-elf.so.1: /lib/libc.so.7: Unsupported relocation type 37 in non-PLT relocations".
Even after reboot, the system cannot even load the shell and the same error is displayed.

Does someone has any idea how to solve this ?

Thank you.
Pierre.
 
Try boot into single user mode and start the network service so you can complete the upgrade, 12.1 is no longer supported so you might as well attempt to perform the upgrade.

The fetch command will inspect your system to be ready for the upgrade and after you input the upgrade command you'll need to restart to input the install command.
 
Worst case scenario is to use fetch (iirc, on my phone right now) and grab and extract the system archives manually. It'll be a mess (somewhat) but you'll get a working system back.
 
the3ajm said:
Try boot into single user mode and start the network service so you can complete the upgrade, 12.1 is no longer supported so you might as well attempt to perform the upgrade.

The fetch command will inspect your system to be ready for the upgrade and after you input the upgrade command you'll need to restart to input the install command.
Click to expand...
Same when booting in single user mode : no shell is loaded because each command returns "ld-elf.so.1: /lib/libc.so.7: Unsupported relocation type 37 in non-PLT relocations"
 
Something got really screwed up at some point. The binaries in /rescue/ might be useful, these are statically compiled versions of a few important commands.
 
Well, nothing works ...
I was really surprised that the update operation went wrong... FreeBSD... a state-of-art OS... simple update... dead :X

Is it possible to resinstall the OS without reformatting the disk, so that the data can be keeped ?
Currently, the ZFS partition is ok, all data are on it and it's still possible to mount it.

I would like to run the freebsd installer so that it resinstalls itself on the same disk, and then I will resinstall the software and move the data to rework properly.

Thanks for replies.

Pierre
 
The installer really doesn't do much more than extract a couple of archives from the install media. You could just do the same by hand. I've done this in the past to fix a completely hosed system. Not the best solution but it'll help when you're in a pinch.
 
Hello,

The answer is "no" :(

Even manual installation was problematic.

I ended by reformating and reinstalling all. I take advantage of this to add a new HDD for the storage, so that there is now 3 drives for RAID5 instead of RAID1.
I also added a small SSD drive for system.
So that : system is stored on an independant drive and if this is happening again, the system can be reinstalled without losing data.

Have a nice day,

Pierre.
 
"So, I decided to rollback the update with freebsd-update rollback."

You should have asked for help before making things more complicated.

"Undefined symbol". Cannonical libs can define the same symbol in a lib file many times. Say you have "putc(char)", and cannonical decides they want a "new putc()" (ugh! why??). They make a __putc, do some foo, and your libc now has a few putc ("the minimal number of they say"), now aliased so that depending on the age of the software using putc (what lib version they asked for) is which putc they get. They say it reduces number of libs: it is at the price of always being required to have the latest lib version from cannonical, however, and accepting any breakage of of past support they decided to "unsupport".

"Unsupported relocation type 37 in non-PLT relocations". Cannonical has a wild UK gov funded initiative to make every memory region any lib and software as marked with an authority type and relocation type. Is it for security or so UK has hack dominance? You decide. page lookup table.

I would guess you physically have the wrong libc file that was somehow stamped as libc7 or that ld-elf.so.1 was not updated. that's my guess. Your /usr/compat/lib folder is a chroot of a kind and you need to (download) the files in that folder. I would replace all of them. But as Sir Dice said "you might want to just reinstall all of it" (the whole linux gig)

If you actually compiled the linux base (i'm guessing freeBSD doesn't currently allow offer that), then it's more complicated, libc compiling is easy if you have the right gcc version and the same compile options cannonical used: which they (used to?) keep under their hat. Compiling libc incorrectly can lead to the wonderful "multiple libc function aliasing" to break, however.
 
I compiled a linux from scratch (before LFS was released able to) and have a boot usb. Mine runs lib6 AND libc5. You can compile libc5 or lib6 and run either. It means my old apps run. I had to do a little ld hacking - i think just some configuration file. They tell you "you can't run libc5, you can run old sun binaries". That is true for "the basic install". Not true in general.
 
ok sorry. "ld-elf.so.1: /lib/libc.so.7" i think are libc issues. People who used cannonical's libc are familar with how often one gets symbol errors on those linux systems due to (their own mistakes): probably millions of questions one can google of people had issues due to failed installation.

I thought the discussion was interesting but I'm pretty sure the source of the problem is very much related to libc: it's installtion or ld's. As I said. I think that is what it has to do with libc.

the LIBC in /usr/compat is Cannonical's libc (ubuntu). There are other libc that work in linux and they do not support ubuntu very well - especially Xorg, kde, and other apps. they are all made to work only with cannonical's libc

If one is getting libc errors in BSD for linux, it's cannonical/ubuntu error. And that libc was indirectly derived from RedHat's (cannonical) libc (which are now different brances and not compatible).

There is not a chance in the world you can have "a generic libc" and port "either Redhat or Ubuntu" ... you'd need /usr/compat-rh and /usr/compat-ubuntu to do either or, or to port apps onto one of the two.

This is really off topic answerign the question. But there you go.
 
This is a "wild bet". Check (if you have one) your ld.conf file. If the installer "didn't overwrite it because it was a user modified file in /etc/", using "the wrong or missing ld.conf", you might get an error like i see above ... IF i remember correcly. sorry if I didn't. No, not the ld.conf file taht configures paths. The ld configuration file that configures library loading (the real conf file, see manpage for it)
 
ld.so and ld-linux.so (have options and a config file) (the linux end i'm unsure about the freeBSD end excuse me). ldconfig(1) only changes the paths option.

The following file may need to exist in your linux base (i had to make one when I built a linux system)

/etc/ld.so.preload

(I cannot find all the config files for ldd and ld.so at the moment. Perhaps it was in a GNU info page not manpage and can't be googled easily)

"when you compile a program, ld marks the elf with static or dynamic options"

So you have an (possibly not updated ld[-linux].so trying to load (maybe not updated and ln -s libc.so libc.so.7) and failing.

however - before that happens - before libc.so.7 loads i *think* other libs (like to read off ext2 and then also elf header) have to be pre-loaded (ie, perhaps to interpret PLT sections) - and if i remember some of these are modules - conditionally loaded. that means preloaded, in ld.so module talk. so you have an ld.so that doesn't necessarily pre-load modules needed to read the elf that is attempted to be loaded ... unless the config file calls it out or unless somehow it's a compiled in default (discouraged).

that is why i think you might have an old or missing config file in your new /usr/compat update

i could be wrong
 
Disaster lifesavers:
  • echo * acts similar to basic ls(1)
  • set path = /rescue (for csh(1)) or PATH=/rescue; export PATH (for sh(1))
  • If you have incompatible hardware, don't blame FreeBSD. I.e. if you want to run FreeBSD, check the compatibility lists and choose your hardware from that
  • Doesn't mean it's all perfect / there's no room for improvement; e.g. there could be an option to set the above from the single user login.
 
  • Thanks
Reactions: a6h
debguy said:
i could be wrong
Click to expand...
Seeing as how the original poster didn't mention /compat being a problem, "Canonical's" libc is glibc and not BSD libc, glibc is not installed to /lib, most of the possible solutions you mentioned have something to do with Linux, and you mention all sorts of linux-isms like ext2, I fairly certain most of what you posted is not applicable to a broken FreeBSD install.

Also, this thread is over as the problematic install has been wiped so there's no problem to solve anymore.
 
You must log in or register to reply here.
Back
Top