HELP! core dumps: install, mtree, et cetera all of the sudden after portmaster security/cyrus-sasl2

[O. Hartmann]

Am 08/16/12 21:44, schrieb Garrett Cooper:
> On Thu, Aug 16, 2012 at 8:33 AM, Hartmann, O.
> <ohartman at zedat.fu-berlin.de> wrote:
>>
>> I ran into a very delicate and nasty situation.
> 
> ...
> 
>> On both FBSD 10 boxes, the installation of the port security/cyrus-sasl2
>> got corrupted by "install" and/or "mtree" dumping core and signalling
>> SIGNAL 11. Booting into multiuser mode is impossible, login core dumps
>> SIGNAL 11, many other daemons, too. The only way is to boot into single
>> user mode.
> 
> I'm not drawing a correlation between this and unrelated coredumping processes.

Me neither, I report this for completeness, since I'm not a OS
developer, such a behaviour could hint/indicate people who are involved
in the OS development, what is going on. Sorry when I'm trying to be too
precise (precise as precise I can be without the exact terminology!).


> 
>> An installation failed due to pkg(ng) was missing libarchive.so via
>> portmaster or via core dumping install(1). By installing on one box, my
>> home box, port security/cyrus-sasl2 manually, luckily install(1) and
>> mtree(1) didn't coredump and it worked - and this precedure rescued me.
>> But on my lab's development box, it doesn't work!
> 
> Don't make delete-old-lib unless you have it moved off to compat
> directories, or have rebuilt everything using the new libarchive.

I didn't! As I wrote before, this mess happened on ALL(!) freeBSD
10.0-CURRENT boxes in the very same way when I updated/reinstalled
security/cyrus-sasl2. Moreover: I can reproduce this on all boxes. All
my boxes use OpenLDAP as a backend with SASL2 enabled (not used so far).

> 
>> On this specific box, where this nasty problem also occured the same way
>> by simply recompiling everything for port www/apache22, including the
>> reinstallation of port security/cyrus-sasl2. Nearly every binary is
>> suddenly coredumping (as on the home box). login, vi, install, devfs,
>> syslogd, mtree, id, find ... a whole lot of binaries seem to be
>> compromised by something I do not see (libsasl2.so perhaps?).
> 
> truss the binaries to figure out exactly what's going wrong.

I will try, but when this errative coredumps of binaries occur, nothing
works properly that is using any kinf of dynamical loaded library! Only
the binaries (static?) from /resucue/* do their work.

> 
> A lot of this lost effort could be avoided (like others have posted on
> the list more than once), by having a centralized package distribution
> server, and by having VMs or jails and keeping snapshots with
> pre-upgrade state on the package building machine to avoid "dead in
> the water scenarios" like you're in right now.

Yes, I'm working on this. it seems, that it becomes more relevant since
I realized that FreeBSD suffers sometimes from misleaded ports or ports
which suddenly are marked BROKEN and do not get compiled ...

> 
>> I tried to help myself via copying /rescue/vi to /usr/bin/vi to have at
>> least a working vi. But in /rescue, I can not find install or mtree. I'm
>> not familiar with the sophisticated ways of /rescue. Where are
>> install(1) and mtree(1)?
> 
> I ran into this issue too a little while ago. I basically gave up on
> recovering a VM and nuked and repaved it using a LiveCD with a chroot,
> some cp -p'ing, etc. But yes.. it would be nice if I could have
> recovered the system at least with a static toolchain: cc, binutils
> [equivalent], mtree, install, etc.

This is how I recovered the nasty broken box. The other one was easy to
recover by reinstalling security/cyrus-sasl2.

I'm quite sure that there is something very foul with something in LDAP
or SASL2, since I can reproduce that proplem.

I saw that rtdl-elf has got some quirks these days, I will try to go
behind the date/version of the source tree when it was committed and
check whether this is the problem.

> 
> ...
> 
>> Disabling this pkgng tag leads to reinstallation of missing packages,
>> which are store in the pkgng sqlite format and not as ASCII anymore, but
>> then I get
>> /var/runld-elf.so.hints: No such file or directory
>> Error: shared library "iconv.3" does not exist.
> 
> service ldconfig start ?

Yes ... sorry ... in the heat of the fight I forgot ... but it doesn't
make the problem go away.

> 
>> But most of the libs have never been touch! So what is the loader
>> complaining about?
> 
> ...
> 
>> I tried to find rescue images and a rescue DVD of a snap shot server,
>> but there is no way to crawl through the informations on the web pages
>> towards a snapshot. All folders end up in 2011 and highly outdated
>> (www.freebsd.org, I didn't look at mirrors since I thought the main
>> server carries the most recent stuff). This isn't funny. No lead, no
>> hint, even in the download section.
>>
>> If someone has some hints how to recompile the sources with an emergency
>> booted disk, I highly appreciate some desater advice. Maybe the release
>> of FreeBSD-10-CURRENT sources I compiled do have accidentally a nasty
>> bug, so it would be nice to update the sources and have a complete
>> recompilation done.
>>
>> Thanks in advance,
> 
>     Simply put: fix your infrastructure (as this isn't the first time
> you have complained about infrastructure issues on the MLs). A lot of
> these issues should not be issues if you set up your infrastructure
> properly to deal with building things only once, backup packages
> before installation, you had snapshots of your system, etc. This will
> help you avoid administration pain, and hopefully will result in less
> duplicated work.
> 
> Cheers,
> -Garrett

I know :-(

Oliver

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20120818/35afc109/signature.pgp