Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 18 Aug 2012 09:42:18 +0200
From:      "O. Hartmann" <ohartman@zedat.fu-berlin.de>
To:        Garrett Cooper <yanegomi@gmail.com>
Cc:        FreeBSD Current <freebsd-current@freebsd.org>, freebsd-questions@freebsd.org
Subject:   Re: HELP! core dumps: install, mtree, et cetera all of the sudden after portmaster security/cyrus-sasl2
Message-ID:  <502F475A.4060207@zedat.fu-berlin.de>
In-Reply-To: <CAGH67wRLe9KKM5H_go_6Nj4nZP-Subdcn53LV8C=Zi3KZhp13Q@mail.gmail.com>
References:  <502D12C0.2060405@zedat.fu-berlin.de> <CAGH67wRLe9KKM5H_go_6Nj4nZP-Subdcn53LV8C=Zi3KZhp13Q@mail.gmail.com>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig9222267582D0970103638D21
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.
> <ohartman@zedat.fu-berlin.de> wrote:
>>
>> I ran into a very delicate and nasty situation.
>=20
> ...
>=20
>> On both FBSD 10 boxes, the installation of the port security/cyrus-sas=
l2
>> 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=
e
>> user mode.
>=20
> I'm not drawing a correlation between this and unrelated coredumping pr=
ocesses.

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!).


>=20
>> An installation failed due to pkg(ng) was missing libarchive.so via
>> portmaster or via core dumping install(1). By installing on one box, m=
y
>> home box, port security/cyrus-sasl2 manually, luckily install(1) and
>> mtree(1) didn't coredump and it worked - and this precedure rescued me=
=2E
>> But on my lab's development box, it doesn't work!
>=20
> 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).

>=20
>> On this specific box, where this nasty problem also occured the same w=
ay
>> 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?).
>=20
> 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.

>=20
> 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 ...

>=20
>> I tried to help myself via copying /rescue/vi to /usr/bin/vi to have a=
t
>> 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)?
>=20
> 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.

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

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

>=20
>> But most of the libs have never been touch! So what is the loader
>> complaining about?
>=20
> ...
>=20
>> 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 emergen=
cy
>> booted disk, I highly appreciate some desater advice. Maybe the releas=
e
>> 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,
>=20
>     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.
>=20
> Cheers,
> -Garrett

I know :-(

Oliver


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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (FreeBSD)

iQEcBAEBAgAGBQJQL0dgAAoJEOgBcD7A/5N8/NsIANT8PdNhIHZVzR3/qgmTIHJ9
zzrrJw8vd7Uh2qVndnLMIxlYtBqVHwDdqa1zqgEvFWMaYrZyfJPgppG5cbKdP3k2
+jHzPIir/rWCRmfAiAixo40C88c1lH9TAC638Gwu3YaVt8tHDHJgXGi5gnn9Jr7r
HcheoiNhoKmQSAP2a3xKwjquxtLMuoY4qnt8ghci68AmHO5M07XuNZVkekmYU39H
eCmfvsHgsMk4X2s3v228EieVD5daGOMCtAe1QHaOKOJFgoVKzFlO7HvL9DtL2cVf
cxCAZIuBmSejb2IO990vhnCiEQqP0dQ9hledMDk9rnRIKz9vtBQculaQ54ZCRPg=
=oV+W
-----END PGP SIGNATURE-----

--------------enig9222267582D0970103638D21--



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?502F475A.4060207>