Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Restore from mksysb fails ( on clone )

Status
Not open for further replies.

mkharris

Technical User
Nov 20, 2000
104
GB
If anyone has had any experience of the following problem ( or knows the answer anyway ) I'd be very grateful for their expertise.

I'm trying to clone one H80 from another ( slightly different config - the source m/c is multi-processor with rootvg mirrored on 2 x 9gb drives, and the target is uni-processor with 2 x 18gb. )

On the source, I've modified bosinst.data with 'RECOVER_DEVICES = no' . The source box is in use 24 x 7, so I've had to mksysb in-flight.

When I come to do the recover, I boot from the install cd, and then choose the option to install from a backup, without changing any default settings ( both disks have been pre-selected for installing ).

As the install progresses, it fails to unpack a series of log files:

Unpack: file out of phase
Unpack: internal unpacking error: decode failure
Restore: error during unpack of ....
Unpack: bad read of pipe
:Error 0
BOS Install: Restore of Base Operating System from rmt0 failed.


At this stage I felt not too concerned, as these were unneeded log files, and the install gave me the option to continue, which I did. Then after that I received:

BOS Install: Could not populate devices directory

( Option to continue, so I did.... )

BOS Install: Could not copy volume group information to the disk

( Option to continue, so I did.... )

Copying Cu* to disk

After this, the install just suspended.

If anyone has any ideas on this, I'd be very interested.

TIA
Mark
 
multiprocessor and uniprocessor systems are different
ie one has bos.mp fileset, another bos.up (you can have to add this fileset before you master mksysb tape ) and tape cloning will fail at various and no particular reasons anyway - why dont you boot off the install cd then? (might be a little bit different wear of tape drives ?) etc etc
 
But shouldn't the install process automatically add any filesets it needs from the CD, which I have started the boot from?
 
I dont know what happens there - but it fails more often than needed - like a bit different disk placement, so i assume mksysb tape is a great complement to roll !SAME! system back to last working point - but you can burn a CD with latest maintenance level (or export ML via NFS (install.images directory (-: ) to get your system up faster
 
Hello,
Why did you change this bosinst.data RECOVER_DEVICES=no

Do you understand what it does and if you make change how it is going to effect things.

 
I changed the RECOVER_DEVICES stanza so that it didn't try to copy the ODM customised objects. My understanding is that this is undesireable when you are cloning, because hardware addresses etc will be different. (?)
 
Unpack: file out of phase
means a tape problem (the rest is because the tape was soft-compressed)

 
Well, that's what I thought to start with. But I've tried 2 different tapes now, and the problem is the same. The 'file out of phase' part of the problem might not be so significant (?) - the files are active log files, so the byte counts are probably wrong once the end of file has been reached. The thing is, I can't quiesce the system for the backup, and those log files aren't important anyway.

I'm more concerned about the subsequent errors - 'Could not populate devices directory' etc. ( Unless they are a knock-on effect from the unpack failures. )
 
The workaround to the original problem was to do a network boot with the help of Storix. I just didn't have time to get to the root of the problem, but I think it could have been:

1. The install CD being fairly old, whereas the mksysb image had the latest AIX ML, or
2. The PP size of rootvg not being large enough for the 18Gb disks ( it was only 16Mb on the source system ), or
3. The mksysb image not having the bos.up fileset when the target system had only 1 cpu, or ( most likely )...
4. Something else.

Thanks to everyone who posted.
Mark
 
Not sure if this commentary helps... I have been (today even) making one machine into a clone of another quite frequently, crossing machine types often (usually H50,H70,H80,S70,S7A,S80). I use NIM and a mksysb image file, not tape. I am 99% sure that we use no special options such as modifying bosinst.data, unless NIM does something like that. We do all of our mksysb images in-flight (I like that term).

Of course since we use NIM, that takes care of such things as bos.mp vs bos.up issues and the various things you might see when making a H50 mksysb into a H80 machine.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top