SUMMARY2: installing Tru64 5.1B on PW500au, moving system disk to DS20E

From: Bob Marcan (bob.marcan_at_aster.si)
Date: 06/23/03

  • Next message: speakmaj_at_mskcc.org: "defragcron on CFS volumes" 
    Date: Mon, 23 Jun 2003 16:47:09 +0200
To: tru64-unix-managers@ornl.gov

    Well, i really didn't give up.
    Found some old mail and this works.
    Then scr..ed up disklabel and reinstalled all again.

    Best regards, Bob

    -------------------
    Boot from distribution CD.
    Exit to shell.

    mount -u /
    dn_setup -init
    sbin/dsfmgr -K
    advscan -r /dev/disk/dsk0
    mount domain_dsk0a#root /mnt

    rm /mnt/etc/dec*
    rm /mnt/etc/dccd.*
    rm /mnt/etc/dcdd.*
    rm /mnt/etc/dfsc.*
    rm /mnt/etc/dfsl.*
    rm /mnt/cluster/members/member/etc/cfginfo
    rm /mnt/etc/cfginfo
    rm /mnt/cluster/members/member/etc/dfsl.*
    rm /mnt/dev/tty0*
    rm /mnt/dev/lp*
    rm /mnt/dev/kevm*
    rm /mnt/dev/scp*

    for dir in cport disk rdisk changer tape ntape; do
            rm -rf /mnt/devices/$dir
            rm -rf /mnt/cluster/members/member/$dir
            rm /mnt/dev/$dir
    done

    rm /mnt/cluster/members/member/.Booted

    cp -p /genvmunix /mnt/genvmunix

    # halt

    P00>>>b dka0 -fi /genvmunix -fl s
    bcheckrc
    ...
    -------------------

    The old mail.
    It's only a part which i saved as a comment in one of my scripts.

    ...
    2) Chris' response

    I did something like this (installed on an old AlphaServer 1000 for an
    ES40). After I did the install and got everything "set", I did the
    following on the AS1000 right before shutting down to remove the disk:

    #*#*#*#
    #!/bin/sh
    # Run in the root directory of the filesystem to "clean"

    rm ./etc/dec*
    rm ./etc/dccd.*
    rm ./etc/dcdd.*
    rm ./etc/dfsc.*
    rm ./etc/dfsl.*
    rm ./cluster/members/member/etc/cfginfo
    rm ./etc/cfginfo
    rm ./cluster/members/member/etc/dfsl.*
    rm ./dev/tty0*
    rm ./dev/lp*
    rm ./dev/kevm*
    rm ./dev/scp*

    for dir in cport disk rdisk changer tape ntape; do
            rm -rf ./devices/$dir
            rm -rf ./cluster/members/member/$dir
            rm ./dev/$dir
    done

    rm ./cluster/members/member/.Booted
    #*#*#*#

    That basically wipes out the hardware database, and when you boot (on
    the real system), it will be recreated for the real hardware.

    3) Bluejay's response

    Depending on how complex your systems are, this might or might not actually
    save you any time. Particularly if it doesn't work.

    Having said that, this *should* work, however you'll also need to delete the
    device database files when you move the system over, in addition to booting
    with the generic kernel. The files should get re-created on your first boot.

    The files involved would be

    dccd.bak dccd.dat dcdd.bak dcdd.dat dec_devsw_db
    dec_devsw_db.bak dec_hw_db dec_hw_db.bak dec_hwc_cdb dec_hwc_cdb.bak
    dec_hwc_ldb dec_hwc_ldb.bak dec_scsi_db dec_scsi_db.bak dec_unid_db
    dec_unid_db.bak dfsc.bak dfsc.dat dfsl.bak dfsl.dat

    If you try and keep these files from your ES40, don't be surprised if you
    get a panic shortly after booting, even with the generic kernel. I've had
    this happen when moving systems around between DS20s and ES40s.

                                                    - Bluejay Adametz

    I am sure all 3 will work, & am going to have a bash at using option 2 which
    seems to have the backing of Compaq's support centre. NOTE: They will NOT
    support the build phase if I have any problems (the only supported build
    option is from CD). However, the ongoing support of this system will be no
    problem provided the HW database looks clean after the build.

    Original question :
    We are rebuilding a GS160 partition over next weekend. It is currently 4.0g
    - we plan to go to 5.1a.

    We are under a bit of time pressure over the weekend, so I was hoping to
    prebuild the 5.1a disk (+ Patch Kit) on another server (an ES40) on which I
    have downtime today. Then come the weekend, boot this new system disk on the
    target server. Naturally, the hardware database will be totally different.
    I've overcome this before in the good-old 4.0 days by booting off
    /genvmunix, running a sizer -n, grabbing the relevant H/W config text &
    using this to rebuild a new kernel, and then was able to reboot off /vmunix
    without any problems

    Question is: Is there a way of doing this on tru64 v5 which doesn't involve
    a lot of time ?

    Regards,

    Phil Richardson
    UNIX Administrator
    ______________________________ __

    ACXIOM
                                                                    
    Direct Dial: +44 (0)191 525 7433 Acxiom Limited
    Telephone: +44 (0)191 525 7000 Camberwell Way
    Fax: +44 (0)191 525 7100 Doxford Technology Park
                                            Sunderland
    E-mail: phil.richardson@acxiom.com SR9 9XZ 

    -- 
  Bob Marcan                             mailto:bob.marcan@snt.si
  Aster^H^H...HermesPlus^H^H^H...S&T   mailto:bob.marcan@aster.si
  Nade Ovcakove 1                       tel:    +386 (1) 5894-329
  1000 Ljubljana, Slovenia                      http://www.snt.si
  • Next message: speakmaj_at_mskcc.org: "defragcron on CFS volumes"

    Relevant Pages