Getting back an Overwritten config file
Alan's Home for Wayward Notes File.
alan at shodha.dec.com
Sun Jul 15 14:58:38 AEST 1990
In article <56677 at lanl.gov>, jrr at lanl.gov (John R. Red-horse) writes:
> Hello Netlanders,
>
> [ A description of how the user has overwritten his configuration
> files on various ULTRIX systems running V3.1 ].
First, do you have backups of the systems? Restoring
them from backup is much easier than regenerating them.
> Is there a sane way to do this again without going through the install
> again from scratch?
Doconfig(8) without any options uses the device list in the
running kernel to build what it belives is one the system.
It won't add DECnet, but that's easy (two lines). If the
current system doesn't know about some newly installed
device you can arrange for doconfig(8) to know about it.
You should have a file called /genvmunix leftover from the
installation. This kernel has close to everything built
into it. What you want to do is arrange for it be running
when you run /etc/doconfig.
[ NOTE: I don't have much experience with diskless systems
so this procedure may only be suitable for non-diskless
systems. ]
1. Save your current kernel somewhere:
# cp /vmunix /vmunix.old
2. Arrange for /genvmunix to be the running kernel on
reboot:
# cp /genvmunix /vmunix
# shutdown -r now "Some reason"
3. Now you can run /etc/doconfig and it should find
all the supported devices that are on the system.
If you added any special device drivers that the
generic kernel doesn't know about you'll have to
do those over (the driver for the MD300 page scanner
for example).
4. Other extras like DECnet, the trace facility that
doconfig(8) doesn't know much about you'll also have
do by hand. DECnet support consists of two lines:
options DECNET
pseudo-device decnet
5. Read the Guide to System Configuration File Maintainence
for more about what is in the configuration file.
> Assuming that I do have to do the install, do I lose
> all the stuff that is currently configured and running on the systems
> (e.g., DECnet, nfs, etc.)? Do not mistake the overall tone of this
> note as that of a calm man---I am desperate, I need help.
You should never have to re-install a system just to get
back a configuration file. If all else fails you can
hack stuff out of the GENERIC configuration file to
get back to something useful. I think there also example
configuration files for diskless systems laying around
somewhere (or in the DMS documentation).
If you expect to add other devices over time it might be a
good idea to put them in the configuration file now. Except
for whole device drivers extra devices don't take up that
much extra space. For example on a DECsystem 5400 that has
two KDA50s you can as many as eight RA type disks. Go ahead
and put entries for all eight:
controller uda0 at uba?
controller uda1 at uba?
controller uq0 at uda0 csr 0172150 vector uqintr
controller uq1 at uda1 csr 0160334 vector uqintr
#
disk ra0 at mscp drive 0
disk ra1 at mscp drive 1
disk ra2 at mscp drive 2
disk ra3 at mscp drive 3
disk ra4 at mscp drive 4
disk ra5 at mscp drive 5
disk ra6 at mscp drive 6
disk ra7 at mscp drive 7
Please note one of the features that I make use of. Ordinarily
the configuration file would have one of uq0 or uq1 for the
"disk rax at blah". If you use unique unit numbers you can
use "mscp" to tell ULTRIX to figure out which disk is on
which controller. Since two KDA50s can support eight disks
you can setup the kernel to eventually recognize eight disks
as long each one has a unique unit number and is one of those
listed.
Using "wildcards" like this depends on the drivers. Look at
the GENERIC configuration file for more examples of how the
other devices drivers do it (or don't).
In the case of "mscp" for DSA disks (and tapes, but I won't
discuss those) as long as the unit numbers are unique you
can use this for any DSA disk on the appropriate controller:
RDxx on the RQDX{1,2,3}
RAxx on the HSC, KDB50, KDA50, UDA50.
RFxx on a DSSI adapter or KFQSA.
For disks and controllers like the RDxx/RQDX# that don't
allow setting unit numbers this gets harder, but you can
still do a little.
>
> Thanks to all in advance.
> Cheers,
>
>
> John Red-Horse INTERnet:JRRedho at sandia.gov
> Org 1524(Engineering Analysis Div)
> Sandia National Laboratories
> Albuquerque, NM 87185-5800 Bell: (505) 846-6115
--
Alan Rollow alan at nabeth.enet.dec.com
More information about the Comp.unix.ultrix
mailing list