ITEM: Q6339L

mksysb limits

  AIX 3.2


  Customer had some questions on cloning systems from one system to
  another using mksysbs.  Sent him this fax        


The following terms are used in this document:

  The word "cloning" as used in the info means creating a
  mksysb on one machine and then restoring it on another

  These are the devices which the system can detect by looking
  at their hardware information. e.g., SCSI, Tape drives, 128
  port card etc.

  The system cannot detect the presence or absence of these
  devices automatically. e.g., ttys, printers, modems etc.

  The machine where mksysb was created.

  The machine where mksysb is being restored. Target machine
  could be same as the source machine.

  For the most reliable results when creating and installing a
  mksysb the following steps should be taken:

  a) power ON all devices and adapters on the source and
     target machines
  b) cards and adapters must be named in sequential order on
     the source machine
  c) you must have exactly the same cards and adapters in
     exactly the same slots on the source and target

The following are the known limitations of mksysb restore at
this time.

  Mksysb will not move non-detectable devices (e.g., ttys,
  printers etc.) defined on one type of adapter to a different
  type of adapter. e.g., ttys defined on a 16 port card on
  source machine will not be defined on 64 port card on target

  When restoring a mksysb created on one machine to another
  machine, the source machine must have software support for
  all the devices existing on the target machine. This would
  include all the LPPs required to support the target machine
  (e.g., FDDI) as well as all the PTFs required for the support
  of target devices (e.g., POWERPC chip support was not
  available until the 325 level).

  Mksysb removes the /dev directory completely and recreates
  it from the odm data bases. If the customer has created
  files in /dev directory without configuration methods to
  recreate them and proper entries in the odm data base, these
  files will not be restored on the target machine.

  Console attributes are not stored as part of mksysb and are
 not restored.  e.g., if you have console login disabled, on
  restoration of mksysb, it will be enabled.

  Restoration of mksysb could result in two or more devices of
  the same type having their names swapped. All of the
  customized attributes go along with the names and get
  swapped.  For example this could be a problem if you have
  two token ring cards.  The following is the reason this

  When restoring mksysb, the devices database is created
  fresh.  All of the detectable device are defined and
  configured from scratch and then mksysb defines the
  non-detectable devices and also updates the user modified
  attributes of detectable devices.

  When defining and configuring the detectable devices, the
  cards are configured in order starting with slot 1.
  Therefore, a card in slot 4 will be configured before a card
  in slot 5 and all the devices on card 4 will be configured
  before any devices on card 5. Thus, the cards will be named

  If in the original system they were not named sequentially,
  these devices will not be reconfigured properly if there are
  user modified attributes e.g., to check your adapter card
  device order you can enter:

        lsdev -C -s mca -F "location name" | sort.

  This problem could happen for adapter cards, tape drives,
  RANs etc.

  Mksysb defines the non-detectable devices matching the
  parent names and types. If the parent is renamed as
  explained in 5, these non-detectable devices could end up at
  wrong locations.  e.g.,

  a) Source machine has two 16 port cards, Card 1 is in 
     slot 05 and Card 2 is added later and is in slot 04. So,
     cards are named as
        card1 sa2       00-05
        card2 sa3       00-04

     Now when mksysb restores, cards are named by going
     through the each slot, so they will be named as
        card1 sa3       00-05
        card2 sa2       00-04

     Since, mksysb goes by name, all the devices (ttys and
     printers) defined on card1 will appear on card2 and vice

  When restoring a mksysb, all the devices should be powered
  on.  This also includes any external adapters eg RANs for
  128 port.  If they are not on, all the devices defined on
  these RANs will be incorrectly configured.

  If you are using 128 port card and some of the RANs are
  connected through modems, mksysb cannot restore theses


  This will work if the following conditions are met.

  a) The 128 port card is in the same slot on both the source
     and target machine.
  b) The RANs are not renumbered and are available after the
     restoration of mksysb.

  Run  the following command.

     /usr/lpp/bosinst/rda -d /etc/objrepos/CuDv.sav \\
                -a /etc/objrepos/CuAt.sav -s /tmp/config

  In some cases mksysb cannot define non-detectable devices.
  It creates the non-detectable devices by going through the
  parent name and type first.  If no match is found, it goes
  by the location. If the cards in the target machine are not
  in the same slot as the machine where mksysb was created,
  some of the devices may not be defined at all.

  e.g., Suppose a 16 port card is in slot 4 on the target
  machine.  In this case tty1 will not be defined on the
  target machine.

        SOURCE                                 TARGET

  00-04         Empty           -     |   16 port card   sa1
  00-05         16 port card    sa2   |   Empty          -
  00-06         64 port card    sa1   |   64 port card   sa2
  00-06-01-00   tty             tty1  |   -              -

  mksysb tries to define tty1 whose parent is sa2. Now sa2 on
  the target machine is different kind of adapter, so it goes
  by location.  But there is nothing in that location 00-05,
  so it is assumed that tty1's parent is not there and so the
  tty is not defined to the system.

  Although a mksysb done when the HACMP/6000-supplied CLVM
  (Concurrent Logical Volume Manager) is enabled appears to
  work, the following error message is displayed after booting
  from the mksysb tape and attempting to restore it:

     /usr/sbin/mklv; /usr/sbin/cluster/mode3: not found
     mklv vgrootvg is operating in concurrent mode operation
     not permitted. The install process has encountered the
     following error:
     mklv: failed return code 1.

  A similar error may appear for the /usr/sbin/extendvg
  command if the rootvg contains more than one physical

  This halts the restore, making the tape seem unusable. APAR
  IX40522 has been created for this problem.  One of the
  following workarounds can be used to resolve the immediate
  problem of not being able to use the mksysb tape created
  while CLVM was the active LVM:

  Workaround 1:

  To restore a mksysb backup image that was created while CLVM
  was the active LVM, boot the system from a set of "bosboot"
  diskettes (created while standard AIX LVM was the active
  LVM), at the Install/Maintenance menu select option 2 and
  continue with the install as you normally would, specifying
  the tape as the input device.

  Workaround 2:

  1. Boot off the mksysb tape as usual.
  2. Select "4 Start a limited function maintenance shell"
  3. Create a backup version of the standard LVM mklv &
     extendvg commands:

       a. Type backup -i and press Enter.
        You will be prompted to mount vol 1 on /dev/rfd0 and
        press Enter to continue.
       b. Type /usr/sbin/mklv and press Enter.
       c. Type /usr/sbin/extendvg and press Enter.
       d. Type CTRL D. This will result in a backup by name on
       the default device (/dev/rfd0) of the mklv and extendvg

  4.   Restore it to the system being booted from the mksysb
       tape. Use the "restore -xv" command to restore all
       files from the backup medium to the corresponding
       location in the RAM-based file system created when
       booting from the mksysb tape.

  5.  Continue with the restoration.

  It is still recommended that system backups using the mksysb
  command NOT be performed while the Concurrent Logical Volume
  Manager is the active LVM.  If you inadvertently do so
  however, the workaround described above should allow you to
  restore the mksysb tape.
  Note, one can see if a customer has clvm installed by
  entering the command 'lslpp -ah cluster.clvm'.
 '/usr/sbin/cluster/cllvm status' can be used to determine
  which version of LVM (standard AIX or clvm) is currently
  configured on a node.  Instructions for Enabling and
  Disabling CLVM can be found in the HACMP/6000 Administration

  If there is not enough space in the /tmp when mksysb was
  created, it can fail while restoring. At the very end of
  restoration, mksysb calls bosboot command, which can fail,
  if there is not enough space in /tmp.

  If this happens, you will get "0301-152 bosboot: not enough
  file space to create:" and will be prompted to go to
  maintence mode or continue. Go to the maintence mode and
  make some room in the /tmp by increasing the filesystem or
  removing some files and then run "bosboot" command.

Support Line: mksysb limits ITEM: Q6339L
Dated: January 1995 Category: N/A
This HTML file was generated 99/06/24~13:30:37
Comments or suggestions? Contact us