Re: fsck seg fault failure on vmware -i386?

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Fri, 12 Feb 2010 13:27:44 -0000
    From:        yancm%sdf.lonestar.org@localhost
    Message-ID:  
<d7f401681e22233d1a771573cec1cf22.squirrel%webmail.freeshell.org@localhost>

  | After waaay to long, I finally got my VM rebuilt using -current from
  | 1/15/2010. It sure would be nice if there was some sort of nuclear
  | cvs command to ignore all conflicts and just make my stinkin' tree
  | look like the source tree.

Yes, it would be nice ... the way we usually do that (or at least the
way I usually do) is just to rm -fr what I had there, and cvs co all
over again...

Otherwise, just removing any files that have conflicts (or even report 'M'
(local mods merged) from cvs), and re-run the update (cvs will complain
about "lost" files, then replace them) works as well.   If there are only
a handful of local mods that you want to obliterate, and you can find them
easily, this can be quicker.

  | - I've compiled libc with DBG=-g in the libc Makefile.
  |    o This did not produce libc_g.a in /usr/obj/lib/libc

No, I don't see anything that would ever make an _g.a version of the
library, I think whoever suggested that might have been mistaken.

  |    o This did produce a libc.a that was about 2x the size
  |      of/lib/libc.a so I assume it has symbols and is debug (?)

Maybe, you could test with
        nm libc.a
and see what it says - expect lots of output.  if all you get is
undefined symbols (U), and T D W and B (capital letter) types, then
you don't have the debug.   If debug is there you should also see lots of
stuff with lower case letter types (t d ...)    You don't have to look
through all the output, the first function or two should be enough to tell.

I'd also have suspected rather more than twice the size- gdb symtabs (the stuff
the -g option produces) tend to be huge.   What might have happened here,
is that DBG=-g turns off -O (compiler optimisation) - which is generally a
good thing, it makes debugging easier, the optimiser can confuse gdb,
but that would make the objects bigger, and I could believe twice as big
(though that is quite a lot.)

But, when building the .a libraries, the make scripts clean up the symbol
tables by default, unless -g is in COPTS - what's in DBG goes into CFLAGS
not into COPTS (COPTS also goes in CFLAGS, and what ends up in CFLAGS is what 
the compiler gets).   That's most likely a bug in bsd.lib.mk (or it might be
a design choice, sometimes it is hard to know).

Anyway, I suspect that perhaps the DBG=-g way of compiling with -g
might have been the wrong way, the library would have been compiled with
-g (and no -O options), and then all the symbols carefully added, thrown
away as COPTS doesn't contain -g.   The COPTS+=-g might have worked a lot
better (though that way doesn't disable optimisation).   But without looking
at the libc.a that you have I can't be certain,    But I kind of suspect
that you might need to build again.

  | - I've compiled fsck_ffs with CPPFLAGS+= -g and
  |   DPADD+=/usr/obj/lib/libc/libc.a in the Makefile

If that finished without errors, that's a good sign (it shoes that
the process was OK).  If you run
        nm fsck_ffs | grep localtime
you should see something like
        0804abd0 T locatime
(not at that address, of course), that indicates that you have localtime
from the static library.   If you see
                 U localtime
instead, that means the static library didn't get used, and localtime will
come from the shared libc at runtime.   You want the T version!

This is a test you can do now, for this it doesn't matter whether the
gdb symbols remained in that libc.a or not to find out if fsck_ffs built
the way we want it to.

  | - I've run: ldd ./fsck_ffs which gives
  |     o ./fsck_ffs:
  |         -lc.12 => /lib/libc.so.12
  |         -lutil.7 => /lib/libutil.so.7
  |         -lprop.1 => /lib/libprop.so.1
  |     o Should I be concerned that -lc is still referenced rather
  |       than my debug version which I manually linked in?

Not necessarily - cc adds "-lc" anyway, which would find the shared version,
so this isn't necessarily a problem (libutil and libprob, those other
libraries, would need the shared libc).   I suspect that this one should
be OK (having two versions of the library could be a problem, but I doubt
it will do any harm here).

  | - I've run: ldd /usr/bin/gdb which gives:
  |    o /usr/bin/gdb:
  |         -lc.12 => /usr/lib/libc.so.12
  |         -ltermcap.0 => /usr/lib/libtermcap.so.0
  |         -lcurses.7 => /usr/lib/libcurses.so.7
  |         -lintl.1 => /usr/lib/libintl.so.1
  |         -lm.0 => /usr/lib/libm387.so.0
  |         -lm.0 => /usr/lib/libm.so.0
  |         -lkvm.6 => /usr/lib/libkvm.so.6
  |    o Some of these are common in /lib some not.

The stuff that's common is really in /lib - eg: /usr/lib/libc.so.12
doesn't really exist (well, it does, but just as a symlink to
/lib/libc.so.12.N)  The libraries have entries in /usr/lib so everything
can be found there, but they have to actually be in /lib so they're
available to commands that run in single user mode.  If you were to
run ldd on something in /bin or /sbin you'd see that it refers to
/lib/libc.so.12 because /usr might not be around when the program is run).
For example, fsck_ffs above - it used /lib/libc.so

  |    o Do I just need to move these (and associated/corrected links) to
  |      /lib?

No, that's both too hard to do correcty, and too likely to go wrong
(and then you'd need to convince gdb to look in /lib for its libraries
instead of /usr/lib where it was told to look).   Not worth the hassle.

  |       Or do I create a temp directory at root and create a temporary
  |      /usr/lib directory once I come up in single user without the real
  |      /usr partition mounted?

That's what I'd do, every time.   It's easier.   You can copy all of
/usr/lib if you prefer, it won't do any harm, I'd use

        cd /usr && pax -rw -pe lib /temp 

(after making /temp).   That should copy everything from /usr/lib to
/temp/lib including correctly copying the symlinks, and getting all
permissions etc right.   Don't forget to also copy the termcap database
from /usr/share/misc/termcap* (those files you can just cp easier.)

Then in single user mode

        mount -u -w /

(after a fsck if one is needed on the root - if the root filesys is
the one with the problems, this gets harder...)

        mv /temp/lib /usr/lib
        (and mv the termcap database too).

before that, /usr should have been an empty directory.   There's no
need (except to recover the space) to ever clean this up, when /usr
is mounted, the stuff in /usr/lib underneath just "vanishes" - if you
do want to recover the space, you need to do that in single user mode
(with /usr not mounted) too.

kre