1cfgadm(1M)              System Administration Commands              cfgadm(1M)
2
3
4

NAME

6       cfgadm - configuration administration
7

SYNOPSIS

9       /usr/sbin/cfgadm [-f] [-y | -n] [-v] [-o hardware_options]
10            -c function ap_id...
11
12
13       /usr/sbin/cfgadm [-f] [-y | -n] [-v] [-o hardware_options]
14            -x hardware_function ap_id...
15
16
17       /usr/sbin/cfgadm [-v] [-a] [-s listing_options]
18            [-o hardware_options] [-l [ap_id | ap_type]]
19
20
21       /usr/sbin/cfgadm [-v] [-o hardware_options] -t ap_id...
22
23
24       /usr/sbin/cfgadm [-v] [-o hardware_options] -h
25            [ap_id | ap_type]
26
27

DESCRIPTION

29       The  cfgadm command provides configuration administration operations on
30       dynamically reconfigurable hardware resources. These operations include
31       displaying  status, (-l), initiating testing, (-t), invoking configura‐
32       tion state changes, (-c), invoking hardware specific  functions,  (-x),
33       and obtaining configuration administration help messages (-h). Configu‐
34       ration administration is performed  at  attachment  points,  which  are
35       places  where system software supports dynamic reconfiguration of hard‐
36       ware resources during continued operation of Solaris.
37
38
39       Configuration  administration  makes  a  distinction  between  hardware
40       resources  that  are  physically  present  in  the machine and hardware
41       resources that are configured and visible to  Solaris.  The  nature  of
42       configuration  administration  functions are hardware specific, and are
43       performed by calling hardware specific libraries.
44
45
46       Configuration administration operates on an attachment point.  Hardware
47       resources  located  at  attachment  points can or can not be physically
48       replaceable during system operation, but are dynamically reconfigurable
49       by way of the configuration administration interfaces.
50
51
52       An  attachment  point  defines  two unique elements, which are distinct
53       from the hardware resources that exist beyond the attachment point. The
54       two  elements  of an attachment point are a receptacle and an occupant.
55       Physical insertion or removal of hardware resources occurs  at  attach‐
56       ment  points and results in a receptacle gaining or losing an occupant.
57       Configuration  administration  supports  the  physical  insertion   and
58       removal  operations as well as other configuration administration func‐
59       tions at an attachment point.
60
61
62       Attachment points have associated state and condition information.  The
63       configuration administration interfaces provide control for transition‐
64       ing attachment point states. A receptacle can exist  in  one  of  three
65       states:  empty,  disconnected or connected, while an occupant can exist
66       in one of two states: configured or unconfigured.
67
68
69       A receptacle can provide the empty state, which is the normal state  of
70       a  receptacle  when the attachment point has no occupants. A receptacle
71       can also provide the disconnected state if it  has  the  capability  of
72       isolating its occupants from normal system access. Typically this state
73       is used for various hardware specific testing  prior  to  bringing  the
74       occupant's  resources into full use by the system, or as a step in pre‐
75       paring an occupant for physical removal or reconfiguration. A  recepta‐
76       cle  in the disconnected state isolates its occupant from the system as
77       much as its hardware allows, but can provide  access  for  testing  and
78       setup. A receptacle must provide the connected state, which allows nor‐
79       mal access to hardware resources contained on any occupants.  The  con‐
80       nected state is the normal state of a receptacle that contains an occu‐
81       pant and that is not currently undergoing configuration  administration
82       operations.
83
84
85       The  hardware  resources  contained  on an occupant in the unconfigured
86       state are not represented by normal Solaris  data  structures  and  are
87       thus  not available for use by Solaris. Operations allowed on an uncon‐
88       figured occupant are limited  to  configuration  administration  opera‐
89       tions.  The  hardware  resources of an occupant in the configured state
90       are represented by normal Solaris data structures and thus some or  all
91       of  those  hardware  resources  can be in use by Solaris. All occupants
92       provide both the configured and unconfigured states,
93
94
95       An attachment point can be in one  of  five  conditions:  unknown,  ok,
96       failing,  failed, or unusable. An attachment point can enter the system
97       in any condition depending upon results  of  power-on  tests  and  non-
98       volatile record keeping.
99
100
101       An  attachment point with an occupant in the configured state is in one
102       of four conditions: unknown, ok, failing, or failed. If  the  condition
103       is not failing or failed an attachment point can change to failing dur‐
104       ing the course of operation if a hardware dependent  recoverable  error
105       threshold  is  exceeded.  If  the condition is not failed an attachment
106       point can change to failed during operation as a result of an  unrecov‐
107       erable error.
108
109
110       An  attachment  point with an occupant in the unconfigured state can be
111       in any of the defined conditions. The condition of an attachment  point
112       with  an  unconfigured  occupant  can  decay from ok to unknown after a
113       machine dependent time threshold. Initiating a  test  function  changes
114       the  attachment point's condition to ok, failing or failed depending on
115       the outcome of the test. An attachment point that does  not  provide  a
116       test  function can leave the attachment point in the unknown condition.
117       If a test is interrupted, the attachment point's condition can  be  set
118       to  the  previous  condition, unknown or failed. An attachment point in
119       the unknown, ok, failing, or failed conditions can be re-tested.
120
121
122       An attachment point can exist in the unusable condition for  a  variety
123       of  reasons, such as inadequate power or cooling for the receptacle, an
124       occupant that is unidentifiable, unsupported,  incorrectly  configured,
125       etc. An attachment point in the unusable condition can never be used by
126       the system. It typically remains in this condition until  the  physical
127       cause is remedied.
128
129
130       An attachment point also maintains busy information that indicates when
131       a state change is in progress or the condition is being reevaluated.
132
133
134       Attachment points are referred to using hardware  specific  identifiers
135       (ap_ids)  that  are  related to the type and location of the attachment
136       points in the system device hierarchy. An ap_id can not  be  ambiguous,
137       it must identify a single attachment point. Two types of ap_id specifi‐
138       cations are supported: physical and logical. A physical ap_id  contains
139       a  fully specified pathname, while a logical ap_id contains a shorthand
140       notation that identifies an attachment point in  a  more  user-friendly
141       way.
142
143
144       For example, an attachment point representing a system's backplane slot
145       number 7 could have  a  physical  ap_id  of  /devices/central/fhc/sysc‐
146       trl:slot7  while the logical ap_id could be system:slot7. Another exam‐
147       ple, the third receptacle on the second PCI I/O bus on a  system  could
148       have a logical ap_id of pci2:plug3.
149
150
151       Attachment points may also be created dynamically. A dynamic attachment
152       point is named relative to a base attachment point which is present  in
153       the system. ap_ids for dynamic attachment points consist of a base com‐
154       ponent followed by two colons (::) and a dynamic  component.  The  base
155       component  is the base attachment point ap_id. The dynamic component is
156       hardware specific and generated by the corresponding hardware  specific
157       library.
158
159
160       For  example, consider a base attachment point, which represents a SCSI
161       HBA, with the physical ap_id /devices/sbus@1f,0/SUNW,fas@e,8800000:scsi
162       and logical ap_id c0 . A disk attached to this SCSI HBA could be repre‐
163       sented by a dynamic attachment point with logical ap_id  c0::dsk/c0t0d0
164       where  c0 is the base component and dsk/c0t0d0 is the hardware specific
165       dynamic component.  Similarly  the  physical  ap_id  for  this  dynamic
166       attachment                point                would                be:
167       /devices/sbus@1f,0/SUNW,fas@e,8800000:scsi::dsk/c0t0d0
168
169
170       An ap_type is a partial form of a logical ap_id that can  be  ambiguous
171       and  not  specify  a  particular attachment point. An ap_type is a sub‐
172       string of the portion of the logical ap_id up to but not including  the
173       colon  (:)  separator.  For  example,  an ap_type of pci would show all
174       attachment points whose logical ap_ids begin with pci.
175
176
177       The use of ap_types is discouraged. The new select sub-option to the -s
178       option  provides  a  more  general and flexible mechanism for selecting
179       attachment points. See OPTIONS.
180
181
182       The cfgadm command interacts primarily with  hardware  dependent  func‐
183       tions contained in hardware specific libraries and thus its behavior is
184       hardware dependent.
185
186
187       For each configuration administration operation a service  interruption
188       can  be  required.  Should  the  completion  of  the function requested
189       require a noticeable  service  interruption  to  interactive  users,  a
190       prompt  is  output on the standard error output for confirmation on the
191       standard input before the function  is  started.  Confirmation  can  be
192       overridden  using  the  -y  or  -n  options  to always answer yes or no
193       respectively. Hardware specific options, such as test level,  are  sup‐
194       plied as sub-options using the -o option.
195
196
197       Operations  that  change  the  state  of  the  system configuration are
198       audited by the system log daemon syslogd(1M).
199
200
201       The arguments for this command conform to the  getopt(3C)  and  getsub‐
202       opt(3C) syntax convention.
203

