- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Hardcode SCSI ids in 11.0 via the O/S ?
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-16-2001 06:16 AM
08-16-2001 06:16 AM
Hardcode SCSI ids in 11.0 via the O/S ?
I have a couple of scsi tape drives (lets say a DDS and a DLT) connected to my N-class running 11.0 . Is there any way of setting the scsi ids of these drives in the O/S so that the DLT will always get a specific ID and the DDS will always get another specific one?
Usually this is do-able via dip switches etc - but I'm looking for a software method, if there is one?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-16-2001 06:21 AM
08-16-2001 06:21 AM
Re: Hardcode SCSI ids in 11.0 via the O/S ?
That dog won't hunt. The SCSI ID's are a function of the device itself and not the OS.
A few SCSI devices have software configurable
SCSI ID's but that is the exception rather than the rule.
Clay
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-16-2001 06:27 AM
08-16-2001 06:27 AM
Re: Hardcode SCSI ids in 11.0 via the O/S ?
Perchance do you mean instance numbers? If so, then you can reassign them, as for instance (no pun) if you want the DDS drive to be instance zero and the DLT to be at instance one.
Regards!
...JRF...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-16-2001 06:42 AM
08-16-2001 06:42 AM
Re: Hardcode SCSI ids in 11.0 via the O/S ?
tape 1 0/0/1/0.2.0 stape CLAIMED DEVICE dlt-device
/dev/rmt/1m /dev/rmt/c0t2d0BEST
tape 0 0/0/1/0.3.0 stape CLAIMED DEVICE dds-device
/dev/rmt/0m /dev/rmt/c0t3d0BESTn
This might make it clearer : in the situation above, I always want my dlt-device to use the /dev/rmt/1m device, and the dds to use 0m. So, lets say my dds drive fails and I replace it with a new one with the same SCSI ID, will the new one appear as 0m ? If I change the SCSI ID to 1 lets say, will the dds now appear as 1m (given that it'll now be the second tape device to be probed on that bus)?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-16-2001 06:52 AM
08-16-2001 06:52 AM
Re: Hardcode SCSI ids in 11.0 via the O/S ?
eg.
ln /dev/rmt/1m /dev/tapedds
ln /dev/rmt/0m /dev/tapedlt
That way I have a consistent name in all my backup scripts.
-- Rod Hills
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-16-2001 06:53 AM
08-16-2001 06:53 AM
Re: Hardcode SCSI ids in 11.0 via the O/S ?
I thought so. First, yes, the instance numbers are reflected in the device files. Thus, the tape at instance number zero has a device file /dev/rmt/0m.
If you merely replace a tape drive, because it died, then the instance number will not change. The problem of changing instance numbers is generally encountered in cold-installations where the hardware is scanned for the "first" time and instance numbers are generated in the order in which devices on buses are seen.
...JRF...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-16-2001 07:09 AM
08-16-2001 07:09 AM
Re: Hardcode SCSI ids in 11.0 via the O/S ?
Here the answer is a qualified no and sorry Rodney's approach is not bulletproof either.
The instance (the cX part of /dev/rmt/cXtYdZ...) number is determined by the order in which the hardware is 'discovered'.
If all the cards are installed in a machine, every time an OS is installed c0 remains c0, c1 remains c1, ...; however, if you started with a machine and added some cards and THEN reload the OS from scratch what was c1 MAY now be c3.
The 0m, 1m, 2m ... devices are simply shorthand
for the longer versions of the device nodes.
0m -> c0t2d0BEST, 1m ->c0t4d0BEST, 2m ->c2t3d0BEST and are for the benefit of use humans. The only thing that the machine cares about are the major and minor device numbers and that is the key.
After you determine which devive node is the one you really want by looking at the cXtYdZ stuff you simply create a new device node with the same major and minor device numbers.
e.g. lets say that you do a ls -l of /dev/rmt/c2t0d0BEST
crw-rw-rw- 2 bin 205 0x020000 Nov 12 c2t0d0BEST
Let's now make that /dev/dlttape
mknod /dev/dlttape c 205 0x020000
chmod 666 /dev/dlttape
You are now done. The bad news is that the only absolutely assured way to do this is after the fact.
Hope this helps, Clay
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-16-2001 07:29 AM
08-16-2001 07:29 AM
Re: Hardcode SCSI ids in 11.0 via the O/S ?
Jason
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-16-2001 07:48 AM
08-16-2001 07:48 AM
Re: Hardcode SCSI ids in 11.0 via the O/S ?
But the question now is what determines the order of discovery of devices? Is it:
- scsi id?
- fastest device to respond to a probe?
- first device on the scsi chain after the controller?
- which ever way the wind is blowing?
(thanks all for your responses so far BTW)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-16-2001 07:55 AM
08-16-2001 07:55 AM
Re: Hardcode SCSI ids in 11.0 via the O/S ?
To my knowledge the order is the hardware path as see by 'ioscan'.
...JRF...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-16-2001 08:03 AM
08-16-2001 08:03 AM
Re: Hardcode SCSI ids in 11.0 via the O/S ?
It's definitely determined by the hardware device path and to that extent it is predictable. Again, as long as no hardware is added or deleted (or moved from one slot to another) the discovery order and thus the instance numbers remain the same.
Clay
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-16-2001 08:18 AM
08-16-2001 08:18 AM
Re: Hardcode SCSI ids in 11.0 via the O/S ?
212 0x001000 Jul 28 2000 0m
212 0x020000 Jul 6 2000 1m
If you remember the Major/Minor numbers for your DDS or DLT device, you can rename them to what you want. Or use mknod to create one.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-16-2001 11:11 AM
08-16-2001 11:11 AM
Re: Hardcode SCSI ids in 11.0 via the O/S ?
However, the KSC is also the highest number in the backplane, but it is still the only card so instance numbers start at 0 for each driver. So far so good--but computers change and sysadmins add more stuff (to lower-numbered bus slots) and these new items will be scanned and added when the system reboots. Instance 0 is taken already so the new card(s) will start at instance 1. Still so far so good.
But let's cold install...if all those new cards and devices are left connected, then insf will see the lowest cards first and the KSC last. Now the KSC instance numbers are no longer 0. The system works fine but as mentioned, backup scripts or other files taken from the old environment will not match. LAN cards are similar. The lan0 device is the KSC when first installed but add a few additional LAN cards and cold install--the built-in LAN on the KSC is now lan3 or lan7...
So to control the creation order, you must disconnect devices that have been added since the original installation (that would cause a reordering of instance numbers). Then add the new cards in the order desired and reboot each time.
There is also a technique that can be used to reorder devices using ioinit but requires the standard BigBoy/BigGirl Policy statement:
"This technique will be changing the I/O config used by the kernel at bootup and mistakes (specifically to do with disk hardware) can render the system unusable and require the use of a recovery CDROM or a complete reinstall. A backup kernel will not fix I/O config file problems."
The technique is to change the file called /etc/ioconfig by using the ioinit command. Let's suppose we want to change the tape drive at 56/52.3.0 from instance 3 to instance 0, and change 56/52.1.0 from 0 to 3, thus swapping the instance numbers. Here are the steps:
# rmsf -vH 56/52.1.0
# rmsf -vH 56/52.3.0
Check the /dev/rmt diretory:
# ls /dev/rmt/
The device files for address 1 and 3 should be gone. Ignore any message from rmsf about trying to remove the driver (it can't do that anyway). Save a copy of the old ioconfig file:
# cp /etc/ioconfig /etc/ioconfig.old
Now create a file which assigns the desired instances, something like this:
56/52.1.0 tape 3
56/52.3.0 tape 0
The format is: hardware-path class instance
which can be found in the ioinit man page. This file should have all the changes you want to make. Now run ioinit to make the changes:
# ioinit -f /tmp/xx
where /tmp/xx is the file created above. If all is well, there will be no output. Run the same command again and it should report that the changes are already in place.
Now reboot. When the system comes back up, run the command:
# ioscan -knfC tape
and if no device files are shown, run the commands:
# insf -e -H 56/52.1.0
# insf -e -H 56/52.3.0
then run ioscan again. This should fix your instance numbers and device file names.
Bill Hassell, sysadmin