SUMMARY - Problems rebuilding kernel after upgrade to 5.1B

From: Antonio Gonzalez (antonio.gonzalez_at_teleline.es)
Date: 05/24/03

  • Next message: Iain Barker: "TruCluster memory channel during Tru64 upgrade from 4.0f to 5.1b"
    Date: Sat, 24 May 2003 17:16:56 +0200
    To: tru64-unix-managers@ornl.gov
    
    

    After some helpfull mails from:
    Dr Thomas.Blinn@HP.com &
    Martin Rønde Andersen

    the problem was solved.
    After trying again doconfig we have this line in the QUIJOTE.list:
    /usr/opt/CAIENF:CAIENF:xxxxxxxx:Computer Associates

    This products are no longer installed but ... is a leftover from the Unix
    version 4.* times

    In /usr/opt/CAIENF there are some files that try forced doconfig to
    configure the
    CAIENF module into the kernel. But this module isn't compatible with version
    5

    Renaming / Removing this directory solved the problem.

    Thanks to the list !!!
    ============================================
    Reply from Dr Thomas.Blinn@HP.com ...
    This is the relevant part of the error messages; the rest is quite
    normal:

    > ld:
    > EXTRAS.mod compressed: proto_kern_ptetab: multiply defined
    > EXTRAS.mod compressed: proto_user_ptetab: multiply defined
    > EXTRAS.mod compressed: proto_user_segpte: multiply defined

    Is the file /sys/conf/QUIJOTE.list an empty file? If it's not, then
    you may well have some kind of kernel layered products installed, and
    it is HIGHLY LIKELY that they are incompatible with V5.x if you put
    them on the system while you were running V4.x. I ask because I see
    that when it built the basic kernel with no kernel layered products,
    the error message went away.

    In V5.1B, the symbols noted are defined in the source file
    arch/alpha/pmap_init.c as structures of the type pt_entry_t.

    I'm guessing that something that's getting linked into EXTRAS.mod
    has a conflicting definition.

    Also, you should make sure you completely clean out the directory
    /usr/sys/QUIJOTE which is where the kernel gets built; the easiest
    way to do this is to just rm -rf the whole directory, and let the
    kernel build procedure recreate it; this often resolves problems
    in kernel builds.

    ============================================
    Reply from Martin Rønde Andersen ...
    It seems you have had some strange drivers put on the system , that are
    no longer needed. EXTRAS.mod and QuiJOTE.mod contains the root of
    confusion.
    Did you add some emx drivers back in v4.* time ??

    At least there is definitions in the config file which should not be
    there, leftovers from version 4.*

    ===========================================
    Original question follows ...
    The path was 4.0D - 4.0G - 5.1 - 5.1B
    With v5.* we started to see a problem with doconfig:

    error:

    *** PERFORMING KERNEL BUILD ***

    A log file listing special device files is located in /dev/MAKEDEV.log
           Working....Tue May 20 20:27:10 MEST 2003

    *** WARNING ***
    An error has occurred during system configuration. A partial listing
    of the error log file (/sys/QUIJOTE/errs) follows:

    cc -c -O2 -DLANGUAGE_C -std0 -g3 -I -I. -I.. -I../include -
    DIDENT=QUIJOTE -DDEC2
    1000 -DUERF -DOSF -DCOMPAT_43 -DMACH -DUFS -DFFM_FS -DATM -DATM -DATM -
    DATM -DAT
    M -DRT_SEM -DCAIENF -DKERNEL -D_KERNEL -D_BSD -D_USE_KERNEL_PROTOS -
    compress -MD
    -no_excpt -nointrinsics -Wg,-unroll,1 -Wb,-static -Wco,-nofloat -
    msg_disable pt
    rmismatch1 -msg_enable
    cvtdiftypes,warnimplfunc,ptrmismatch,macroredef,lvaluecas
    t,uselesstyped -msg_inform
    cvtdiftypes,warnimplfunc,ptrmismatch,macroredef,lvalu
    ecast,uselesstyped -msg_enable
    uninit1,falloffend,intrinsicint,outtoomany,outtoo
    few,questcompare,storclsdcl,tentredef -msg_warn
    uninit1,falloffend,intrinsicint,
    outtoomany,outtoofew,questcompare,storclsdcl,tentredef -msg_enable
    othermember -
    msg_error othermember -Umips -UMIPS -U__intel__ -D__alpha -
    D__digital__ -D__arch
    ...........
    ...........
    ...........

    _data.o cam_data.o cam_special_data.o pcxal_data.o pci_option_data.o
    eisa_option
    _data.o ws_data.o emx_data.o cpuconf.o autoconf_data.o cons_sw_data.o
    /usr/lib/cmplrs/cc/objZ QUIJOTE.mod
    Generating version stamp
    Generating EXTRAS.mod
    Linking vmunix
    ld:
    EXTRAS.mod compressed: proto_kern_ptetab: multiply defined
    EXTRAS.mod compressed: proto_user_ptetab: multiply defined
    EXTRAS.mod compressed: proto_user_segpte: multiply defined
    *** Exit 1
    Stop.

    After you select to buld the kernel only with the basic options, it
    works
    and creates a kernel, but some aditonal options are needed as well.

    *** NOTE ***
    The customized kernel for this machine could not be successfully
    created. One possible problem could be kernel layered products
    that might be incompatible with the base operating system. This
    script will now automatically attempt to build a kernel using the
    base operating system only.
    Is this ok? (y/n) [y]:

    *** Retrying Kernel Build ***
           Working....Tue May 20 21:38:28 MEST 2003

    The new kernel is /sys/QUIJOTE/vmunix

    Any idea?

    The configuraton:
    - AS8400 with Tru64 v5.1B
    - No patches yet. I'm afraid of adding patches to this now !!
    - We updated frmware to 6.3 and run ECU
    All the reported problems dealing wth kernel builds seems to be absent
    here.

    the only thing we plan to do is to delete the kernel build modules and
    reload them from CD.

    Any hint on this ???

    Antonio González Ortiz
    Consultoría Técnica
    E-Mail: Antonio.Gonzalez@teleline.es
    Movil: 656.300.497


  • Next message: Iain Barker: "TruCluster memory channel during Tru64 upgrade from 4.0f to 5.1b"

    Relevant Pages

    • Problems building kernel
      ... but am running into trouble. ... other machines, including an identical ES40, without any problems. ... The customized kernel for this machine could not be successfully ... that might be incompatible with the base operating system. ...
      (Tru64-UNIX-Managers)
    • SUMMARY: Problems building kernel
      ... Thanks to Dr. Blinn I was able to solve the problem by taking the config ... file to another system and building the kernel on that machine. ... Tom ... > that might be incompatible with the base operating system. ...
      (Tru64-UNIX-Managers)
    • Re: tip: bzip2/lzma now in tip:x86/setup-lzma
      ... compress with all the compressors that are configured into the kernel, ... as kernel or module developers). ... support reading an extra initramfs image. ...
      (Linux-Kernel)
    • Re: [PATCH 9/33] i386 boot: Add serial output support to the decompressor
      ... For the same reason that we compress the kernel. ... If they're messed up the later boot will fail too. ... of including normal kernel code. ...
      (Linux-Kernel)
    • Re: tip: bzip2/lzma now in tip:x86/setup-lzma
      ... compress with all the compressors that are configured into the kernel, ... as kernel or module developers). ... support reading an extra initramfs image. ...
      (Linux-Kernel)