OPTIONS

205       The following options are supported:
206
207       -a
208
209           Specifies  that  the  -l  option  must also list dynamic attachment
210           points.
211
212
213       -cfunction
214
215           Performs the state change function on the attachment  point  speci‐
216           fied by ap_id.
217
218           Specify  function as insert, remove, disconnect, connect, configure
219           or unconfigure. These functions  cause  state  transitions  at  the
220           attachment  point by calling hardware specific library routines and
221           are defined in the following list.
222
223           insert         Performs operations that allows the user to manually
224                          insert  an  occupant  or to activate a hardware sup‐
225                          plied mechanism that performs  the  physical  inser‐
226                          tion. insert can have hardware specific side effects
227                          that temporarily suspend activity in portions of the
228                          system.  In such cases the hardware specific library
229                          generates appropriate warning messages  and  informs
230                          the user of any special considerations or procedures
231                          unique to that hardware. Various  hardware  specific
232                          errors  can  cause this function to fail and set the
233                          receptacle condition to unusable.
234
235
236           remove         Performs operations that allow the user to  manually
237                          remove  an  occupant  or to activate a hardware sup‐
238                          plied mechanism to  perform  the  physical  removal.
239                          remove  can have hardware specific side effects that
240                          temporarily suspend activity in portions of the sys‐
241                          tem.  In  such  cases  the hardware specific library
242                          generates appropriate warning messages  and  informs
243                          the user of any special considerations or procedures
244                          unique to that hardware. Various  hardware  specific
245                          errors  can  cause this function to fail and set the
246                          receptacle condition to unusable.
247
248
249           disconnect     Performs  hardware  specific  operations  to  put  a
250                          receptacle in the disconnected state, which can pre‐
251                          vent an occupant from operating in a normal  fashion
252                          through the receptacle.
253
254
255           connect        Performs  hardware  specific  operations  to put the
256                          receptacle in the connected state, which  allows  an
257                          occupant  to operate in a normal fashion through the
258                          receptacle.
259
260
261           configure      Performs hardware specific operations that allow  an
262                          occupant's   hardware  resources  to  be  usable  by
263                          Solaris. Occupants that are configured are  part  of
264                          the  system  configuration  and  are  available  for
265                          manipulation by Solaris device manipulation  mainte‐
266                          nance  commands  (eg:  psradm(1M), mount(1M), ifcon‐
267                          fig(1M)).
268
269
270           unconfigure    Performs hardware specific operations that logically
271                          remove  an  occupant's  hardware  resources from the
272                          system. The occupant must  currently  be  configured
273                          and  its  hardware  resources  must not be in use by
274                          Solaris.
275
276           State transition functions can fail due to  the  condition  of  the
277           attachment  point  or  other hardware dependent considerations. All
278           state change  functions  in  the  direction  of  adding  resources,
279           (insert,  connect  and configure) are passed onto the hardware spe‐
280           cific library when the attachment point is in  the  ok  or  unknown
281           condition. All other conditions require the use of the force option
282           to allow these functions to be passed on to the  hardware  specific
283           library.   Attachment  point  condition does not prevent a hardware
284           specific library being called for related to the  removal  (remove,
285           disconnect and unconfigure), of hardware resources from the system.
286           Hardware specific libraries can reject state  change  functions  if
287           the attachment point is in the unknown condition.
288
289           The  condition of an attachment point is not necessarily changed by
290           the state change functions,  however  errors  during  state  change
291           operations can change the attachment point condition. An attempt to
292           override a condition and force a state change that would  otherwise
293           fail can be made by specifying the force option (-f). Hardware spe‐
294           cific safety and integrity checks can prevent the force option from
295           having any effect.
296
297
298       -f
299
300           Forces the specified action to occur. Typically, this is a hardware
301           dependent override of a safety  feature.  Forcing  a  state  change
302           operation  can allow use of the hardware resources of occupant that
303           is not in the ok or unknown conditions, at the  discretion  of  any
304           hardware dependent safety checks.
305
306
307       -h [ap_id | ap_type ... ]
308
309           Prints out the help message text. If ap_id or ap_type is specified,
310           the help routine of the hardware specific library for  the  attach‐
311           ment point indicated by the argument is called.
312
313
314       -l [ap_id | ap_type ... ]
315
316           Lists  the  state  and  condition  of  attachment points specified.
317           Attachment points can be filtered by using the -s option and select
318           sub-option.  Invoking  cfgadm  without one of the action options is
319           equivalent to -l without an argument. The format of the  list  dis‐
320           play  is controlled by the -v and -s options. When the -a option is
321           specified attachment points are dynamically expanded.
322
323
324       -n
325
326           Suppress any interactive confirmation and assume that the answer is
327           no.  If  neither -n or -y is specified, interactive confirmation is
328           obtained through the standard error output and the standard  input.
329           If  either of these standard channels does not correspond to a ter‐
330           minal (as determined by isatty(3C)) then the -n option is assumed.
331
332
333       -ohardware_options
334
335           Supplies hardware specific options to the main command option.  The
336           format  and  content  of  the  hardware option string is completely
337           hardware specific. The option string hardware_options  conforms  to
338           the getsubopt(3C) syntax convention.
339
340
341       -slisting_options
342
343           Supplies  listing options to the list (-l) command. listing_options
344           conforms to the getsubopt(3C) syntax  convention.  The  sub-options
345           are  used  to  specify  the  attachment  point selection criteria (
346           select=select_string),    the    type    of    matching     desired
347           (match=match_type),  order  of  listing (sort=field_spec), the data
348           that is displayed (cols=field_spec and cols2=field_spec), the  col‐
349           umn  delimiter  (delim=string) and whether to suppress column head‐
350           ings (noheadings).
351
352           When the select sub-option is  specified,  only  attachment  points
353           which  match the specified criteria will be listed. The select sub-
354           option has the following syntax:
355
356             cfgadm -s select=attr1(value1):attr2(value2)...
357
358
359           where an attr is one of ap_id, class or type. ap_id refers  to  the
360           logical  ap_id  field,  class  refers to attachment point class and
361           type refers to the type field. value1, value2, etc. are the  corre‐
362           sponding  values  to be matched. The type of match can be specified
363           by the match sub-option as follows:
364
365             cfgadm -s match=match_type,select=attr1(value1)...
366
367
368           where match_type can be either exact or partial. The default  value
369           is exact.
370
371           Arguments  to  the  select sub-option can be quoted to protect them
372           from the shell.
373
374           A field_spec is one or more data-fields  concatenated  using  colon
375           (:), as in data-field:data-field:data-field. A data-field is one of
376           ap_id,  physid,  r_state,  o_state,  condition,  type,  busy,  sta‐
377           tus_time, status_time_p, class, and info. The ap_id field output is
378           the logical name for the attachment point, while the  physid  field
379           contains the physical name. The r_state field can be empty, discon‐
380           nected or connected. The o_state field can be configured or  uncon‐
381           figured.  The busy field can be either y if the attachment point is
382           busy, or n if it is not. The type and info fields are hardware spe‐
383           cific.  The status_time field provides the time at which either the
384           r_state,  o_state,  or  condition  of  the  attachment  point  last
385           changed.  The status_time_p field is a parsable version of the sta‐
386           tus_time field. If an attachment point has an associated class, the
387           class  field  lists the class name. If an attachment point does not
388           have an associated class, the class field lists none.
389
390           The order of the fields in field_spec is significant: For the  sort
391           sub-option,  the first field given is the primary sort key. For the
392           cols and cols2 sub-options, the fields are  printed  in  the  order
393           requested.  The order of sorting on a data-field can be reversed by
394           placing a minus () before the data-field name within the field_sec
395           for  the  sort sub-option. The default value for sort is ap_id. The
396           defaults values for cols and cols2 depend on whether the -v  option
397           is  given:  Without  it cols is ap_id:r_state:o_state:condition and
398           cols2 is not set.  With  -v  cols  is  ap_id:r_state:o_state:condi‐
399           tion:info  and  cols2 is status_time:type:busy:physid:. The default
400           value for delim is a single space. The value  of  delim  can  be  a
401           string  of arbitrary length. The delimiter cannot include comma (,)
402           character, see getsubopt(3C). These listing options can be used  to
403           create parsable output. See NOTES.
404
405
406       -t
407
408           Performs a test of one or more attachment points. The test function
409           is used to re-evaluate the condition of the attachment point. With‐
410           out  a  test  level specifier in hardware_options, the fastest test
411           that identifies hard faults is used.
412
413           More comprehensive tests are hardware  specific  and  are  selected
414           using the hardware_options.
415
416           The  results  of  the  test  is used to update the condition of the
417           specified occupant to either ok if no faults are found, failing  if
418           recoverable  faults are found or failed if any unrecoverable faults
419           are found.
420
421           If a test is interrupted, the attachment point's condition  can  be
422           restored  to its previous value or set to unknown if no errors were
423           found or failing if only recoverable errors were found or to failed
424           if any unrecoverable errors were found. The attachment point should
425           only be set to ok upon normal completion of testing with no errors.
426
427
428       -v
429
430           Executes in verbose mode. For the -c, -t and -x options  outputs  a
431           message  giving  the  results  of each attempted operation. Outputs
432           detailed help information for the -h option. Outputs verbose infor‐
433           mation for each attachment point for the -l option.
434
435
436       -xhardware_function
437
438           Performs  hardware  specific  functions.  Private hardware specific
439           functions can change the state of a receptacle or occupant. Attach‐
440           ment  point  conditions  can change as the result of errors encoun‐
441           tered during private hardware specific functions.  The  format  and
442           content of the hardware_function string is completely hardware spe‐
443           cific. The option string hardware_function conforms to the  getsub‐
444           opt(3C) syntax convention.
445
446
447       -y
448
449           Suppresses  any interactive confirmation and assume that the answer
450           is yes.
451
452

