The SSA disk are not showing up in service mode
model: r20 22.214.171.124
restoring and the ssa disk is not being recognized
Customer is trying to restore from a full system backup and
the 7133 SSA disk are not showing up in service mode.
Taken from the Sysback Manual Nov 1995 release page C-5
IBM 7133 Serial Storage Architecture (SSA) disk subsystem
The serial storage architecture provides a high-speed interconnection
technology for SSA disk drives. The drives and cables are hot-plugable,
allowing a disk drive to be replaced while the unit is operational.
Also, the location within the loop is transparent to AIX, allowing
a disk not currently in use to change locations without affecting
the operation of the system.
Since AIX does not keep track of the physical location of the disk
drive, it is not possible for Sysback to record and later reference
a disk by its physical location. Instead, Sysback will keep track
of the physical volume ID, which is unique to each individual disk
drive. Thus, when recreating a volume group on the same physical
disks as they were previously installed, all disks will be recognized
and automatically added to the volume group. However, when cloning
systems or when a drive has been replaced, the disk or disks will
appear as missing. The user may then use the option "Edit volume
group and logical volume attributes" to re-select the drives for
each volume group.
The AIX Version 3 operating system does not include the boot support
for the SSA disks. Therefore, the SSA disks cannot be be placed in
the rootvg volume group, since they are not identified during the
AIX or Sysback installation processes. It will therefore be necessary
to install the rootvg volume group onto other disks, then recreate
and restore the additional SSA volume groups from the Sysback System
Backup after the system has been installed and is running in normal
The SSA disks are supported as boot and install devices on AIX
Version 4. Therefore, the disks will be recognized by the Sysback
installation process, and may be selected and used in any volume
group, including the rootvg.
Closing with customer approval
Closing with Customer Approval
Customer is trying to recreate a volume group from smit and gets this
1800-034: Exit status: Return by command.
Found library item AC7491L which states that this is a known
bug in 126.96.36.199 and before. The customer is using 188.8.131.52, so
I don't understand why this bug still exists.
the smit command was similar to this:
remakevg -Ff /dev/rmt0 -N -v vgname
This is clearly the same problem. Had him run the command from
the command line and got these messages:
0516-404 alloc not enough resources available to fulfill allocation.
0516-822 mklv unable to create logical volume.
The command however ended successfully and it appeared to have worked.
The customer then started the restore. We are waiting to see if
the restore goes well, then we will try to understand what is giving
him the error.
Waiting on customer call back. Sending out the latest version of
Airborne Express \# 8676379154
The customer states sysback 184.108.40.206 did not restore
the mirroring correctly. I looked at the vginfo file
which seem correct, but the number of copies was 1.
So it really depends on how the system was setup pior
to the backup.
The customer is going to restore now, setting the number of
copies to 2. Then run the mkvginfo -Sf rootvg command and
look at the output. Ref A-41 of the sysback manual for a
complete understanding of the mkvginfo output
Not In, Left Message
The customer's had a tape with one bad spot on it.
Closing with customer apporval
It appears that even the backup commands failes trying to
backup/restore this data. The tar and cpio commands work.
When backup runs it prompts to insert the next tape in the drive,
even though it has not backed up that much data. I had
the customer send me the list of all the files in that vg, which
I still could not reproduce this problem on our system
I will have the customer send my a complete tar backup of this
Waiting on tape from the customer
I received the tape from the customer.
I restored the tar output and was able to reproduce the problem.
It appears the files in question are symbolic links that point
lrwxrwxrwx 1 root sys 0 Apr 5 10:46 tk2cansi.res ->
lrwxrwxrwx 1 root sys 0 Apr 5 10:46 tk2cavx3.res ->
lrwxrwxrwx 1 root sys 0 Apr 5 10:46 tk2cdec.res ->
lrwxrwxrwx 1 root sys 0 Apr 5 10:46 tk2cdgd2.res ->
lrwxrwxrwx 1 root sys 0 Apr 5 10:46 tk2cdgd4.res ->
lrwxrwxrwx 1 root sys 0 Apr 5 10:46 tk2chft.res ->
lrwxrwxrwx 1 root sys 0 Apr 5 10:46 tk2chftc.res ->
lrwxrwxrwx 1 root sys 0 Apr 5 10:46 tk2chp.res ->
lrwxrwxrwx 1 root sys 0 Apr 5 10:46 tk2ciris.res ->
lrwxrwxrwx 1 root sys 0 Apr 5 10:46 tk2clft.res ->
lrwxrwxrwx 1 root sys 0 Apr 5 10:46 tk2clftc.res ->
lrwxrwxrwx 1 root sys 0 Apr 5 10:46 tk2cncd.res ->
lrwxrwxrwx 1 root sys 0 Apr 5 10:46 tk2csun.res ->
lrwxrwxrwx 1 root sys 0 Apr 5 10:46 tk2csun5.res ->
I am not sure how this occurred?
Fixed with APAR IX57585
The backup (byname) command will prompt for a
second tape if it encounters a symbolic link
of zero length. These links arent of much use,
but can still be created with: ln -s "" name
Closing with customer approval
Support Line: The SSA disk are not showing up in service mode ITEM: BG2836L
Dated: April 1996 Category: N/A
This HTML file was generated 99/06/24~13:30:22
Comments or suggestions?