I have a strange problem.
GS140 with DUNIX V4.0E + PK2. We have a 5 tape devices. A DAT and 4 x
TZ89's in a TL894 silo.
The tape device special file names (rmt0, rmt1 etc). Do not match the bus
ordering (bus, target and LUN). This is annoying but not a real problem.
We cannot change the rmt* file names as various applications, scripts etc
expect to see them in their existing order.
Now all this is fine. Pre V4.0E, if you rebooted the box, if the tape
device special files existed, they WERE NOT recreated. They were only
created if a physical device existed that DID NOT have a device special
file. ie., if you added a new device, the next rmt number would be used by
default.
The 4.0e upgrade release notes (we upgraded from v4.0d some months ago) did
say that tape device special files would be deleted and recreated in bus,
target and LUN order, and that if you wanted them in a different order, you
should delete and recreate following the upgrade. This we did and all was
fine with the world.
However, when we reboot the box now (V4.0e + PK2) it seems to ALWAYS delete
the tape device special file names and recreate them in the default order.
The /dev/MAKEDEV.log file matches the date and time of the last reboot and
shows these things being recreated.
Is this an intentional change of behaviour and is it documented anywhere? If
it is, does anybody have a way around the problem (apart from the obvious of
putting a script in /sbin/init.d and a link to /sbin/rc3.d/S??tapefilenames
to delete them and recreate them in the desired order).
Tony
Quotation: "Is the glass half full or half empty?? ...
Well, drink it anyhow, that's what I say".
Pete Goss.
+-----------------------------------------------------------------+
| TONY MILLER - Systems Projects - VODAFONE LTD, Derby House, |
| Newbury Business Park, Newbury, Berkshire. |
+-------------+---------------------------------------------------+
| Phone | 01635-507687(local) |
| Work email | ANTHONY.MILLER_at_VF.VODAFONE.CO.UK |
| FAX | 01635-233517 |
+-------------+---------------------------------------------------+
Disclaimer: Opinions expressed in this mail are my own and do not
reflect the company view unless explicitly stated. The information
is provided on an 'as is' basis and no responsibility is accepted for
any system damage howsoever caused.
Received on Fri Nov 05 1999 - 14:40:43 NZDT