USAGE

454       The required privileges to use this  command  are  hardware  dependent.
455       Typically,  a  default  system configuration restricts all but the list
456       option to the superuser.
457

EXAMPLES

459       Example 1 Listing Attachment Points in the Device Tree
460
461
462       The following  example  lists  all  attachment  points  except  dynamic
463       attachment points.
464
465
466         example# cfgadm
467
468           Ap_Id         Type        Receptacle      Occupant       Cond
469         system:slot0    cpu/mem     connected       configured     ok
470         system:slot1    sbus-upa    connected       configured     ok
471         system:slot2    cpu/mem     connected       configured     ok
472         system:slot3    unknown     connected       unconfigured   unknown
473         system:slot4    dual-sbus   connected       configured     failing
474         system:slot5    cpu/mem     connected       configured     ok
475         system:slot6    unknown     disconnected    unconfigured   unusable
476         system:slot7    unknown     empty           unconfigured   ok
477         c0              scsi-bus    connected       configured     unknown
478         c1              scsi-bus    connected       configured     unknown
479
480
481
482       Example 2 Listing All Configurable Hardware Information
483
484
485       The  following example lists all current configurable hardware informa‐
486       tion, including those represented by dynamic attachment points:
487
488
489         example# cfgadm -al
490
491           Ap_Id            Type         Receptacle      Occupant        Cond
492         system:slot0       cpu/mem      connected       configured      ok
493         system:slot1       sbus-upa     connected       configured      ok
494         system:slot2       cpu/mem      connected       configured      ok
495         system:slot3       unknown      connected       unconfigured    unknown
496         system:slot4       dual-sbus    connected       configured      failing
497         system:slot5       cpu/mem      connected       configured      ok
498         system:slot6       unknown      disconnected    unconfigured    unusable
499         system:slot7       unknown      empty           unconfigured    ok
500         c0                 scsi-bus     connected       configured      unknown
501         c0::dsk/c0t14d0    disk         connected       configured      unknown
502         c0::dsk/c0t11d0    disk         connected       configured      unknown
503         c0::dsk/c0t8d0     disk         connected       configured      unknown
504         c0::rmt/0          tape         connected       configured      unknown
505         c1                 scsi-bus     connected       configured      unknown
506
507
508
509       Example 3 Listing Selectively, Based on Attachment Point Attributes
510
511
512       The following example lists all attachment points  whose  class  begins
513       with  scsi,  ap_id  begins  with c and type field begins with scsi. The
514       argument to the -s option is quoted to protect it from the shell.
515
516
517         example# cfgadm -s "match=partial,select=class(scsi):ap_id(c):type(scsi)"
518
519         Ap_Id         Type          Receptacle      Occupant           Cond
520          c0          scsi-bus      connected       configured         unknown
521          c1          scsi-bus      connected       configured         unknown
522
523
524
525       Example 4 Listing Current Configurable Hardware Information in  Verbose
526       Mode
527
528
529       The  following  example lists current configurable hardware information
530       for ap-type system in verbose mode:
531
532
533         example# cfgadm -v -l system
534         Ap_Id                      Receptacle Occupant   Condition Information
535         When         Type      Busy     Phys_Id
536         system:slot1               connected  configured ok
537         Apr  4 23:50 sbus-upa  n        /devices/central/fhc/sysctrl:slot1
538         system:slot3               connected  configured ok        non-detachable
539         Apr 17 11:20 cpu/mem   n        /devices/central/fhc/sysctrl:slot3
540         system:slot5               connected  configured ok
541         Apr  4 23:50 cpu/mem   n        /devices/central/fhc/sysctrl:slot5
542         system:slot7               connected  configured ok
543         Apr  4 23:50 dual-sbus n        /devices/central/fhc/sysctrl:slot7
544
545
546
547
548       The When column represents the status_time field.
549
550       Example 5 Testing Two Occupants Using the  Hardware  Specific  Extended
551       Test
552
553
554       The  following  example tests two occupants using the hardware specific
555       extended test:
556
557
558         example# cfgadm -v -o extended -t system:slot3 system:slot5
559         Testing attachment point system:slot3 ...  ok
560         Testing attachment point system:slot5 ...  ok
561
562
563
564       Example 6 Configuring an Occupant Using the Force Option
565
566
567       The following example configures an occupant in the  failing  state  to
568       the system using the force option:
569
570
571         example# cfgadm -f -c configure system:slot3
572
573
574
575       Example 7 Unconfiguring an Occupant From the System
576
577
578       The following example unconfigures an occupant from the system:
579
580
581         example# cfgadm -c unconfigure system:slot4
582
583
584
585       Example 8 Configuring an Occupant at an Attachment Point
586
587
588       The following example configures an occupant:
589
590
591         example# cfgadm -c configure c0::dsk/c0t0d0
592
593
594

