ITEM: Q6339L
mksysb limits
AIX 3.2
Response:
Customer had some questions on cloning systems from one system to
another using mksysbs. Sent him this fax
LIMITATIONS OF MKSYSB RESTORATION.
The following terms are used in this document:
CLONING:
The word "cloning" as used in the info means creating a
mksysb on one machine and then restoring it on another
machine.
DETECTABLE DEVICES:
These are the devices which the system can detect by looking
at their hardware information. e.g., SCSI, Tape drives, 128
port card etc.
NON-DETECTABLE DEVICES:
The system cannot detect the presence or absence of these
devices automatically. e.g., ttys, printers, modems etc.
SOURCE MACHINE:
The machine where mksysb was created.
TARGET MACHINE:
The machine where mksysb is being restored. Target machine
could be same as the source machine.
SUMMARY:
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
machines.
The following are the known limitations of mksysb restore at
this time.
1)
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
machine.
2)
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).
3)
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.
4)
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.
5)
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
occurs:
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
sequentially.
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.
6)
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
versa!
7)
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.
8)
If you are using 128 port card and some of the RANs are
connected through modems, mksysb cannot restore theses
properly.
Workaround:
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
9)
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.
10)
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
volume.
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
commands.
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
Guide.
11)
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