[comp.unix.ultrix] Getting back an Overwritten config file

jrr@lanl.gov (John R. Red-horse) (07/11/90)

Hello Netlanders,
I am a novice (and reluctant) system manager for a small Ultrix LAN
consisting of four diskless VAXxtation 3100's being served by a
VAXstation 3200 boot node and a DECstation 5400.  Each of these systems
is running version 3.1 Ultrix and the VAXstations run UWS 2.2 as well.
I ran into a peculiar, though self-induced problem that I am hopeful
can be recovered from in some reasonable fashion.  Specifically,
while adding disks to each of the machines, I noticed that I was going
to have to modify the config file via the utility ``doconfig'' and rebuild
my kernel.  Silly me, I asked to have the existing file overwritten when
queried by doconfig (the question doesn't say *WHEN* the overwriting gets
done) and, quite simply, the config files that I had built originally,
through the automated build procedure on the install tapes are gone (sigh).

Is there a sane way to do this again without going through the install
again from scratch?  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.

Thanks to all in advance.
Cheers,


John Red-Horse                           INTERnet:JRRedho@sandia.gov
Org 1524(Engineering Analysis Div)
Sandia National Laboratories
Albuquerque, NM   87185-5800    Bell:	(505) 846-6115

alan@shodha.dec.com ( Alan's Home for Wayward Notes File.) (07/15/90)

In article <56677@lanl.gov>, jrr@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@sandia.gov
> Org 1524(Engineering Analysis Div)
> Sandia National Laboratories
> Albuquerque, NM   87185-5800    Bell:	(505) 846-6115


-- 
Alan Rollow				alan@nabeth.enet.dec.com

grr@cbmvax.commodore.com (George Robbins) (07/15/90)

In article <56677@lanl.gov> jrr@lanl.gov (John R. Red-horse) writes:
> Hello Netlanders,
> I ran into a peculiar, though self-induced problem that I am hopeful
> can be recovered from in some reasonable fashion.  Specifically,
> while adding disks to each of the machines, I noticed that I was going
> to have to modify the config file via the utility ``doconfig'' and rebuild
> my kernel.

See the man entry for doconfig(8).  There is no reason you can't run it
again and regenerate the configuration files.  The trick seem to be that
you have to be running "genvmunix", since what it does is scan through
all the myriad devices defined in this kernel and echo back those that
autoconfig actually found when the kernel was booted.

> Is there a sane way to do this again without going through the install
> again from scratch?  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 can also probably start the installation and abort it part way, but
you have to be very careful about this, especially if you don't know/
remember the flow of events.

It should alo be mentioned that occasional backups of *all* the disks,
including the "system areas", help prevent this sort of embarressment.

-- 
George Robbins - now working for,     uucp:   {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing:   domain: grr@cbmvax.commodore.com
Commodore, Engineering Department     phone:  215-431-9349 (only by moonlite)