ENVIRONMENT VARIABLES

596       See  environ(5) for descriptions of the following environment variables
597       that affect the execution of cfgadm: LC_TIME, LC_MESSAGES, NLSPATH  and
598       TZ.
599
600       LC_MESSAGES    Determines how cfgadm displays column headings and error
601                      messages. Listing output data is  not  affected  by  the
602                      setting of this variable.
603
604
605       LC_TIME        Determines  how  cfgadm  displays  human readable status
606                      changed time (status_time).
607
608
609       TZ             Specifies the timezone used when converting  the  status
610                      changed  time.  This  applies to both the human readable
611                      (status_time) and parsable (status_time_p) formats.
612
613

EXIT STATUS

615       The following exit values are returned:
616
617       0    Successful completion.
618
619
620       1    An error occurred.
621
622
623       2    Configuration administration not supported on specified target.
624
625
626       3    Usage error.
627
628

ATTRIBUTES

630       See attributes(5) for descriptions of the following attributes:
631
632
633
634
635       ┌─────────────────────────────┬─────────────────────────────┐
636       │      ATTRIBUTE TYPE         │      ATTRIBUTE VALUE        │
637       ├─────────────────────────────┼─────────────────────────────┤
638       │Availability                 │SUNWcsu                      │
639       └─────────────────────────────┴─────────────────────────────┘
640

