| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 867.1 | Workaround not acceptable | NETRIX::"[email protected]" | Nancy Flavell | Fri Feb 21 1997 01:28 | 16 |
| The customer spoke with their Engineers who said that the reason they
sometimes need to boot genvmunix is that the system becomes basically
unusable. Thus, the previously mentioned workaround is not feasible,
unless they first boot to single-user mode.
So, I'm left with wondering how to make an automatic check on system
boot so that X.25 will not be started unless support is there.
We considered applying a check similar to what LAT does, where it
uses sysconfig -s to see whether dlb is built into the kernel.
However, would there be something statically available to grep for,
like x25_access, or does X.25 dynamically add support?
Nancy
[Posted by WWW Notes gateway]
|
| 867.2 | | DELNI::MUGGERIDGE | | Fri Feb 21 1997 02:32 | 26 |
| I am not aware of any requirement to have X.25 be aware of when genvmunix is booting
and taking appropriate action if it is not configured.
In the spirit of genvmunix, it should contain the 'maximum' system configuration. If
you take a look at the config file it describes all manner of devices which it will attemp
to detect. If it finds a device, then it is configured.
So continuing with the spirit of genvmunix, it would make some sense to configure X25
into that file as well.
However, if you absolutely must not have X.25 starting when genvmunix boots, then
one way you could do this is by creating a file in /sbin/rc3.d (or maybe rc2.d)
with a name like S28.00_NoX25. Then this could detect which kenel is booting
and move the X.25 startup scripts. e.g. maybe something like:
create directory /sbin/rc3.d/tmp if it doesn't already exist
if genvmunix then mv S28.[1-9]* /sbin/rc3.d/tmp
else if vmunix then mv /sbin/rc3.d/tmp/* /sbin/rc3.d
You may run into problems with the way these scripts are invoked. I don't know if
by the time rc3.d scripts are run, that moving them will result in problems. If this
is the case, you can try this script in rc2.d.
Good luck.
Matt.
|
| 867.3 | rfc1006 the real culprit | NETRIX::"[email protected]" | Nancy Flavell | Wed Feb 26 1997 01:51 | 20 |
| Matt,
In implementing your recommended workaround, the customer realized
that, even though there were lots of X.25 errors spewing across the
screen, it was actually the rfc1006 starting up directly afterward
which caused the system to panic. Applying the same workaround to
the rfc1006 startup took care of the problem.
They are upgrading to the OSI 3.2b product this weekend and will
test to see whether the system still panics when rfc1006 tries to
start under the generic kernel.
The customer wanted to thank you for your time and to let you
know that it was not the X.25 starting up which caused the
problem.
I extend my gratitide, as well.
Nancy
[Posted by WWW Notes gateway]
|