Re: stable/12 broken?
On Fri, Feb 22, 2019 at 07:53:57AM +0100, Antoine Brodin wrote: > On Fri, Feb 22, 2019 at 7:39 AM Antoine Brodin wrote: > > Hi, > > > > For your information, the stable/12 branch seems broken, at least on > > i386, there is a segmentation fault when trying to run binaries and 0 > > package can be produced. > > The regression happened between > > SVN Revision: Jail stable/12 -> 344262 > > and > > SVN Revision: Jail stable/12 -> 344454 > > The onlly relevant commit seems to be: > > Author: kib > Date: Thu Feb 21 12:13:27 2019 > New Revision: 344436 > URL: https://svnweb.freebsd.org/changeset/base/344436 > > Log: > MFC r344120: > Unify i386 and amd64 getcontextx.c, and use ifuncs while there. Thank you, Antoine. The commit was reverted, see the commit message in r344463 for explanation of the issue. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: libcrypto.so.111 linked binaries SIGSEGV (in bhyve guest)
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 filesystem! 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. Thanks, -harry ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