SEE ALSO

642       cfgadm_fp(1M),      cfgadm_ib(1M),       cfgadm_pci(1M),cfgadm_sbd(1M),
643       cfgadm_scsi(1M),  cfgadm_usb(1M), ifconfig(1M), mount(1M), prtdiag(1M),
644       psradm(1M),  syslogd(1M),  config_admin(3CFGADM),  getopt(3C),  getsub‐
645       opt(3C), isatty(3C), attributes(5), environ(5)
646

DIAGNOSTICS

648       Diagnostic  messages  appear  on  the standard error output. Other than
649       options and usage errors, the following are  diagnostic  messages  pro‐
650       duced by this utility:
651
652         cfgadm: Configuration administration not supported onap_id
653
654
655
656         cfgadm: No library found for ap_id
657
658
659
660         cfgadm: ap_idis ambiguous
661
662
663
664         cfgadm: operation: Insufficient privileges
665
666
667
668         cfgadm: Attachment point is busy, try again
669
670
671
672         cfgadm: No attachment points with specified attributes found
673
674
675
676         cfgadm: System is busy, try again
677
678
679
680         cfgadm: operation: Operation requires a service interruption
681
682
683
684         cfgadm: operation: Data error: error_text
685
686
687
688         cfgadm: operation: Hardware specific failure: error_text
689
690
691
692
693       See  config_admin(3CFGADM)  for additional details regarding error mes‐
694       sages.
695

