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"
