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

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.

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

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

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.

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

...

> 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 ?

> 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