Problem: After an upgrade from 3.0B to ... to 4.0 I failed to compile the kernel (see original message at the end)
Most helpful were the answers of Tom Blinn <tpb_at_zk3.dec.com> which I summarize below,
I received also some messages stating that I cannot upgrade from 3.0B->4.0,
I was obviously to short here, with a drag I ment: 3.0B->3.2->3.2C-(Firmware upgrade)->4.0.
Tom > Hi. I can't tell for sure what is wrong, but I'll tell you how to
Tom > go about a check of the OSF inventory on your system to see if all
Tom > the files are the ones they should be. I will also tell you that
Tom > what's killing the build is a conflict in the compilation of
Tom > conf.c, one of the files that is copied to each configuration's
Tom > build directory and recompiled. That file is including a local
Tom > header file strkinfo.h that is redefining a symbol STRKINFO. If I
Tom > were trying to diagnose this more thoroughly, I'd be figuring out
Tom> what part of the configuration process creates the strkinfo.h file
Tom> and what definition was in effect that caused the conflict. In any
Tom> case, you're not getting a good conf.o file created from conf.c.
Tom>
Tom> To check your inventory, first run these steps as root:
Tom>
Tom> # rm /tmp/OSF400.inv # cd /usr/.smdb. # for lk in OSF*400.lk ; do >
Tom> cat `basename $lk .lk`.inv >> /tmp/OSF400.inv > done
Tom>
Tom> This will create a file in /tmp/OSF400.inv that contains the
Tom> concatenated contents of all the source inventory files for which
Tom> there is a lock file in the /usr/.smdb. directory.
Tom>
Tom> Now you need to run the /usr/lbin/fverify utility -- see the
Tom> reference page for a cogent description of what it does. Here's how
Tom> you run it:
Tom>
Tom> # cd / # /usr/lbin/fverify -np < /tmp/OSF400.inv
Tom>
Tom> If it reports any checksum or size mismatches (and it may) then you
Tom> need to figure out why the file differs.
Tom>
Tom> If that doesn't turn up the source of the problem, then you need to
Tom> check the .product.list file on the system:
Tom>
Tom> # cd /sys/conf # cat .product.list
Tom>
Tom> If there are kernel layered products registered in the file, then
Tom> you might need to edit your kernel's copy of .product.list (in
Tom> /sys/conf/SYSTEM.list where SYSTEM is the configuration file name)
Tom> to remove them, and retry the build. However, doconfig is supposed
Tom> to do this for you.
Tom>
Tom> If you do turn up inventory mismatches with fverify, you can use
Tom> grep to do a search of the /usr/.smdb./OSF*.inv files to figure out
Tom> what subset had the original file, and you should be able to
Tom> restore the file from the media.
Tom>
The above fverify showed some flaws:
> # /usr/lbin/fverify -np < /tmp/OSF400.inv > /tmp/OSF400.verify.result
> ./usr/ccs/lib/cmplrs/cxx/libcxx.so: cannot stat (No such file or directory)
> ./usr/var/dt: permissions rwxrwxrwx should be rwxr-xr-x
> ./etc/dec_hw_db: checksum 44343 should be 00000
> ./etc/dec_hw_db: size 2896 should be 0
> ./etc/dec_hw_db.bak: checksum 44343 should be 00000
> ./etc/dec_hw_db.bak: size 2896 should be 0
> 6 verification errors encountered.
> 0 corrections performed.
Tom>The verify errors you saw are probably not indicative of any real
Tom>problem; the ./usr/ccs/lib/cmplrs/cxx/libcxx.so is surprising, but
Tom>the others are not. libcxx.so should have been loaded as part of
Tom>the OSFBASE400 subset. The dec_hw_db is, I believe, the database
Tom>of hardware options; an empty file is delivered in the inventory,
Tom>and the file gets modified by some system component, but I'm not
Tom>sure just which.
Tom further suggested to remove all ALL files in the /sys/SYSTEM [where the kernel will be compiled]
and do a
doconfig -c SYSTEM
whic repopulates the /sys/SYSTEM and then tries to compile.
This worked just fine -> we are back on track again.
a grep for the problematic STRKINFO definition showed that the /sys/SYSTEM directory
had an old and obsolete copy of *.h files and maybe others which caused the compile failure.
Peter
The original question:
Peter> Hi netters, After upgrading our Dec Alpha 400 4/166 from 3.0B OSF1
Peter> to DUNIX 4.0, which was a drag but not too complicated, I fail to
Peter> compile the kernel, the process stops with the following: ...... rm
Peter> -f conf.o cc -c -O2 -DLANGUAGE_C -g3 -G 4 -I -I. -I.. -I../include
Peter> -DIDENT=EVOLUTION -DDEC2100_A50 -DSWAPTYPE=1 -DGENERIC -DUERF -DOSF
Peter> -DULT_BIN_COMPAT -DCOMPAT_43 -DMACH -DUFS -DRT_SEM -DKERNEL
Peter> -D_KERNEL -D_BSD -signed -Wg,-w2 -compress -no_excpt -Wg,-unroll,1
Peter> -Wb,-static -Wco,-nofloat -Olimit 3000 -D__alpha -Umips -UMIPS
Peter> conf.c cc: Warning: strkinfo.h, line 1: The redefinition of the
Peter> macro "STRKINFO" conflicts with a current definition because the
Peter> replacement lists differ. The redefinition is now in effect.
Peter> #define STRKINFO 1
Peter> -----------------^ objZ: No such file or directory - conf.o ***
Peter> Exit 1
Peter>
Peter> Running the "generic" kernel works fine including the multiuser
Peter> environment for most things. On this system we had under 3.0B
Peter> trouble to compile the kernel using doconfig, but doing it by hand
Peter> worked, both ways fail now. The manual hints that there are
Peter> probably some subsets which are incompatible with the hardware, but
Peter> I cannot see any problematic subset, maybe we do not need all of
Peter> them. At the end of this mail I add the list [a minor question,
Peter> which I can probably look up in manual: is there away to get rid of
Peter> some old uninstalled subsets?]
[snip]
-----
Peter Beerli <beerli_at_genetics.washington.edu>
University of Washington, GENETICS, Box 357360, Seattle,
WA 98195-7360, USA. Work:(206) 543-8751,
Home:(206) 527-9906, Fax:(206) 543-0754; GMT+0800.
WWW://evolution.genetics.washington.edu/PBhtmls/beerli.html
Received on Fri Jul 26 1996 - 19:19:02 NZST