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: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?502F475A.4060207>