This chapter provides information on the settings and files that need to be set and edited to customize your system for use. It is not necessary to change all listed settings and names on all systems. You are free to customize your systems as much or as little as necessary to suit your purposes. The following topics are covered in this chapter.
“System Configuration Check” provides information on determining what hardware and software are installed and active, and reporting the current system software settings.
“Configuring Software” provides information on making changes to basic system settings and options.
“Partitioning Your System” describes how to divide an SGI 3000 Series system into multiple distinct systems.
The IRIX system provides two commands that allow you to check your system hardware and software configurations. The hinv(1M) and versions(1M) commands display the hardware and software inventories, respectively. Other commands report on graphics hardware, the system name, configured printers, and basic system settings.
The hinv command displays the system's hardware inventory table, which is created at boot time. This command can be run from the command monitor (PROM) or from your system shell prompt. Pertinent information such as the processor type, amount of main memory, and all disks, tape drives, and other devices is included.
Example 4-1 shows hinv output from the IRIX shell prompt. For more information, see “Checking Installed Hardware in /hw” and the hwgraph(4D)man page.
With the -v and -m options, hinv produces verbose output including board name, part number, barcode number, and the physical location of each board as a path under /hw. % hinv -vm |
Location: /hw/module/001c10/node
IP35 Board: barcode KHD544 part 030-1604-001 rev -G
Location: /hw/module/001c10/Ibrick/xtalk/14
IBRICK Board: barcode KJX216 part 030-1557-002 rev -F
Location: /hw/module/001c10/Ibrick/xtalk/15
IBRICK Board: barcode KJX216 part 030-1557-002 rev -F
Location: /hw/module/001c10/Ibrick/xtalk/15/pci/4
[missing info: Not present on interface] Laser unreadable
Location: /hw/module/001c13/node
IP35 Board: barcode KHD546 part 030-1604-001 rev -G
Location: /hw/module/001c13/Xbrick/xtalk/14
XBRICK Board: barcode KHP021 part 030-1565-001 rev -K
Location: /hw/module/001c13/Xbrick/xtalk/15
XBRICK Board: barcode KHP021 part 030-1565-001 rev -K
Location: /hw/module/001c16/node
IP35 Board: barcode KHD136 part 030-1604-001 rev -F
Location: /hw/module/001c21/node
IP35 Board: barcode KHD152 part 030-1604-001 rev -G
Location: /hw/module/001c24/node
IP35 Board: barcode KHD106 part 030-1604-001 rev -G
Location: /hw/module/001c29/node
IP35 Board: barcode KHD079 part 030-1604-001 rev -G
Location: /hw/module/001c32/node
IP35 Board: barcode KHD135 part 030-1604-001 rev -G
Location: /hw/module/001c35/node
IP35 Board: barcode KHD191 part 030-1604-001 rev -G
Location: /hw/module/001r19/router
ROUTER Board: barcode KRE126 part 030-1596-001 rev -F
Location: /hw/module/001r27/router
ROUTER Board: barcode KRE084 part 030-1596-001 rev -F
32 400 MHZ IP35 Processors
CPU: MIPS R12000 Processor Chip Revision: 3.5
FPU: MIPS R12010 Floating Point Chip Revision: 0.0
CPU 0 at Module 001c10/Slot 0/Slice A: 400 Mhz MIPS R12000 Processor Chip (enabled)
Processor revision: 3.5. Secondary cache: Size 8 MB Speed 266 Mhz
CPU 1 at Module 001c10/Slot 0/Slice B: 400 Mhz MIPS R12000 Processor Chip (enabled)
Processor revision: 3.5. Secondary cache: Size 8 MB Speed 266 Mhz
CPU 2 at Module 001c10/Slot 0/Slice C: 400 Mhz MIPS R12000 Processor Chip (enabled)
Processor revision: 3.5. Secondary cache: Size 8 MB Speed 266 Mhz
CPU 3 at Module 001c10/Slot 0/Slice D: 400 Mhz MIPS R12000 Processor Chip (enabled)
Processor revision: 3.5. Secondary cache: Size 8 MB Speed 266 Mhz
CPU 4 at Module 001c13/Slot 0/Slice A: 400 Mhz MIPS R12000 Processor Chip (enabled)
Processor revision: 3.5. Secondary cache: Size 8 MB Speed 266 Mhz
CPU 5 at Module 001c13/Slot 0/Slice B: 400 Mhz MIPS R12000 Processor Chip (enabled)
Processor revision: 3.5. Secondary cache: Size 8 MB Speed 266 Mhz
CPU 6 at Module 001c13/Slot 0/Slice C: 400 Mhz MIPS R12000 Processor Chip (enabled)
Processor revision: 3.5. Secondary cache: Size 8 MB Speed 266 Mhz
CPU 7 at Module 001c13/Slot 0/Slice D: 400 Mhz MIPS R12000 Processor Chip (enabled)
Processor revision: 3.5. Secondary cache: Size 8 MB Speed 266 Mhz
CPU 8 at Module 001c16/Slot 0/Slice A: 400 Mhz MIPS R12000 Processor Chip (enabled)
Processor revision: 3.5. Secondary cache: Size 8 MB Speed 266 Mhz
CPU 9 at Module 001c16/Slot 0/Slice B: 400 Mhz MIPS R12000 Processor Chip (enabled)
Processor revision: 3.5. Secondary cache: Size 8 MB Speed 266 Mhz
CPU 10 at Module 001c16/Slot 0/Slice C: 400 Mhz MIPS R12000 Processor Chip (enabled)
Processor revision: 3.5. Secondary cache: Size 8 MB Speed 266 Mhz
CPU 11 at Module 001c16/Slot 0/Slice D: 400 Mhz MIPS R12000 Processor Chip (enabled)
Processor revision: 3.5. Secondary cache: Size 8 MB Speed 266 Mhz
CPU 12 at Module 001c21/Slot 0/Slice A: 400 Mhz MIPS R12000 Processor Chip (enabled)
Processor revision: 3.5. Secondary cache: Size 8 MB Speed 266 Mhz
CPU 13 at Module 001c21/Slot 0/Slice B: 400 Mhz MIPS R12000 Processor Chip (enabled)
Processor revision: 3.5. Secondary cache: Size 8 MB Speed 266 Mhz
CPU 14 at Module 001c21/Slot 0/Slice C: 400 Mhz MIPS R12000 Processor Chip (enabled)
Processor revision: 3.5. Secondary cache: Size 8 MB Speed 266 Mhz
CPU 15 at Module 001c21/Slot 0/Slice D: 400 Mhz MIPS R12000 Processor Chip (enabled)
Processor revision: 3.5. Secondary cache: Size 8 MB Speed 266 Mhz
CPU 16 at Module 001c24/Slot 0/Slice A: 400 Mhz MIPS R12000 Processor Chip (enabled)
Processor revision: 3.5. Secondary cache: Size 8 MB Speed 266 Mhz
CPU 17 at Module 001c24/Slot 0/Slice B: 400 Mhz MIPS R12000 Processor Chip (enabled)
Processor revision: 3.5. Secondary cache: Size 8 MB Speed 266 Mhz
CPU 18 at Module 001c24/Slot 0/Slice C: 400 Mhz MIPS R12000 Processor Chip (enabled)
Processor revision: 3.5. Secondary cache: Size 8 MB Speed 266 Mhz
CPU 19 at Module 001c24/Slot 0/Slice D: 400 Mhz MIPS R12000 Processor Chip (enabled)
Processor revision: 3.5. Secondary cache: Size 8 MB Speed 266 Mhz
CPU 20 at Module 001c29/Slot 0/Slice A: 400 Mhz MIPS R12000 Processor Chip (enabled)
Processor revision: 3.5. Secondary cache: Size 8 MB Speed 266 Mhz
CPU 21 at Module 001c29/Slot 0/Slice B: 400 Mhz MIPS R12000 Processor Chip (enabled)
Processor revision: 3.5. Secondary cache: Size 8 MB Speed 266 Mhz
CPU 22 at Module 001c29/Slot 0/Slice C: 400 Mhz MIPS R12000 Processor Chip (enabled)
Processor revision: 3.5. Secondary cache: Size 8 MB Speed 266 Mhz
CPU 23 at Module 001c29/Slot 0/Slice D: 400 Mhz MIPS R12000 Processor Chip (enabled)
Processor revision: 3.5. Secondary cache: Size 8 MB Speed 266 Mhz
CPU 24 at Module 001c32/Slot 0/Slice A: 400 Mhz MIPS R12000 Processor Chip (enabled)
Processor revision: 3.5. Secondary cache: Size 8 MB Speed 266 Mhz
CPU 25 at Module 001c32/Slot 0/Slice B: 400 Mhz MIPS R12000 Processor Chip (enabled)
Processor revision: 3.5. Secondary cache: Size 8 MB Speed 266 Mhz
CPU 26 at Module 001c32/Slot 0/Slice C: 400 Mhz MIPS R12000 Processor Chip (enabled)
Processor revision: 3.5. Secondary cache: Size 8 MB Speed 266 Mhz
CPU 27 at Module 001c32/Slot 0/Slice D: 400 Mhz MIPS R12000 Processor Chip (enabled)
Processor revision: 3.5. Secondary cache: Size 8 MB Speed 266 Mhz
CPU 28 at Module 001c35/Slot 0/Slice A: 400 Mhz MIPS R12000 Processor Chip (enabled)
Processor revision: 3.5. Secondary cache: Size 8 MB Speed 266 Mhz
CPU 29 at Module 001c35/Slot 0/Slice B: 400 Mhz MIPS R12000 Processor Chip (enabled)
Processor revision: 3.5. Secondary cache: Size 8 MB Speed 266 Mhz
CPU 30 at Module 001c35/Slot 0/Slice C: 400 Mhz MIPS R12000 Processor Chip (enabled)
Processor revision: 3.5. Secondary cache: Size 8 MB Speed 266 Mhz
CPU 31 at Module 001c35/Slot 0/Slice D: 400 Mhz MIPS R12000 Processor Chip (enabled)
Processor revision: 3.5. Secondary cache: Size 8 MB Speed 266 Mhz
Main memory size: 4096 Mbytes
Instruction cache size: 32 Kbytes
Data cache size: 32 Kbytes
Secondary unified instruction/data cache size: 8 Mbytes
Memory at Module 001c10/Slot 0: 512 MB (enabled)
Bank 0 contains 256 MB (Standard) DIMMS (enabled)
Bank 1 contains 256 MB (Standard) DIMMS (enabled)
Memory at Module 001c13/Slot 0: 512 MB (enabled)
Bank 0 contains 256 MB (Standard) DIMMS (enabled)
Bank 1 contains 256 MB (Standard) DIMMS (enabled)
Memory at Module 001c16/Slot 0: 512 MB (enabled)
Bank 0 contains 256 MB (Standard) DIMMS (enabled)
Bank 1 contains 256 MB (Standard) DIMMS (enabled)
Memory at Module 001c21/Slot 0: 512 MB (enabled)
Bank 0 contains 256 MB (Standard) DIMMS (enabled)
Bank 1 contains 256 MB (Standard) DIMMS (enabled)
Memory at Module 001c24/Slot 0: 512 MB (enabled)
Bank 0 contains 256 MB (Standard) DIMMS (enabled)
Bank 1 contains 256 MB (Standard) DIMMS (enabled)
Memory at Module 001c29/Slot 0: 512 MB (enabled)
Bank 0 contains 256 MB (Standard) DIMMS (enabled)
Bank 1 contains 256 MB (Standard) DIMMS (enabled)
Memory at Module 001c32/Slot 0: 512 MB (enabled)
Bank 0 contains 256 MB (Standard) DIMMS (enabled)
Bank 1 contains 256 MB (Standard) DIMMS (enabled)
Memory at Module 001c35/Slot 0: 512 MB (enabled)
Bank 0 contains 256 MB (Standard) DIMMS (enabled)
Bank 1 contains 256 MB (Standard) DIMMS (enabled)
ROUTER in Module 001c10/Slot 0: Revision 1: Active Ports [1,2,3,4,5,6,7,8] (enabled)
ROUTER in Module 001c24/Slot 0: Revision 1: Active Ports [1,2,3,4,5,6,7,8] (enabled)
Integral SCSI controller 4: Version Fibre Channel QL2200A
Disk drive: unit 114 on SCSI controller 4 (unit 114)
Disk drive: unit 115 on SCSI controller 4 (unit 115)
Disk drive: unit 116 on SCSI controller 4 (unit 116)
Disk drive: unit 117 on SCSI controller 4 (unit 117)
Disk drive: unit 118 on SCSI controller 4 (unit 118)
Disk drive: unit 119 on SCSI controller 4 (unit 119)
Disk drive: unit 120 on SCSI controller 4 (unit 120)
Disk drive: unit 121 on SCSI controller 4 (unit 121)
Disk drive: unit 122 on SCSI controller 4 (unit 122)
Disk drive: unit 123 on SCSI controller 4 (unit 123)
Disk drive: unit 124 on SCSI controller 4 (unit 124)
Disk drive: unit 125 on SCSI controller 4 (unit 125)
Integral SCSI controller 3: Version Fibre Channel QL2200A
Disk drive: unit 114 on SCSI controller 3 (unit 114)
Disk drive: unit 115 on SCSI controller 3 (unit 115)
Disk drive: unit 116 on SCSI controller 3 (unit 116)
Disk drive: unit 117 on SCSI controller 3 (unit 117)
Disk drive: unit 118 on SCSI controller 3 (unit 118)
Disk drive: unit 121 on SCSI controller 3 (unit 121)
Integral SCSI controller 0: Version Fibre Channel QL2200
Disk drive: unit 40 on SCSI controller 0 (unit 40)
Disk drive: unit 41 on SCSI controller 0 (unit 41)
Disk drive: unit 42 on SCSI controller 0 (unit 42)
Disk drive: unit 43 on SCSI controller 0 (unit 43)
Disk drive: unit 44 on SCSI controller 0 (unit 44)
Disk drive: unit 45 on SCSI controller 0 (unit 45)
Disk drive: unit 46 on SCSI controller 0 (unit 46)
Disk drive: unit 47 on SCSI controller 0 (unit 47)
Disk drive: unit 48 on SCSI controller 0 (unit 48)
Disk drive: unit 49 on SCSI controller 0 (unit 49)
Integral SCSI controller 1: Version Fibre Channel QL2200A
Disk drive: unit 114 on SCSI controller 1 (unit 114)
Disk drive: unit 115 on SCSI controller 1 (unit 115)
Disk drive: unit 116 on SCSI controller 1 (unit 116)
Disk drive: unit 117 on SCSI controller 1 (unit 117)
Disk drive: unit 118 on SCSI controller 1 (unit 118)
Disk drive: unit 119 on SCSI controller 1 (unit 119)
Disk drive: unit 120 on SCSI controller 1 (unit 120)
Disk drive: unit 121 on SCSI controller 1 (unit 121)
Disk drive: unit 122 on SCSI controller 1 (unit 122)
Disk drive: unit 123 on SCSI controller 1 (unit 123)
Disk drive: unit 124 on SCSI controller 1 (unit 124)
Disk drive: unit 125 on SCSI controller 1 (unit 125)
Integral SCSI controller 2: Version Fibre Channel QL2200A
Disk drive: unit 1 on SCSI controller 2 (unit 1)
Disk drive: unit 2 on SCSI controller 2 (unit 2)
Integral Fast Ethernet: ef0, version 1, module 001c10, pci 4
PCI Adapter ID (vendor 4215, device 8704) pci slot 1
PCI Adapter ID (vendor 4215, device 8704) pci slot 2
PCI Adapter ID (vendor 4215, device 8704) pci slot 1
PCI Adapter ID (vendor 4215, device 8704) pci slot 2
PCI Adapter ID (vendor 4215, device 8704) pci slot 3
PCI Adapter ID (vendor 4265, device 3) pci slot 4
PCI Adapter ID (vendor 4545, device 22529) pci slot 5
PCI Adapter ID (vendor 4172, device 32777) pci slot 6
PCI Adapter ID (vendor 4140, device 192) pci slot 7
IOC3 external interrupts: 1
HUB in Module 001c10/Slot 0: Revision 2 Speed 200.00 Mhz (enabled)
HUB in Module 001c13/Slot 0: Revision 2 Speed 200.00 Mhz (enabled)
HUB in Module 001c16/Slot 0: Revision 2 Speed 200.00 Mhz (enabled)
HUB in Module 001c21/Slot 0: Revision 2 Speed 200.00 Mhz (enabled)
HUB in Module 001c24/Slot 0: Revision 2 Speed 200.00 Mhz (enabled)
HUB in Module 001c29/Slot 0: Revision 2 Speed 200.00 Mhz (enabled)
HUB in Module 001c32/Slot 0: Revision 2 Speed 200.00 Mhz (enabled)
HUB in Module 001c35/Slot 0: Revision 2 Speed 200.00 Mhz (enabled)
IP35prom in Module 001c10/Slot n0: Revision 6.44
IP35prom in Module 001c13/Slot n0: Revision 6.44
IP35prom in Module 001c16/Slot n0: Revision 6.44
IP35prom in Module 001c21/Slot n0: Revision 6.44
IP35prom in Module 001c24/Slot n0: Revision 6.44
IP35prom in Module 001c29/Slot n0: Revision 6.44
IP35prom in Module 001c32/Slot n0: Revision 6.44
IP35prom in Module 001c35/Slot n0: Revision 6.44
USB controller: type OHCI
|
If a piece of peripheral hardware installed on your system does not appear in the hinv output, it may or may not be an indication of trouble with your hardware. Some peripherals connected to the system by a board on a VME bus are not identified when running hinv from the command monitor. To list the missing peripheral, enter hinv at a system shell prompt. If your peripheral is still not recognized, reseat the board or device in its socket and check that it is using the correct SCSI address. If this does not relieve the problem, the hardware itself may be defective. Note also that most devices are not recognized by hinv until after the MAKEDEV command has been run after their installation.
The contents of the /hw directory structure are updated as necessary by the ioconfig command run from /etc/brc at boot time (see “Multiuser State from System Shutdown” in Chapter 3 and the oconfig(1M) man page for more information). All recognized hardware should be represented by an entry under /hw, and some of these entries will have symbolic links in other parts of the /hw structure as well as /dev.
For example, the system root partition may appear in the following entries:
/hw/scsi_ctlr/1/target/1/lun/0/disk/partition/0/block /hw/disk/root /dev/root |
The first entry (/hw/scsi_ctlr/ and so on) represents the physical location of the board as described in hwgraph(4D). The second and third paths shown above (/hw/disk/root and /dev/root) are symbolic links to the long physical pathname (the first path above). The symbolic links serve as a convenient shorthand for the various system commands that need to reference the device.
With each system restart (for example, after a reboot, shutdown, halt, init command, or power off), the startup routine probes for hardware devices on all the systems connected into the NUMAlink interconnection fabric. All the slots and links in all the modules within the fabric are probed.
The routine then creates a hierarchical filesystem, called the hardware graph, that lists all the hardware that is located. The top of the hardware graph is visible at /hw. For complete details, see the hwgraph(4D)man page.
After the hardware graph is completed, the ioconfig program assigns a unit number to each located device that needs one. Other programs (for example, hinv and the device's driver) read the assigned number and use it.
On an initial startup, ioconfig assigns numbers sequentially; for example, if two IRIS ATM XIO boards are found, they are numbered unit0 (with ports 0 to 3) and unit1 (with ports 4 to 7).
On subsequent startups, ioconfig distinguishes between hardware that it has seen before and new items. To previously seen items, it assigns the same unit and port numbers that were assigned on the initial startup. To new hardware, it assigns new sequential numbers. ioconfig never reassigns a number, even if the device that had the number is removed and leaves a gap in the numbering.
New items are differentiated from previously-seen items based on the hardware graph listing (that is, the path within /hw). The database of previously-seen devices is kept in the /etc/ioconfig.conf file. For example, a replacement board (exact same name) that is installed into the location of an old board will be assigned the old board's numbers, while a board that is moved from one location to another will be assigned a new unit number and new port numbers.
For more information about the hardware graph and ioconfig, see the hwgraph(4D) and ioconfig(1M) man pages.
The versions command gives you an inventory of software packages that have been installed using inst. This command can be run only at the system shell prompt, not from the command monitor. Software installed by other means is not included in the versions output. Along with the names of the software products, the release revision level numbers are displayed. By default, the output of versions includes all the products and their subsystems and is typically several hundred lines long. It is often convenient to redirect the output to a file that you can view at your convenience. For a more general look at the products you have installed, without the list of specific subsystems, use the -b (brief) flag as shown in Example 4-2:
versions -b output reads as follows although a complete listing is much longer: |
I = Installed, R = Removed
Name Date Description
I 4Dwm 07/18/96 Desktop Window Manager, 6.2 (based on
OSF/Motif 1.2.4)
I demos 07/18/96 Graphics Demonstration Programs, 6.2
I desktop_base 07/18/96 IndigoMagic Desktop Base Software,
6.2
I desktop_eoe 07/18/96 IndigoMagic Desktop, 6.2
I desktop_tools 07/18/96 Desktop Tools, 6.2
I dps_eoe 07/18/96 Display PostScript/X, 2.0.5 based on
PostScript Level 2
I eoe 07/22/96 IRIX Execution Environment, 6.2
I insight 07/18/96 IRIS InSight Viewer, 2.3.3
I nfs 07/18/96 Network File System, 6.2 with IMPACT
10000
|
The gfxinfo command is useful for determining the graphics hardware installed in the system. It is in the /usr/gfx directory, which is not on any of the standard search paths. Thus gfxinfo typically needs the full pathname to be specified for successful execution. As shown in Example 4-3, the command requires no arguments to run.
This sample gfxinfo output is for an Indy workstation:
% /usr/gfx/gfxinfo |
Graphics board 0 is "NG1" graphics.
Managed (":0.0") 1280x1024
24 bitplanes, NG1 revision 3, REX3 revision B,
VC2 revision A
MC revision C, xmap9 revision A, cmap revision C,
bt445 revision A
Display 1280x1024 @ 60Hz, monitor id 12
|
This command provides more information about the graphics system than the hinv command (hinv would simply return Indy 24-bit). From the output of gfxinfo you can determine the number of screens and their pixel resolutions, bitplane configurations, component revision levels, and monitor types. There is no man page for gfxinfo. Servers without graphics capability do not have this command installed.
The uname command returns information such as the operating system version and hostname. The -a option gives a complete list of the uname output. See the uname(1) man page for a description of all the uname options and fields.
lpstat with the -a option shows all the printers configured for the lp spooling system and gives their status. See the IRIX Admin: Peripheral Devices and the lpadmin(1M) and lpstat(1) man pages for detailed information on printer administration.
You can quickly check the configuration of a workstation or server with chkconfig(1) as shown in Example 4-4. The /sbin/chkconfig command reports the state of various process daemons (that is, whether or not they are supposed to be active).
Enter the chkconfig command to check your configuration.
chkconfig |
This sample output is typical for a networked workstation with the Network File System (NFS) option installed. The left column of the output describes a system feature, and the right column indicates whether it is on or off.
Flag State ==== ===== acct off audit off automount on gated off lockd on mrouted off named off network on nfs on noiconlogin off nsr on quotacheck off quotas off routed on rtnetd off rwhod off sar on snmpd on timed on timeslave off verbose off visuallogin on windowsystem off yp on ypmaster off ypserv off |
The following list provides more specific information about each system feature:
The following sections describe how to set the various options available to customize your IRIX operating system.
Y ou can use the chkconfig(1M) command to change some aspects of system configuration. To determine which aspects of a system you can alter with chkconfig, enter the chkconfig command:
chkconfig |
You see a list of configuration options, which are described in “Checking Software Configuration Options with chkconfig”. If you use the -s option, you see a list that is sorted by whether the configuration item is on or off.
To change a configuration option, use the chkconfig command with two arguments: the name of the option you wish to change and the new status of the configuration (on or off). You must have root privilege to change a system configuration.
For example, to turn on detailed process accounting, log in either as root or as the system administrator, and enter:
chkconfig acct on |
To turn off process accounting, enter:
chkconfig acct off |
Some aspects of system configuration do not take effect until the system is shut down and rebooted because startup scripts, which are in the directory /etc/init.d, are run when the system is booted and brought to multiuser mode. These scripts read the files that chkconfig sets to determine which daemons to start.
Some configuration items that can be controlled by chkconfig may not be displayed by chkconfig. These include:
| nostickytmp | Sets sticky behavior for the directory /tmp. When the directory is sticky, (with nostickytmp set to off), users may not remove files from the directory unless they own the files, have explicit permission to remove the files (write permission), or have superuser privileges. The opposite behavior allows users to remove or replace files in /tmp, which is a publicly writable directory, even if they do not own the files. This is handy behavior if you have users who need to create large temporary files and you are short on disk space. But it is better to increase disk space to avoid important files being removed. | |
| nocleantmp | Controls whether or not the directory /tmp is cleaned out each time the system is booted. If nocleantmp is on, /tmp is not cleaned. If nocleantmp is off, all files in /tmp are removed each time the system is started. |
If you want to see these flags in the chkconfig menu, you can use the -f option to force chkconfig to create a configuration file for the options:
chkconfig -f nocleantmp on |
In this example, chkconfig creates a configuration file called nocleantmp in the directory /etc/config, which flags the system not remove files from /tmp at reboot.
These system-wide defaults affect programs and system functions:
System display
Processor allocation
Time zone
Name of the system
Network address
Default system printer
System date and time
File and directory access permissions
Access control lists (ACLs) and capabilities
These defaults are described more thoroughly in specific sections of this guide, but they are all presented here to provide an overview of the IRIX system.
You can make the output of programs and utilities running on one system appear on the screen of another system on the same network by changing the DISPLAY environment variable. This is useful if your network includes graphical systems and non-graphical servers. In order to view information from the server graphically, you reset the display to a graphics workstation.
For example, if your server has only a character-based terminal as its console and you wish to run gr_osview to visually inspect your CPU usage, you would issue this command on the server (for csh and tcsh shells):
setenv DISPLAY graphics_system:0 gr_osview |
or this command for ksh and sh shells:
DISPLAY=graphics_system:0; export DISPLAY |
Also issue an xhost command on the graphics system to allow the server to display on it:
xhost +server_system |
When you invoke gr_osview on the server, the window with the output will appear on the graphics system name you specify. In this example, graphics_system was used in place of the system name. The :0 used after the system name indicates that display monitor 0 (the graphics console) should be used to display the output. When you have finished using the graphics console, be sure to reset the display by issuing this command on the server:
setenv DISPLAY local_server:0 |
local_server is the name of your server. If you logged in from the graphics system to the server and set the DISPLAY variable that way, simply log out when you are finished.
If you have a multiprocessor system, the mpadmin(1M) command and the Miser suite of commands allow you to change the way programs are assigned to the various processors on your system. To determine if your system is multiprocessor, use the hinv(1M) command. A multiprocessor system returns information similar to the following in its hinv output:
Processor 0: 40 MHZ IP7 Processor 1: 36 MHZ IP7 Processor 2: 40 MHZ IP7 Processor 3: 40 MHZ IP7 Processor 4: 40 MHZ IP7 Processor 5: 40 MHZ IP7 Processor 6: 40 MHZ IP7 Processor 7: 40 MHZ IP7 |
Or, alternately, output similar to the following:
8 40 MHZ IP7 Processors |
A single-processor system returns information similar to the following for the hinv command:
1 100 MHZ IP22 Processor |
If you have only one processor on your system (and the vast majority of systems have only one processor), this command still operates, though it has no useful purpose.
The mpadmin command allows you to turn off processors, report various states of the processors, and move system functions such as the system clock to specific processors. For more information, see the mpadmin(1M) man page.
For partitioning of the system in a batch environment, the batch scheduling component of Miser should be used. Miser allows for fine-grained control of memory and CPU allocations between batch applications, and between batch and interactive applications. For information on Miser, see IRIX Admin: Resource Administration.
The Cpuset System is primarily a workload manager tool permitting a system administrator to restrict the number of processors that a process or set of processes may use. Cpusets may optionally restrict both kernel and user memory.
When the memory restriction feature is enabled, a set of nodes each containing a set of CPUs is computed from the list of CPUs supplied and memory allocations can be limited to the CPUs assigned to the nodes. Allocation limits can be restricted to the available physical memory or overflow can be swapped to the swap file.
A system administrator can use cpusets to create a division of CPUs within a larger system. Such a divided system allows a set of processes to be contained to specific CPUs, reducing the amount of interaction and contention those processes have with other work on the system. In the case of a restricted cpuset, the processes that are attached to that cpuset will not be affected by other work on the system; only those processes attached to the cpuset can be scheduled to run on the CPUs assigned to the cpuset. An open cpuset can be used to restrict processes to a set of CPUs so that the affect these processes have on the rest of the system is minimized.
The cpuset command can be used to create, destroy, and display these CPU sets. For more information, see the cpuset(1) man page and IRIX Admin: Resource Administration.
You can use the mpadmin(1) command to exclude the specified CPU from performing any work. This functionality is useful in a situation in which you suspect a CPU may have a hardware error but you do not want to shut down your entire system.
The mpadmin -x[processor] command excludes the processor numbered processor. An excluded processor is isolated, as in the case of the mpadmin command with the -I argument. In addition, the runon(1) command and sysmp(2) function with the MP_MUSTRUN argument are prohibited from executing any commands on the processor. When no processor is specified, the mpadmin -x command writes the numbers of the processors that are excluded to the standard output. This request will fail if there are any MUSTRUN processes currently running on the processor. For more information, see the mpadmin(1) man page.
The name of the system is stored in several places. If you want to change the name of your system, you must change the name in all the following locations, or your system does not function correctly:
In the file /etc/sys_id
In the file /etc/hosts (for networking purposes)
In a kernel data structure, which you read and set with hostname
In an NIS map on the NIS master server, if you are running NIS
Note: Do not arbitrarily change the name of a running workstation. Many programs that are started at boot time depend on the name of the workstation.
To display the name of the system, use the hostname command with no arguments:
hostname |
This command displays the name of the system. The uname command also displays the name of the system, along with other information.
Procedure 4-1 describes how you change the name of a workstation.
Procedure 4-1. Changing a Workstation Name
Log in as root.
Edit the file /etc/sys_id. Change the name of the host to the new name. Write and exit the editor.
You must also change the name of the host in any network files, such as /etc/hosts, and possibly in the NIS map on the master NIS server.
Reboot your system.
All programs that read the hostname when they are started at boot time now use the correct hostname.
For information about the Internet address of a workstation, see IRIX Admin: Networking and Mail . For more information about the name of the system, see the hostname(1) and uname(1) man pages.
The system's network address (IP address) is covered more thoroughly in IRIX Admin: Networking and Mail .
Procedure 4-2 describes how you set a network address.
Procedure 4-2. Setting a Network Address
Place the network address in /etc/hosts on the same line as the system name. For example
194.45.54.4 magnolia
If you use the network information service (NIS), place the name of your domain in the file /var/yp/ypdomain, if it is installed.
Use the nvram(1M) command to set the variable netaddr to the IP number of the system. For example:
nvram netaddr 194.45.54.4
The lpadmin(1M) command sets the default printer. This command sets the default printer to laser:
lpadmin -dlaser |
Note that the printer laser must already exist and be configured. For complete information on setting up printers, see the IRIX Admin: Peripheral Devices .
To set the time zone of the system, edit the file /etc/TIMEZONE. For a site on the east coast of the United States, the file might look something like this:
# Time Zone TZ=EST5EDT |
The line TZ=EST5EDT means:
The current time zone is Eastern Standard Time.
It is 5 hours to the west of Greenwich Mean Time.
Daylight saving time applies here (EDT).
The TZ environment variable is read by init(1) when the system boots, and the value of TZ is passed to all subsequent processes. The time zone designation (such as EST) is simply passed through for your convenience. The important parts of the designation are the specification of the deviation from Greenwich Mean Time and the presence of the daylight savings time indicator. For convenient time zone information for the majority of North America, Europe, Asia, the Middle East, South America, and Australia and New Zealand, see Table 4-1 through Table 4-6.
Table 4-1. North America Time Zones
Region | GMT Differential | Abbreviation |
|---|---|---|
Newfoundland | -3:30 | NST |
Atlantic | -4:00 | AST |
Eastern | -5:00 | EST |
Central | -6:00 | CST |
Saskatchewan | -6:00 | CST |
Mountain | -7:00 | MST |
Pacific | -8:00 | PST |
Yukon | -9:00 | YST |
Alaska | -10:00 | AST |
Hawaii | -10:00 | HST |
Bering | -11:00 | BST |
Baja Norte | -8:00 | PST |
Baja Sur | -7:00 | MST |
Mexico (General) | -6:00 | CST |
Region | GMT Differential | Abbreviation |
|---|---|---|
Ireland | 0:00 | BST |
The United Kingdom | 0:00 | BST |
Western Europe | 0:00 | WET |
Iceland | 0:00 | WET |
Middle Europe | 1:00 | MET |
Poland | 1:00 | MET |
Eastern Europe | 2:00 | EET |
Turkey | 3:00 | EET |
Western Russia | 3:00 | WSU |
Region | GMT Differential | Abbreviation |
|---|---|---|
Rep. of China | 8:00 | CST |
Hong Kong | 8:00 | HKT |
Japan | 9:00 | JST |
Rep. of Korea | 9:00 | ROK |
Singapore | 8:00 | SST |
Table 4-4. Middle East Time Zones
Region | GMT Differential | Abbreviation |
|---|---|---|
Israel | 2:00 | IST |
Egypt | 2:00 | EET |
Table 4-5. South America Time Zones
Region | GMT Differential | Abbreviation |
|---|---|---|
Brazil/East | -3:00 | EST |
Brazil/West | -4:00 | WST |
Brazil/Acre | -5:00 | AST |
Brazil/De Noronha | -2:00 | FST |
Chile/Continental | -4:00 | CST |
Chile/Easter Island | -6:00 | EST |
Table 4-6. Australia and New Zealand Time Zones
Region | GMT Differential | Abbreviation |
|---|---|---|
Australia/Tasmania | 10:00 | EST |
Australia/Queensland | 10:00 | EST |
Australia/North | 9:30 | CST |
Australia/West | 8:00 | WST |
Australia/South | 9:30 | CST |
Australia/Victoria | 10:00 | EST |
Australia/NSW | 10:00 | EST |
New Zealand | 12:00 | NZT |
For complete information about setting your time zone, see the timezone(4) man page.
Use the date(1) command to set the date and time. For example, to set the date to April 1st, 1999, and the time to 09:00, log in as root and enter:
date 0401090099 |
Changing the date and time on a running system can have unexpected consequences. Users and administrators use system scheduling utilities (at, cron, and batch) to perform commands at specified times. If you change the effective date or time on the system, these commands may not execute at the desired times. Similarly, if your users use the make utility provided with the system, the commands specified in Makefiles may perform incorrectly. Always try to keep your system date and time accurate within reason. Random changes of the date and time can be extremely inconvenient and possibly destructive to users' work.
If timed is running on the system, and it is a slave system, the time is reset by timed and not the date command. For more information, see the timed(1M) man page.
In general, IRIX file access permissions are set to allow ease of use among multiple users while maintaining system security. This section discusses how you can change file access permissions to permit or deny read, write, and execution permission for users, groups, or everyone. Note that users can also configure a umask to control default access to their own files (see “Default File Permissions (umask)” in Chapter 5 for more information).
The IRIX operating divides permissions into three categories, and users into three relationships. The three relationships are the owner of the file, the owner's user group, and all users. If you view a long listing of a directory, you see that the permissions field for each file in the directory looks something like this:
-rwxrwxrwx |
Note that the line of permissions has the string rwx repeated three times. The first instance of rwx applies to the file owner, the next instance applies to the group members, and the third applies to all other users on the system. The example above shows full permissions. A more restricted permission set might look like this:
-rw-r--r-- |
The three categories of permissions are read, write, and execute. They are denoted as r for read, w for write, and x for execute in long listings of files. To get a long listing, enter the following command at your system prompt in any directory:
ls -l |
Along with the permission information, the ls -l command lists the owners and the sizes of the files and the date they were last modified.
Read permission allows you to look at the contents of a file. Write permission allows you to make changes to or remove a file. Execute permission allows you to run the file as a command from your shell prompt.
Each character is separately significant in the permissions listing. Starting at the left, the first character is a dash. A dash in any other position means that no permission is granted and the actions associated with that permission are denied. However, in the left-most place, the contents of that space describes whether the file is a file or a directory. If it is a directory, a d appears in that space. Other characters in this place indicate that the file is a pipe, a block or character special device file, or other type of file. See the ls(1) man page.
To see the current status of a file's permission settings, use the ls -l command. For example, to see the status of permission on the file review, enter:
ls -l review -rw-r--r-- 1 jones engr 1015 Aug 14 16:20 review |
Permissions are shown as read (r), write (w), and execute (x), for each of user, group, and other, respectively. That is, each of the user, group, and everyone else has some combination of read, write, and execute access to the file. After the first character (in this example, a dash), the next three characters give the read, write, and execute permission for the user, the next three characters give the read, write, and execute access for the group, and the last three characters give the read, write, and execute access for everyone else. So in the example, user jones has read (r) and write (w), access to the file review, while the group has only read (r) access, and other also has only read (r) access. Nobody has execute (x) permission.
The superuser or owner of the file can change these permission settings. As superuser, you can give everyone write access to a file with the chmod command. For example, to add write access for the group and others to the review file, use the go+w (g for group, o for other, and +w to permit writing) option as follows:
chmod go+w review |
Now the access permissions should look like this:
-rw-rw-rw- 1 jones engr 1015 Aug 14 16:20 review |
Another way of controlling permission settings is with the octal number representation obtained by using 7 as representing read, write and execute permission (4+2+1). In this way, to give complete read, write, and execute permissions to a file, use the chmod 777 command, and to give just read permission to the owner and no other permissions at all, use chmod 400. For complete information on setting access permissions on files and directories, refer to the chmod(1) man page.
| Note: If you use chmod on a device file, edit the /etc/ioperms file to reflect the change, or the device file returns to the default access permissions after a reboot. |
The format of an entry in /etc/ioperms is:
device_name owner group nnn |
device_name is the device filename, owner is the file owner, group is the group, and nnn is the octal permission setting as described above and in the chmod(1) man page. Refer to the ioconfig(1M) man page for details on device permission settings in the /etc/ioperms file.
Directories use the same permissions as files, but their meanings are slightly different. For example, read permission on a directory means that you can use the ls command to look at the contents of that directory. Write permission allows you to add, change, or remove files in that directory. (However, even though you may have write permission in that directory, you must also have write permission on the individual files to change or remove them, unless you own the directory.) Finally, execute permission on a directory allows you to use the cd command to change directories into that directory.
The first series of three places after the leftmost place in the permissions field describe the permissions for the owner of the file. Here is an example of a long listing for a file:
-rwx------ 1 owner grp 6680 Apr 24 16:26 shell.script |
The file is not a directory, so the leftmost space is blank. The characters rwx indicate that the owner of the file, owner, has read, write, and execute permission on this file. The second series of three spaces describe permissions for the owner's group. In this case, the group is grp. Suppose permissions for this file were slightly different, like this:
-rwxr-x--- 1 owner grp 6680 Apr 24 16:26 shell.script |
In that case, any member of the group grp could read or execute the file, but not change it or remove it. All members of group grp can share a pool of files that are individually owned. Through careful use of group read and write permissions, you can create a set of document source files that are owned by one person, but any group member can work on them.
The third series of spaces provides for all other users on the system and is called the public permissions. A file that is set to be readable by any user on the system is called publicly readable.
Example 4-5 shows a long listing of a sample projects directory:
Example 4-5. Projects Directory
total 410 drw------- 1 owner grp 48879 Mar 29 18:10 critical -rw-r--r-- 1 owner grp 1063 Mar 29 18:10 meeting.notes -rw-rw-rw- 1 owner grp 2780 Mar 29 18:10 new.deal -rwxrwxrwx 1 owner grp 8169 Jun 7 13:41 new.items -rw-rw-rw- 1 owner grp 4989 Mar 29 18:10 response -rw------- 1 owner grp 23885 Mar 29 18:10 project1 -rw-r----- 1 owner grp 3378 Jun 7 13:42 saved_mail -rw-r--r-- 1 owner grp 2570 Mar 29 18:10 schedules -rwxrwxr-x 1 owner grp 6680 Apr 24 16:26 shell.script |
The files in this directory have varying permissions. Some are restricted to the owner, some can be read only by members of the owner's group, and some can be read, changed, or removed by anybody. The shell script is executable by any user.
You change the permissions on a file by means of the chmod(1) command. You can use chmod only to change files that you own. Generally, you use this command to protect files you want to keep secret or private, to protect private directories, and to grant permissions to files that need to be used by others. To restrict access to a file or directory to yourself only, enter:
chmod 600 filename chmod 700 dirname |
Other permissions may be added by using the chmod command with the letter associated with the permission. For example, to add general write permission to a file, enter:
chmod +w filename |
For more examples, see the chmod(1) man page.
You can decide what default permissions your files have by placing the umask command in your .cshrc, .profile, or .login file. There is a default umask setting for the entire system in the /etc/profile and /etc/cshrc files. By changing the setting of your umask, you can alter the default permissions on your files and directories to any available Discretionary Access Control (DAC) permission. See the umask(1) man page for more information.
A drawback to the umask command is that it makes every file you create receive the same permissions. For most purposes, you want the files you create to be accessible by the members of your group. For example, if an individual is suddenly called away and another person must take over that person's portion of a project, the source files must be accessible by the new user. However, you might want the personal files you keep in your home directory to be private, and if you set your umask to allow group read and write privileges, any member of the group can access your personal files. But mechanisms are available to prevent this access. For example, you can create a directory of private files and alter the permissions on that directory with the chmod command to restrict all but your own access. Then no other user would be allowed into the directory.
You can also use the IRIX utilities to change all the files in your home directory to your chosen permission automatically at your convenience. You can set up your account so that this action happens to any files or directories you indicate every time you log out. For example, say you have three directories, called personal, letters, and budget. You can set up a .logout file in your home directory with commands to be executed each time you log out from the system. The following commands, placed in the.logout file will prevent access to the three example directories to anyone but you:
chmod 700 budget personal letters chmod 600 budget/* personal/* letters/* |
The umask command is an important part of DAC. It allows you to maintain security and still allow convenient access to your files. To set your account up to allow group read and write privileges and no other privileges, place this line in your .cshrc or .profile file:
umask 006 |
This makes every file you create have the following permissions:
-rw-rw---- |
With your umask set to 006, directories that you create have the following permissions:
drwxrwx--- |
In plainer terms, you and your group will have full use of the file or directory. No other user, except the superuser (root), will have access to your files.
Partitioning an SGI Origin 3000 series system involves dividing a single large system into multiple distinct systems, each with its own console, root filesystem, and IP network address as shown in Figure 4-1. Each partition can be rebooted, loaded with software, powered down, and upgraded independently. The partitions can communicate via IP over a NUMAlink connection.
Partitions can be of different sizes, and a particular system can be configured in more than one way. For example, a 128-processor system could be configured into four partitions of 32 processors each. (See “Supported Configurations” for a list of supported configurations for system partitioning.)
Your choice of partition size and number of partitions affects fault containment and scalability. In general, a middle-of-the-road solution may be acceptable in terms of both fault containment and scalability.
From a fault containment perspective, if the partitions are large, more of the system is lost in a failure because a failure in a partition brings down the complete partition.
From a scalability perspective, within a single partition, a system scales as if it is a single system. An application may only execute within a single partition. A network protocol is required for communication between applications in multiple partitions.
Fault containment is one of the major reasons for partitioning a system. A single partition can be brought down (because of a hardware or software failure, or as part of a controlled shutdown) without affecting the rest of the system. A hardware memory barrier is set up between any two partitions, thus providing higher availability for a partition than for a single large system.
Another advantage of partitioning is that large jobs can be run when required by converting the system into one large system at night, and then splitting it into multiple systems during the day.
Disadvantages of partitioning a system include loss of the ability to run or degraded performance for larger applications, such as heavily multithreaded applications or shared memory applications. In addition, with a partitioned system, access is lost to all system resources outside of your own partition, including filesystems, disks, and networking devices.
SGI 3000 Series systems must have the eoe.sw.partition software package installed in order to use the system partitioning capabilities. A new kernel must be configured and a system boot must be done after installing the partitioning software package.
Interpartition communication occurs through a fault-tolerant messaging system (xpc) as shown in Figure 4-2. The kernel in each partition is aware of all the other kernels. They communicate by using the hardware's block transfer engine ( BTE). The xpc driver uses this hardware.
The xpc driver provides multiple (32) logical channels: some are used for kernel-to-kernel communication, and others are used by the raw cl or network if_cl devices.
Each partition has one cl driver and one if_cl driver. The if_cl driver implements an IP interface on top of xpc; if_cl is the NUMAlink network interface. Applications can use BSD sockets, for example, to communicate between partitions.
For cl devices, 16 full-duplex logical channels provide for character device user communication to any other partition. Each device appears in the /hw filesystem when its target partition boots. The pathname is as follows (the partition_number and device_number are specified as two-digit hexadecimal values):
/hw/xplink/raw/partition_number/device_number |
The if_cl driver is configured using the ifconfig command. See the ifconfig(1M) man page for more information. The procedure for configuring the if_cl driver as a network driver is essentially the same as the procedure used to configure the Ethernet driver (ef0).
To configure the if_cl driver, follow the steps in Procedure 4-3:
System partitioning is an administrative function. The system console is connected to the controller as required by the configuration selected when an SGI 3000 Series system is installed. For additional information or recabling, contact your service representative.
You can set up partitions by using the mkpart partition configuration command or by using the setpart command from the command monitor.
The mkpart partition configuration command allows you to perform the following tasks:
List current partitions.
Save the current configuration.
Set up partitions and include the following steps:
Split an existing system into multiple partitions.
Coalesce partitions into a larger system.
Split up existing partitions and regroup them differently.
The mkpart command can be run only by the system administrator with superuser privilege. If the system is configured as CAP_NO_SUPERUSER, you must have effective capabilities of CAP_SHUTDOWN, CAP_DEVICE_MGT and CAP_SYSINFO_MGT. See the capabilities(4) man page for more information on the capability mechanism that provides fine grained control over the privileges of a process. All partitions that are affected by mkpart must be running the IRIX operating system.
See the mkpart(1M) man page for detailed information on this command.
A typical sequence of partitioning commands is as follows:
Run mkpart -l to list all partitions.
Run mkpart again to repartition the system.
Partition IDs are stored in the L1 system controllers.
mkpart uses a daemon (mkpd) to write IDs on remote partition L1s.
Reboot all affected partitions if mkpart is successful.
The mkpart command-line syntax is as follows:
mkpart [-p partid -m brick ... [ -m brick ... ] ... ] ... [-F]
mkpart [-i] [-F]
mkpart [-l]
mkpart [-n]
mkpart [-h]
The mkpart command supports the following options:
| -p partid | Specifies the partition ID for the new configuration. | |||
| -m brick | Indicates the C-brick (brick is used in some documentation) number. | |||
| -i | Coalesces all currently active partitions into a single system with a partition ID of 0. A partition ID of 0 indicates an unpartitioned system. | |||
| -l | Lists current partitions. | |||
| -n | Prints partition ID of this partition. | |||
| -h | Prints a usage message.
| |||
| -F | Forces override of all sanity checks. The command sets up partitioning as given and tries to reboot the system. |
You can also set up partitions by using the setpart command from the command monitor.
To set up partitions using the setpart command, follow the steps in Procedure 4-4:
Procedure 4-4. Setting Up Partitioned Systems
Reset the system.
From the System Maintenance menu, enter option 5 for the command monitor.
Run the setpart command. (The setpart -h command displays all setpart options.) The setpart command is an interactive command that takes input from you, including a partition number and the C-brick numbers of the C-bricks that comprise the partition.
After finishing, reset the system again. The system will now come up as two or more partitions. Each partition needs to have a I-brick, root disk, console, and so on.
To tear down partitions and coalesce the system back together, follow the steps in Procedure 4-5:
Procedure 4-5. Tearing Down Partitions
Drop to the command monitor in all the partitions.
Run the setpart -c command in any of the partitions. This command clears all partition information and offers to reset all partitions simultaneously. Now the entire system is reset and comes back up together as a single partition.
The partmgr(1M) command invokes a partitioning administration tool for the SGI Origin 3000 series of servers that allows you define and store partition definitions including:
Partition ID information for bricks and racks
Associated prom environment variables.
Only a system administrator with superuser privilege can use this command. If the system is configured as CAP_NO_SUPERUSER, you must have effective capabilities of CAP_SHUTDOWN, CAP_DEVICE_MGT and CAP_SYSINFO_MGT. See the capabilities(4) man page for more information on the capability mechanism that provides fine grained control over the privileges of a process.
All the affected partitions have to be rebooted in order to change the system to the new partition scheme.
The partition ID of 0 has a special meaning in the operating system and cannot be used on a partitioned system. Valid partition IDs can be any number between 1 and 63, both included.
The term brick in this section refers to the C-brick module. The basic C-brick module contains four MIPS CPUs and up to 8GB of local memory.
In order to use the partmgr(1M) command, the following requirements must be met:
You must install the eoe.sw.partition software package.
The L1 and L2 firmware must be current.
You must enable partitioning administration in all L1s using the partdb enable L1 command.
The mkpd daemon must be running on all partitions for partmgr to work. If this is not the case, the partmgr command may not be able to shutdown remote partitions.
For the PROM to use the environment variables defined in the mode definition, the PROM environment variable AutoPROMVars must be set to 1.
See the partmgr(1M) man page for detailed information on this command.
The partmgr command-line syntax is as follows:
partmgr [-h]
partmgr [-l]
partmgr [-a]
partmgr [-n]
partmgr [-v]
partmgr -c [-m modename]
partmgr -x modename [-F]
partmgr -s modename [-F]
partmgr -i [-F]
partmgr -d [-F] -f file
partmgr -d [-F] -m modename -u [-e var=value]...
partmgr -d [-F] -m modename [-p part -b bricks [-e var=value]...]...
partmgr -d [-F] -m modename [-p part -r racks [-e var=value]...]..
The partmgr command supports the following options:
| -h | Help. Print a usage message. | |||
| -l | List brick IDs of all known system bricks to standard out. | |||
| -a | List all currently defined modes. | |||
| -n | Display the current partition ID. | |||
| -v | Display the environment variables for the current partition. | |||
| -c | Display mode configuration. If no mode is specified (-m modename), the current mode is displayed. | |||
| -x modename | Delete a mode. | |||
| -s modename | Set a mode to be the current mode. This may require some partitions to be rebooted. | |||
| -i | Same as -s Unpartitioned. Initializes the system to the default unpartitioned state. | |||
| -d | Define a new node. | |||
| -m modename | Specifies a mode name. This option is used with the -c and -d options. | |||
| -u | When defining a new mode, used to specify an unpartitioned system. | |||
| -p part | Specifies a partition ID. A partition ID is a number between 1 and 63, inclusive. The order of the -p, -b, -r and -e options is significant. See the partmgr(1M) man page. | |||
| -b bricks | Specifies brick IDs (example: 001c13) | |||
| -r racks | Specifies rack IDs (example: 001). | |||
| -e var=value | Specifies an environment variable name/value pair. | |||
| -f file | When defining a new mode, used to specify an input file. | |||
| -F | Forces override of some sanity checks. This option should be used with caution. The user of partmgr should understand the consequences of using this option.
|
Example 1.
To define a mode for an eight brick system with two partitions of four bricks each, perform the following;
partmgr -d -m modename -p 1 -b 001c10,001c13,001c16,001c21 -p 2 -b 001c24,001c29,001c32,001c35 |
Example 2.
To define a mode for an unpartitioned system with the prom environment variable AutoBoot set to No, perform the following:
partmgr -d -m modename -u -e AutoBoot=No |
Example 3.
The following three examples are of input files (-f option). The leading spaces are allowed, but not required; they are only added for readability.
a.
MODE modename1
PARTITION 1
BRICKS
001c10 001c13 001c16 001c21
ENVIRON
AutoBoot=No
PARTITION 2
BRICKS
002c10 002c13 002c16 002c21
ENVIRON
AutoBoot=No
OSLoadPartition=scsi(0)disk(1)rdisk(0)partition(0)
SystemPartition=scsi(0)disk(1)rdisk(0)partition(8)
|
b.
MODE modename2
PARTITION 1
RACKS
001 002
PARTITION 2
RACKS
003 004
|
c.
MODE modename3
UNPARTITIONED
ENVIRON
AutoBoot=No
OSLoadPartition=scsi(0)disk(1)rdisk(0)partition(0)
SystemPartition=scsi(0)disk(1)rdisk(0)partition(8)
netaddr=128.162.192.65
|
Figure 4-3 shows the configurations that are supported for system partitioning. For each configuration, it gives the total number of C-bricks, the number of C-bricks in each partition, and the maximum number of processors in a partition. For additional information, see the SGI Origin 3000 Owner's Technical Configuration Manual or your sales representative.
Metarouters are routers that only connect to other routers. They are needed in systems above 32 C-bricks systems.
Keep in mind the following guidelines when partitioning your system:
A partition must be made up of one or more 4-processor C-bricks.
Each partition must have a unique ID number between 1 and 63, inclusively.
Each partition must contain the following components:
The console of the lowest numbered C-brick in a partition becomes the console for that partition. (The original console remains the console for the partition that contains it.)
Each partition has its own set of PROM environment variables: ConsolePath, OSLoadPartition, SystemPartition, netaddr, and root.
All bricks in a partition must be physically contiguous. The route between any two processors in the same partition must be contained within that partition, and not through any other partition. If the bricks in a partition are not contiguous, the system will not boot.
On a SGI Origin 3000 series system, you can both add and remove certified controller cards while the system is powered on. Individual device drivers may support hot-plug insertion, hot-plug removal, neither, or both. If a driver supports both hot-plug insertion and removal, then you can replace cards supported by that driver in a running system.
Only certified device drivers support PCI hot-plug operations. These operations are available to drivers statically linked with the kernel and to loadable drivers. For information on specific certified device drivers, see your service representative.
| Note: Attempts to hot-plug insert or remove a card that does not have a certified driver will fail. |
Only 66 MHz cards can be installed in an empty bus. Cards that are installed in a bus where another card is already installed run at the same bus speed as the existing card. If installing the new card results in a bus speed mis-match with the existing card, the hot-plug operation fails. Since a Pbrick has six buses with two slots each, you can populate it at boot time to accommodate insertion of cards running at 33 and 66 MHz. A 66 MHz card can also be run at 33MHz and can be inserted into a 33 MHz bus.
Procedure 4-6 describes how you install a certified card such as a Qlogic Fiber Channel and SCSI controller card.
Procedure 4-6. Installing a PCI card Using the pciconfig Command
Insert a supported card into an empty PCI slot in a Pbrick or Ibrick of your running SGI Origin 3000 series system.
PCI cards are physically installed in a Pbrick or Ibrick. First, the card is mounted in a PCI carrier, which is then inserted into a slot in the back of the brick. Each slot in a brick can be identified by its bus and slot number label at the top of the slot. A tab is pushed to seat the card down into its slot.
For more detailed information about installing a PCI card, see the SGI Origin 3000 Series Owner's Guide that was provided with your system.
Bring the card online by using the pciconfig command.
In the following example, a pciconfig command powers up the PCI slot, determines the type of card installed, and calls the appropriate device driver to initialize the card and its software.
pciconfig -b /hw/module/001c16/Pbrick/bus/3/pci -s 1 -u
The -b option specifies /hw/module/001c16/Pbrick/bus/3/pci as the path to bus 3 in the Pbrick, the -s option specifies slot 1, and the -u option indicates that you want to hot-plug insert a card in the specified slot. For a description of these options, see the pciconfig(1M) man page.
Check the hardware graph for the new device entries.
After a successful hot-plug insertion, the system runs as if the card was installed at boot time. Typically, new device entries are found in the hardware graph.