Big thanks to
* Schoepflin, Keith [Keith.Schoepflin_at_hp.com]
* Chris Adams [cmadams_at_hiwaay.net]
and
* Adametz, Bluejay [bluejay_at_fujigreenwood.com]
for three quick responses, all based on similar tactics , and all of which
look good to me :
1) Keith's response
You will need to delete the hardware database and recreate it on the
5.1a disk. You can use the following procedure to do this. You can do
all the step in single user mode.
************************************************************************
***********************************
# cd /etc
# rm dec_*
# cp dfsl.dat dfsl.bak
# cp dfsc.dat dfsc.bak
# cat /dev/null >dfsl.dat
# cat /dev/null >dfsc.dat
# shutdown -h now
P00>>>b -fl s -fi genvmunix <bootdef_dev>
# mount -u /
# dn_setup -init
# dsfmgr -K
# doconfig
************************************************************************
***********************************
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_at_acxiom.com SR9 9XZ
*********************************************************************
The information contained in this communication is
confidential, is intended only for the use of the recipient
named above, and may be legally privileged.
If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination,
distribution, or copying of this communication is strictly
prohibited.
If you have received this communication in error,
please re-send this communication to the sender and
delete the original message or any copy of it from your
computer system. Thank You.
Received on Mon Sep 23 2002 - 15:14:18 NZST