rchrd@well.UUCP (Richard Friedman) (07/18/89)
Due to a unending series of hardware problems that resulted in the
hard disk on my stand alone DN3000 being replaced twice, I have had
to install and re-install SR10.1 over 4 times in the past two weeks!
Anyone who has had to do this installation (from cartridge tapes) only
once knows of what intrepedations I speak. Now, while my DN3000 is at
the Apollo shop, I have time to reflect on the deficiences of the
SR10 installation procedure and give some recommendations, if anyone
at Apollo is there to listen.. These comments are particularly targetted
at the single, stand alone system.
1. There needs to be a load/install option for the stand alone
system. In particular, there should be a clean-up procedure that
deletes unneeded parts of the software from the disk. Also, the
installation procedure could be smarter and not bother to load unneeded
system files. I have noticed that even tho only one SAU option is
selected, MINST loads all the SAU directories into the AA. Why?
Information about the parts of the system the user does not want
(such as /usr/games, /usr/new, domain_examples, unneeded manual pages, etc.)
should be requested at the start and skipped from the load process as well
as the install.
2. Documentation of the load/install is terrible! The "Installing
Software" manual should have been re-issued with corrections rather than
having the corrections in the release notes. In the end, the messages that
come out of MINST and INSTALL++ during installation don't correspond to
anything in either document. This adds great anxiety when you are
2 hours into the installation and a question comes up that you don't know
how to answer. The documentation should be clearer on what happens when
you answer questions on the screen. All answers should be mentioned.
3. Once the system is installed, there should be a backup procedure that
will transfer the system, with a boot record, to a backup medium, like
cartridge tape, so that should the disk have to be INVOL'd later on we
can re-load the system without having to go thru the whole load/install
procedure again! This seems simple enough to do. A system backup builder
can look around to see what is installed on the disk, prepare a
bootable tape in whatever structure it needs, and write the tape(s).
Later, after an INVOL, a RELOAD from the monitor shell should be able to
put everything back and setup for a boot back to DOMAIN_OS. Were this
system backup/reload available I could have saved at least 25 hours of
real agony!
4. Finally, I have noticed that the load procedure at times will
retension a cartridge tape twice! Retensioning should be a y/n option
from the console and be global: "Should load volumes be retensioned
before being read [y/n]" If this is the second re-install today, I really
don't think I have to retension and would like to skip it.
Lets hope SR10.2 looks better. And don't forget about us stand alone
sites, please!
--
...Richard Friedman rchrd@well.uucp
(Pacific-Sierra Research/Berkeley, CA.)
also: {lll-crg,pacbell,hplabs}!well!rchrdflinn@apollo.COM (Donald Flinn) (07/20/89)
In article <12735@well.UUCP> rchrd@well.UUCP (Richard Friedman) writes: > >1. There needs to be a load/install option for the stand alone >system. In particular, there should be a clean-up procedure that >deletes unneeded parts of the software from the disk. Also, the >installation procedure could be smarter and not bother to load unneeded >system files. I have noticed that even tho only one SAU option is >selected, MINST loads all the SAU directories into the AA. Why? >Information about the parts of the system the user does not want >(such as /usr/games, /usr/new, domain_examples, unneeded manual pages, etc.) >should be requested at the start and skipped from the load process as well >as the install. > >2. Documentation of the load/install is terrible! The "Installing >Software" manual should have been re-issued with corrections rather than >having the corrections in the release notes. In the end, the messages that >come out of MINST and INSTALL++ during installation don't correspond to >anything in either document. This adds great anxiety when you are >2 hours into the installation and a question comes up that you don't know >how to answer. The documentation should be clearer on what happens when >you answer questions on the screen. All answers should be mentioned. > >3. Once the system is installed, there should be a backup procedure that >will transfer the system, with a boot record, to a backup medium, like >cartridge tape, so that should the disk have to be INVOL'd later on we >can re-load the system without having to go thru the whole load/install >procedure again! This seems simple enough to do. A system backup builder >can look around to see what is installed on the disk, prepare a >bootable tape in whatever structure it needs, and write the tape(s). >Later, after an INVOL, a RELOAD from the monitor shell should be able to >put everything back and setup for a boot back to DOMAIN_OS. Were this >system backup/reload available I could have saved at least 25 hours of >real agony! > >4. Finally, I have noticed that the load procedure at times will >retension a cartridge tape twice! Retensioning should be a y/n option >from the console and be global: "Should load volumes be retensioned >before being read [y/n]" If this is the second re-install today, I really >don't think I have to retension and would like to skip it. > >Lets hope SR10.2 looks better. And don't forget about us stand alone >sites, please! > >-- > ...Richard Friedman rchrd@well.uucp > (Pacific-Sierra Research/Berkeley, CA.) > also: {lll-crg,pacbell,hplabs}!well!rchrd Richard Thanks for your comments. We are trying to make RAI easy to use as well as give the flexibility that our different customer need or desire. This is an ungoing task. We welcome comments, suggestions and constructive criticism. As to your specific comments - 1. distaa is the program that handles loading the AA from media. It uses a script driver file which allows you to select parts of a product to load into the AA. You can generate one of these file using cfgsa (see the install manual on using cfgsa). cfgsa's output is a selection file and an override file. The selection file is the one that drives distaa. The override file restricts what you can pick during config and subsequent installs. This stops you from picking and/or trying to install a subproduct that you did not load into the AA (the overrides file and the selection files are paired.) In order to use cfgsa first rbak file 1 from the tape to get the release index for that product. Then run distaa using the selection file that you have generated. In this manner the AA will only contain those subproducts that you have choosen. ( The templates that we supply are built with cfgsa.) If you only choose one sau in the cfgsa session, only one sau will be loaded into the AA. Likewise, if you don't choose /usr/games you will not get /usr/games in the AA. 2. Documentation is being rewritten. 3. Save your selection and override files to a tape. Next boot from your boot tape to get your node up and running with the boot software. Restore the selection and override files. Run distaa with the restored selection file and the -l switch. This is equivalent to a reload. 4. We are following the cartridge tape manufactuer rules which say that you must retension the tape each time you use it.
rchrd@well.UUCP (Richard Friedman) (07/21/89)
Its quite obvious that the team at apollo that put together the
installation tools did not actually attempt to do an OS install of
10.1 on a stand alone node. I think the documentation is an educated
guess by the writers as to what should work. For a stand alone node,
there is really no reason whey load and install should be different
phases of the process. There should be a MINST question: Is this a
stand-alone node? A yes response gets you into a combined load/install
dialog that lets you specify what parts of the system you want, etc.
and does the load directly into the system rather than creating an
/install area and then creating redundant links to it to create the
real system. The poor user, who has little time to completely
understand the implications of the install procedure (which is
not documented to begin with) suffers the anxiety of not knowing
the complete ramifications of all the install options.
We rely on apollo providing simple canned routines like MINST and
INSTALL.
THe stand-alone system does not have a partner node to suck off
critical files. Once a stand alone disk is INVOL'd there is nothing
but the system installation boot tape. This tape has nothing real
on it and is to be used only to load in the system. It doesnt even
have a complete set of diagnostics in the sysboot record, so once
you do an invol you cant do a disk test or cpu tes (win.dex or cpu.dex)
until AFTER you have successfully installed the system (which takes 3 hours!).
There are other problems, like what to do when there is some sort of
failure during the install process... how can you reliably recover or
restart without having to go all the way back to invol the disk!
I am talking about OS installations, not optional products...
There should be a simple procedure, as I mentioned earlier, for saving
the system, not just a simple way to reinstall from the install media.
I want to backup the system on my own tapes, preserving my own
customizations, invol the disk, and reload in a simple way that requires
minimal operator interventions. Why cant I do this??
Apollo needs to work more on the installation process.
In the meantime, I'd like to find out how many stand alone nodes are
out there and what their experiences are regarding sr10 installs.
For that, watch this space.
--
...Richard Friedman rchrd@well.uucp
(Pacific-Sierra Research/Berkeley, CA.)
also: {lll-crg,pacbell,hplabs}!well!rchrd