[SUMMARY] Tru64 V4.0G upgrade rebuilds magtape device special files?

From: <ruhnke_at_us.ibm.com>
Date: Wed, 06 Sep 2000 07:53:53 -0500

Once again the ever reliable Dr. Tom Blinn comes through with the answer:

It's a side effect of the update, perhaps more precisely a side effect
of the kernel rebuild that's part of the update. And it's not new, it
has worked this way for a LONG time.

He also reminds us of the changes imposed by Tru64 V5.0x:

For folks like you who have a particular ordering they want to see for
the "rmt" names (based on the current V4.0x behavior, in V5.x things
are quite different but usually your device names will be preserved).

So it looks like I will be OK until my next upgrade.

--CHRis

Chris H. Ruhnke
Mid-Range Technical Services
IBM Global Services
St. Louis, MO

Office: (314) 233-7314
Pager: (800) 759-8888 PIN 8714690


O'Toole's Law: Murphy is an optimist.


Original message:

> Friends:
>
> After upgrading from DU V4.0D to Tru64 V4.0G this past weekend I ran into
> problems with
> NSR V5.2 not seeing the drives in the Jukebox. I tracked the problem
down
> to the fact that
> the /dev/*mt* special files had been recreated apparently by scanning the
> SCSI busses in
> sequential order.
>
> I "fixed" the problem by deleting the /dev/*mt* files and re-running
> MAKEDEV for each of
> my tapes in the order I wanted them.
>
> 1) This is a heads-up for those of you who, like me, have magtape device
> files that are NOT
> in SCSI bus order -- my tz17 is *mt0*, tz28 is *mt1* and tz2, tz3, tz12
and
> tz13 (the Jukebox tapes)
> are *mt2*, *mt3*, *mt4* and *mt5* respectively. The upgrade named them
> *mt4*, *mt5*, *mt0*,
> *mt1*, *mt2* and *mt3*.
>
> 2) Does anyone know if this was just a result of the upgrade or does this
> happen at boot time?
> I'd sure hate to have to add a script to the startup sequence to re-MAKE
my
> tape devices
> after each boot.
Received on Wed Sep 06 2000 - 12:55:03 NZST

This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:41 NZDT