Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 18 Aug 2012 09:42:18 +0200
From:      "O. Hartmann" <>
To:        Garrett Cooper <>
Cc:        FreeBSD Current <>,
Subject:   Re: HELP! core dumps: install, mtree, et cetera all of the sudden after portmaster security/cyrus-sasl2
Message-ID:  <>
In-Reply-To: <>
References:  <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Am 08/16/12 21:44, schrieb Garrett Cooper:
> On Thu, Aug 16, 2012 at 8:33 AM, Hartmann, O.
> <> wrote:
>> I ran into a very delicate and nasty situation.
> ...
>> On both FBSD 10 boxes, the installation of the port security/cyrus-sas=
>> 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 singl=
>> user mode.
> I'm not drawing a correlation between this and unrelated coredumping pr=

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 via
>> portmaster or via core dumping install(1). By installing on one box, m=
>> 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 w=
>> 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 ( 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 a=
>> least a working vi. But in /rescue, I can not find install or mtree. I=
>> 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, b=
>> then I get
>> /var/ 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
>> (, 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 emergen=
>> booted disk, I highly appreciate some desater advice. Maybe the releas=
>> 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 :-(


Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

Version: GnuPG v2.0.19 (FreeBSD)



Want to link to this message? Use this URL: <>