Date: Fri, 22 Feb 2019 10:09:11 +0100 From: Harry Schmalzbauer <freebsd@omnilan.de> To: Eugene Grosbein <eugen@grosbein.net>, Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-stable <freebsd-stable@freebsd.org> Subject: Re: libcrypto.so.111 linked binaries SIGSEGV (in bhyve guest) Message-ID: <9bb73bcb-ecf6-7fc0-cd34-4bf9fc0864bd@omnilan.de> In-Reply-To: <7b8b7a29-d956-c1b1-ea16-21896c683aca@grosbein.net> References: <335630bc-a558-9e31-5e2d-aee6237e83b0@omnilan.de> <596d1486-e2af-43f7-6f3f-65881e91819d@omnilan.de> <20190221085432.GR2420@kib.kiev.ua> <c3ea0ae9-bdf0-3b1c-31f8-e53f8cba2689@omnilan.de> <20190221093645.GS2420@kib.kiev.ua> <de5748fa-3650-d35f-5329-31dd3ee04fe7@omnilan.de> <7b8b7a29-d956-c1b1-ea16-21896c683aca@grosbein.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9bb73bcb-ecf6-7fc0-cd34-4bf9fc0864bd>