libcrypto.so.111 linked binaries SIGSEGV (in bhyve guest)
freebsd at omnilan.de
Fri Feb 22 09:09:15 UTC 2019
Am 22.02.2019 um 04:51 schrieb Eugene Grosbein:
> 21.02.2019 22:27, Harry Schmalzbauer wrote:
>>> The object is clearly corrupted.
>> Thanks to your hint to readelf, I found out that it gets corrupted during dump(8) (or resotore, not yet analyzed).
>> The obj tree contains the good version, the dump archive not.
>> The dump archive is used as source for the ISO, hence the described errors.
>> Now I have to dig in 10 years old deployment scripts to track down and reproduce the corruption. No explanation so far, but for sure no rtld-elf problem :-)
>> And also not a problem in the FreeBSD make chain, building stable/12 on stable/11 works as intended and doesn't produce the mutilated libcrypto.so.111!
> You may find useful reading trail of this PR https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228174
> Long story short: dump(8) will read inconsistent data (or even garbage) from mounted file system
> unless used with -L to make and dump a snapshot. And UFS snapshots are not compatible with SU+J UFS
> created with installer by default in some versions of FreeBSD.
Thanks a lot for that additional relevant information. I'm aware about
the -L & SU+J problem. And I'm not conviced, the default installer
settings handle this situation correctly, at least not for the root
My issue was unrelated though.
I dump(8)ed a unmounted md(4), but restore(8) hasn't had enough space
(only view bytes, so size of the corrupted file wasn't obviously wrong)
and the deployment script hasn't checked the return status at all.
Fixed the script and now the restore(8)ed libcrypto.so.111 works.
More information about the freebsd-stable