Dear all,
it now works... the short solution is: ignore the docs which come with
it, get two Trudes like Tom Blinn and Sean Davidson suggesting stuff
and then hack away.
Background:
1) DS20E shipped with 4.0G,
2) application requires/desires 4.0F,
3) DE600 NIC (EtherExpress-based, 'ee' device),
4) base 4.0F does not support the DE600.
so, what you do (in theory) is:
1) Install 4.0F,
2) Apply NHD3 (New Hardware Delivery, Rel. 3) downloaded from
ftp://ftp.europe.digital.com/public/unix/v4.0f/nhd3.tar.gz
with the additional requirements of:
a) machine on the net ('cos your DE600-based 4.0F box sure isn't),
b) CD-writer,
c) Alpha with mkisofs to make the bootable CD.
3) Apply PK#4 from the usual place, see 2) for hint.
Fine: it fails in 2) in a pretty dire way, at least on my box. The
box we are talking about is a DS20E with the new(er) 6-disk tower
cabinet, firmware 5.8-10, a KZPAC-CA driving 2x 9.1Gb disks in RAID 1
(mirrored systems disk), 1Gb RAM and a DE600 network card.
So, when you do 2) what happens is that one of the subsets, namely
OSHHWBIN102 fails during the IVP saying that the files
sys/BINARY/ee.mod
sys/BINARY/aha_chim.mod
cannot be found by pax. Note that the paths are _exactly_ as written
above (this will become relevant later). This failure adds a polite
message saying that your system is now probably unstable and that you
should reboot the universe. It is worthwhile noticing that the tar.gz
file as downloaded passes the checksum test vs. the checksum file in
the same place, furthermore if a tar xvzf is run on it on a Linux and
OpenBSD box all is well (i.e. GNU tar) but under DU you a "trailing
garbage ignored" message. Mmh.
Panic follows (the machine was clearly due in production the next
day). The solution came slowly by aggregating knowledge: Tom Blinn
explained why the above mechanism is a right-royal mess, Sean Davidson
sent an e-mail with possible causes and solutions and finally the
local Compaq man (Hi Theodore!) offered to use the internal Compaq
network to hunt for solutions. Theodore took charge of downloading
both a fresh NHDv3 and a NHDv2 kit (since Tom Blinn told me that the
ee driver was in v2 already) and burn CDs padded to 650Mb as Sean had
written that...
"Yes there are issues with non corporate COMPAQ make NHD CDs because
the firmware on the system during the boot process uses the first
CD it finds as the size of all other CDs so the NHD CD is about 30mb
and when the OS CD is put into the CD drive it is also viewed as only
30mb and lots of files cannot be found. The NHD CD must be 650mb
in size as seen by the CDROM drive for everything to work correctly.
The NHD CDROMs ordered from manufacturing were produced this way."
In the same mail he suggested that, given that the box was already
running 4.0F then I didn't _need_ to boot off the CD (which is really
needed only in the case of new hardware being added) but could do it
by hand... I'll let Sean speak:
"Since all you need is the ee driver you can do the following:
Get the gzip tar file that contains the kit onto your system or burn
the gzip tar file onto a cd.
Then create a directory /var/tmp/nhd and then dump the gzip tar
file into the /var/tmp/nhd directory.
gzip -dc foo.tar.gz | tar -C /var/tmp/nhd -xpf -
Now just do a setld right from the /var/tmp/nhd/V4.0F directory
and select all the subsets.
setld -l /var/tmp/nhd/V4.0F/kit
At this point the new ethernet driver should have been loaded and
made available to rebuild a new target kernel with doconfig.
doconfig
Or you can just add the ee driver line to your existing config
file.
echo "config_driver ee" >> `hostname -s | tr '[a-z]' [A-Z]'`
doconfig -c `hostname -s | tr '[a-z]' '[A-Z]'`
Then copy your newly built kernel to /vmunix and reboot."
OK, so the above sounds trivial but sadly it didn't quite work. Let
me describe my steps:
1) extract the nhdv3.tar.gz file,
2) burn a CD with both the tar.gz and the extracted tree as contents
(non-bootable, trivial ISO9660 filesystem) so that I could take it
over to the DS20E,
3) run
find . -type f -exec md5sum {} \;
on both CD and directory tree to check that the contents matched,
4) mount the CD on the DS20E in /mnt,
5) setld -l /mnt/V4.0F/kit,
*Boom*
it fails on the IVP again. Uh-oh.
6) Fine, so perhaps it is the CD which is an issue, extract in
/var/tmp/nhd as per Sean's message,
7) setld -l /var/tmp/nhd/V4.0F/kit,
*Boom*
it fails on the IVP again. Uh-oh.
8) Hacking time, if you look at the .inv (lives in /usr/.smdb./) file
you notice that the files for the kernel modules have a path
starting with sys/ and that it might well be that something there
is the problem. Hence...
cd /var/tmp/nhd
ln -s V4.0F/sys .
ln -s V4.0F/usr .
cd V4.0F
It works! Or so I thought until I rebuilt the kernel and the 'ee'
driver wasn't there (via doconfig). Not Good(tm),
9) add the config_driver to the kernel configuration file in
sys/conf/MACHNAME
as per Sean's instructions (while you're at it you might also want
to add aha_chim which are the Adaptec on-board controllers),
10) doconfig -c MACHNAME and the card is finally there!
11) while you are at it repeat 9)&10) with GENERIC so you have a
genvmunix which can see the network if need be...
And, just to prove it really does work:
# uname -a
OSF1 lilith V4.0 1229 alpha
# ifconfig -a
ee0: flags=c63<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST,SIMPLEX>
inet 192.168.51.34 netmask ffffff00 broadcast 192.168.51.255 \
ipmtu 1500
None of this would have been possible without the support and
suggestions of Tom Blinn and Sean Davidson. Also Theodore from GCC in
Nicosia (Cyprus) helped out by re-doing the CDs and checking on the
internal Compaq sites for hints (we didn't find anything which was
very relevant) along with coming round to hack at the problem with
me.
Ciao,
Arrigo
P.S. Hint of the day... Tom Blinn wrote:
``The OSHPATCH102.dw file means the patch "didn't work" ("dw").''
--
Arrigo Triulzi <arrigo_at_albourne.com>
Albourne Partners Ltd. - London, UK
Received on Fri Jan 19 2001 - 18:24:25 NZDT