NOTES

697       Hardware resources enter the unconfigured pool in a  hardware  specific
698       manner.  This can occur at various times such as: system initialization
699       or as a result of an unconfigure operation. An occupant that is in  the
700       unconfigured  state  is  not available for use by the system until spe‐
701       cific intervention occurs. This intervention can be  manifested  as  an
702       operator  initiated command or it can be by way of an automatic config‐
703       uring mechanism.
704
705
706       The listing option of  the  cfgadm  command  can  be  used  to  provide
707       parsable  input for another command, for example within a shell script.
708       For parsable output, the -s option must be used to  select  the  fields
709       required.  The  -s option can also be used to suppress the column head‐
710       ings. The following  fields  always  produce  parsable  output:  ap_id,
711       physid,  r_state,  o_state,  condition,  busy status_time_p, class, and
712       type. Parsable output never has white-space characters embedded in  the
713       field value.
714
715
716       The  following  shell script fragment finds the first good unconfigured
717       occupant of type CPU.
718
719         found=
720         cfgadm -l -s "noheadings,cols=ap_id:r_state:condition:type" | \
721         while read ap_id r_state cond type
722         do
723              if [ "$r_state" = unconfigured -a "$cond" = ok -a "$type" = CPU ]
724              then
725                   if [ -z "$found" ]
726                   then
727                        found=$ap_id
728                   fi
729              fi
730         done
731         if [ -n "$found" ]
732         then
733                  echo "Found CPU $found"
734         fi
735
736
737
738
739       The format of the parsable time field  (status_time_p)  is  YYYYMMDDhh‐
740       mmss,  giving  the  year, month, day, hour, minute and second in a form
741       suitable for string comparison.
742
743
744       Reference should be made to the  hardware  specific  documentation  for
745       details of System Configuration Administration support.
746
747
748
749SunOS 5.11                        25 Oct 2004                       cfgadm(1M)
Impressum