(I added a few items to the subject list from the original posting since
the answers went beyond my specific question.)
Thanks to:
From: Tom Webster <webster_at_ssdpdc.mdc.com>
From: "Dave Golden" <golden_at_falcon.invincible.com>
From: alan_at_nabeth.cxo.dec.com (Alan Rollow)
Original question:
I've set up the 3 channel raid controller on 2100 5/300.
Recently, understanding from DecDirect that it was supported,
I got a 3 channel raid controller for an alphastation 255.
Unlike the 2100, there does not seem to be a mechanism for
loading arc in order to run the standalone raid configuration
routine at the console prompt. In the hardware book for the
system, it seems that running the firmware upgrade would allow
one to set the AlphaBios, but then getting it back to an SRM
console would require running the upgrade again.
=============================================================================
Tom Webster gave an excellent set of information and Dave Golden
pointed out the following URL:
-----
> ftp://ftp.digital.com/pub/Digital/Alpha/firmware/utilities/mkbootarc.txt
>
> This tells you how to make the bootable arc floppy I was talking about.
> Everything you need should be able to be downloaded from the web site.
>
> Good luck,
> Dave
>
> --
> Dave Golden golden_at_invincible.com
> Invincible Technologies Corporation
> -----
That document contains this reference:
tar xvf mkbootarc.tar
This file contains 2 .cmp images
ab512.cmp for Alphastation 255 platforms
arc445.cmp for Alphastation 200/250/400 series platforms
Well, currently that tar file does not have the .cmp files. These
files do not seem to be on the latest firmware CD. However,
for the 255 there is a file "abboot.exe" which seems to be, in part, what
is created by the mkbootarc command. There is another file on
that ftp site: mkbootfirm.tar
Tom refers to this below. With that program one can make a bootable
ARC floppy without burning in the ARC software.
So, from the ftp site above, get mkbootfirm.tar and check the README file.
I made a bootable image on floppy from the "abboot.exe" file
from the v3.8 firmware cd using the mkbootfirm command
that was on the digital ftp site. Boot from the floppy.
When it begins to run, it comes up with a dialog box and the message
that the "NVRAM is invalid" and that it would try to set
the NVRAM back to factory defaults. Press return to continue.
This is not something I was comfortable doing. Tom said it did not
seem to matter on his machines. I pressed the F2 key and it seemed
to work fine. There was a menu selection that enabled me to put
the standalone raid controller software in and run it.
At the end of running the raid software, back at the ARC menu,
I simply reset the machine to get back to the SRM console.
It seems to run fine after this. (Well there is one thing
after installing 4.0b, but that is for another message.)
I'm including Tom's notes below to fill out details that I missed.
-mike
---------------------------------------------------------------------
Michael A. Crowley mcrowley_at_mtholyoke.edu
Director of Network and Technical Services 413-538-2140
Mount Holyoke College, Dwight Hall fax: 413-538-2331
50 College St, South Hadley, MA 01075
---------------------------------------------------------------------
=============================================================================
Tom Webster
=============================================================================
>From webster_at_ssdpdc.mdc.com Wed Jan 15 23:28:54 1997
You really have two questions going at once here (1) what's the deal
with the firmware on the AS255's and (2) how do I run the RAID setup
utilites.
I'm going to give you the short answers first and attach copies of the
longer answers that I've sent to this group in the past.
As far as the firmware goes, it seems DEC decided to save a couple of
bucks on the AS200s and AS255s. Unlike the AS250's, these systems only
have enough NVRAM available to load either the SRM or ARC consoles.
If you read the DEC marketing lit. it just claims tha the systems
can run either NT or DU/VMS (it never says that you can dual boot with
any ease). DEC provides a partial solution on the Firmware CDs (3.7 and
up) that allows you to boot the arc console without reflashing the
NVRAM. There is a file in the AS255 directory on the CD called
"abboot.exe", just have the AS255 use it for the boot file.
That should get your immediate need to boot the ARC console taken care of.
In case you want to be able to boot to the ARC console more often (i.e.
to dual boot NT), I'm attaching the long version that discusses a network
and floppy based method of booting the ARC w/o flashing the NVRAM.
In regards to the SWXCRMGR software, you can boot to the ARC console
and run it from there, or you can actually run it from the SRM
console.
NOTE: This is how we do it on our 8400. I haven't had an opportunity
to try it on my AS255 yet (let me know if it works).
Here is the snipit on running SWXCRMGR (and SDRLMGR) from the SRM:
----- snip ----- snip ----- snip ----- snip ----- snip -----
In order to do anything more than parity checking and rebuilding
drives (after replacing the failed drive), you are going to have
to take the system down and use one of the stand-alone configuration
utilities from the console. The latest version of these utilites that
I am aware of is 3.11 and you need to use that to be compatable with
the later versions of DU 3.2. The utilites should have come on
a floppy disk (along with instructions).
If you can't find the floppy, all is not lost, the later versions of
of the Firmware CD's have the utilites.
I should say something about which utility to use: if you have a
graphics head and a PC style keyboard, use the swxcrmgr.exe utility.
If you are using a serial terminal for a graphics head: connect a
PC or Mac to the serial line (via a null modem and your choice of
terminal emulation software), and use the srlmgr.exe utility.
The swxcrmgr software expects a graphic head and runs ~200-1,000%
slower on a serial head. The srlmgr utility was designed for
use with serial heads and works well in this mode, but still expects
a PC style keyboard.
So, now you are thinking to yourself: OK, I have the firmware CD
(we'll use the v3.5 CD as an example), but how do I run a program
off of it from the SRM console? Here is how we run srlmgr on our
8400 (which has no grphics head):
1. Halt the system down to the SRM Console (">>>" prompt).
2. Do a "sho dev" to figure out the device name of your
CD-ROM drive, i.e. DKd500.
3. Load support for iso9660 file systems (if your SRM console
can't do this, you are going to have to make a floppy).
>>> load -f iso9660
4. List the directory, to make sure you are in the right place....
>>> ls iso9660:[CDROM.UTILITY]/DKd500
>>> ls iso9660:[CDROM.UTILITY.SWXCRMGR]/DKd500
. . .
ad nausium....
5. Run the srlmgr. (The -p1, tells it to look for the controllers
on the first PCI bus.)
>>> run iso9660:[CDROM.UTILITY.SWXCRMGR]SRLMGR.EXE -d DKd500 -p1
NOTE: The drive name in the form "DKd500" IS case sensitive and it
will cause commands to fail if you mess up the case on the drive
name.
If you need to make floppies, you can copy the utilites to a FAT
formatted disk using mtools or a PC with a CDROM drive.
----- snip ----- snip ----- snip ----- snip ----- snip -----
And here is the body of my posting on dual booting AS255's:
----- snip ----- snip ----- snip ----- snip ----- snip -----
Background:
We recently purchased a number of AlphaStation 255's after having a
demo AlphaStation 250 placed with us. The AlphaStation 250 was
designed to easily boot between Digital UNIX/OpenVMS and Windows NT,
having sufficient NVRAM installed to hold both the SRM console and the
ARC console.
After purchasing our AS255s, we discovered that they were equipped with
sufficient NVRAM to hold either the SRM console firmware OR the ARC
console firmware. I later discovered that this was true of
AlphaStation 200s as well.
Before the appearance of the V3.7 firmware CD, the only way to switch
firmware was to re-flash the NVRAM to the desired type. The V3.7
firmware CD provided firmware images that could be booted from the CD
which would boot the ARC console without re-flashing the NVRAM. Please
refer to the firmware documentation to find the correct files.
This got us half way home, because it allowed us to stop re-flashing
the NVRAM and just leave the SRM console installed (the systems run DU
80%+ of the time). The downside was that it required the operator to
have a copy of the firmware CD on hand and remember the right boot
image to load from the CD.
Solutions:
We arrived at two different, but complementary, solutions for
simplifying the dual boot process and enabling us to keep the physical
count of firmware CDs to a minimum.
1. We configured a number of the AS255s as bootp/tftp servers. These
systems provide the ARC console boot file, abboot.exe or arcboot.exe
depending on your hardware, from the firmware CD as the boot file.
It was unclear in the firmware documentation if this file was
bootable via bootp, but it does work. The user then issues a
"b ewa0" from the SRM console to boot the ARC console. Any bootp/tftp
capable host on the subnet should be able to serve as a boot host.
NOTE: The *.sys version of these files are MOP bootable if you have
VMS or ULTRIX boxes which can act as boot hosts.
2. The second solution was to use Kevin Mocklin's
(mocklin_at_frodo.eng.pko.dec.com) mkbootfirm, under Digital UNIX, to
write a bootable image of the abboot.exe file onto a 1.44mb floppy
(this also works with the arcboot.exe file used for AS200s). Then
when the user needs to boot the ARC console, they just need to place
the floppy in the drive and issue a "b dva0" from the SRM console.
Keven's mkbootfirm utility is available from:
ftp://ftp.digital.com/pub/Digital/Alpha/firmware/utilities/mkbootfirm.tar
The bootp/tftp implementation is faster, but can be problematic for a
number of reasons: (a) if RIS operating system upgrades are being made
available to the system, (b) the network or the boot host(s) are down,
(c) nobody is willing, or able, to provide bootp or bootpgw services on
the desired subnet. Because of this, the floppy, while slower, is a
complementary solution. It has the advantage of not having to rely on
other hosts and the network.
We had hoped to be able to find a quick and easy method of writing the
ARC console booter to a small 'a' partition on some of our three disk
systems, but that answer had eluded us thus far. That would provide
better speed than the bootp/tftp solution, without reliance on the
network and boot hosts.
Outstanding issues:
The only problem that we still have outstanding has to do with clocks:
DU and WinNT seem to have very different ideas about what the current
date is (about a 30 year discrepancy). It appears that one or both OSs
are using an offset from the system hardware clock. Attempting to
reconcile the dates has thus far failed (usually resulting in DU
deciding that the date is invalid and resetting it). Any thoughts or
suggestions would be appreciated.
----- snip ----- snip ----- snip ----- snip ----- snip -----
I hope this all helps,
Tom
--
+--------------------------------+------------------------------+
| Tom Webster | "Funny, I've never seen it |
| SysAdmin MDA-SSD ISS-IS-HB-S&O | do THAT before...." |
| webster_at_ssdpdc.mdc.com | - Any user support person |
+--------------------------------+------------------------------+
| Unless clearly stated otherwise, all opinions are my own. |
+---------------------------------------------------------------+
Received on Mon Jan 20 1997 - 14:17:45 NZDT