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
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:29 UTC