Hi,
This was a bit of a head scratcher for us, and DEC tech support wasn't
much help so, I thought I might share our solution(s) with the list.
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.
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 Wed Dec 18 1996 - 03:55:24 NZDT