Things that I can do while booted in Maintenance mode (boot -lm)

[Alzhy]

Okay.. in my current dilemma to clone a server, I will be opting to just use a "dd whole disk copy" of my refrence server, plug that disk in to my target server and "boot -lm" off of it.. first off to correct VG00...

Can I also mount root so that I can edit networking and hostname info at this boot state?....

Sorry.. I've been fastracking myself in HPUX environments and have been stumbling onto a lot of "walls"...

[Mark Grant]

Nelson, is there any particular reason why you can't use "Ignite" to clone these servers?

It would be a lot less of a headache.

[Shahul]

Hi,

Yes, You can activate VG and mount filesystems here. Not to be a problem.

Good luck
Shahul

[Alzhy]

Mark.. my marching order is to have an OS on this new server exactly the same as another reference server. This server does not have a tape drive nor a CDROM as it is a vPar. It has LAN connectivity and an Ignition install was to be the original plan BUT, I can not seem to use a make_net_recovery archive out of our reference server as an Ignite Image.. Whenever I try to use the archive file and do an archive_impact, it seems the make_net_recovery archive file is not the format that make_sys_image (the right way to create a golden Ignite image) creates .. even if I specify tar gz format out of my make_net_recovery command on the reference server..

And I could not make a golden image off of the reference server as it is operating 24x7 and make_sys_image litereally renders the server unusable while doing its thing of creating a golden image...

That is why I am just planning to do a complete dd copy of the reference server's OS to another disk, pop that disk in to the new server, boot -lm, do the VG gyrations to "right" vg00, and edit networking configuration...

[Shahul]

Nelson,

Your plan is OK, But it doesn't look like a nice one. You already mentioned that both of your systems has different configurations like one has CDROM and Tape, other doesn't. There may be more mismatches like this.

I would recommend a fresh install and patch it to same level as other is, then copy any other data if you require from old system through network or NFS..etc. Otherwise go for ignite.

Good luck
Shahul

[Alzhy]

Sahul,
Thanks.. why would it not be a nice one (the dd transported disk method)? Does'nt HP-UX rebuild its device files to suite what it sees locally on a server?

both servers are simialr in architecture, the only differences are the vdd-rom and tape drives...

[Shahul]

Nelson,

In HPUX device drivers are part of kernel. If both the systems are very similar and identical, IInd system may boot with other system's kernel. Not sure, many times doesn't succeeded due to kernel mismatches. It panics sometimes. So normally we install OS for different systems, avoid copying kernel across.

Your idea is not senseless. You can give a try like many other adminstrators.

Best of luck
Shahul

[Todd McDaniel_1]

Nelson,

I can't remember if I told you about our broot script... I will post it again...

You can find it in this link or attached...

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=370366

[Sridhar Bhaskarla]

Nelson,

One method (slightly dirty) is to use "steal the mirror" method if you have reasonably latest servers like L, N and up. And you should be confident enough to fix any kind of LVM issues.

Make sure mirror is good and bootable. Replace the mirror disk as if it is bad with a new one. Follow vgcfgrestore and restoring the mirror process.

Boot up the other server with the stolen mirror disk. You will need to put it in the same slot as of the old server. If it is part of serviceguard, then you may want to change the vgid using vgchgid command in -lm mode.

It's not the clean method than dd but it works. My preference goes to make_tape_recovery though.

-Sri

[Bill Hassell]

The dd method almost always fails unless the hardware is EXACTLY the same. You are making a copy of a running system (which means that the cloned copy will need fsck on all the filesystems) which has hardcoded I/O paths for every device in the current system. In the clone system, because it is vPAR, the I/O paths will be different, so as it boots, the new device files will be created. But the old device files are hardcoded in lvmtab so volume groups will fail to activate. There's a lot of work (needing some in-depth sysadmin experience) to fix all the problems.

[Duncan Edmonstone]

I'd add another point to what Bill said against using dd.

The problem with dd is that it copies *absolutley everything* on the disk *including* bad block tables etc... AND any differences in disk geometry won't be taken into account

So what you end up with on the other disk is a copy of your original disk, including potentially a set of bad blocks which are in fact OK.

Of course if both disks are virtually brand new and the same model, this aint so bad. But still not perfect.

If your disks are in fact LUNs of a disk array then you have no problem (as the disk array takes care of all the bad block relocation)

HTH

Duncan

[Scott Tinsley]

Nelson,

Any luck on getting a dd boot disk copy procedure? We are trying to perform a similar function, but our copies are made using EMC BCVs. We want to create a "Gold" untouched virgin boot disk. This disk would have all our required patches and common software used in all our environments. We then want to be able to make a copy of the GOLD boot and use this copy as a boot disk for a new HP N-Partition. I have seen the boot copy scripts. We have one that we run here. What is wrong with the copy script process is that it copies all the flaws you may have on your current boot env. If you want a virgin finished boot disk using the script, you would have to boot a copy of the GOLD boot back on the original nPar/server and then use the boot copy script to create a new one. Not very useful if you are now using the original nPar for real work or the orginal nPar is in a new configuration. Also, the copy script methods do not seem to take into account using the copy on a second server or nPar that may have a slightly different device path setup.

More to the point, did you get a process to work from the DD copy? I know under Solaris we could do this fairly easily. You might need to tweak the booted copy from single user, but it was a dependable and repeatable process.

Thanks

[Alzhy]

Scott, yes the dd approach works but make sure your dd disk(s) are the same geometry (CylHeadSec) as your source disk. The procedure is as follows:

1. present(move, plug, zone, etc) the dd'd disk to the server you want to bring it up

2. boot -lm

3. fix VG00 (if using LVM)
if you want detailed procs. i can post it as well.

4. reboot...

Done..

[Scott Tinsley]

Nelson,

Yes, that step "fix VG00" is what I am trying to figure out. I have a day or two to play with it, but I would appreciate it if you could post the steps needed to fix the boot volume group.

Scott

[Elmar P. Kolkman]

One way is to remove /etc/lvmtab and run 'vgscan -v'.

But I would still suggest to use ignite. I've never tried it, but doesn't ignite support a recovery hard disk? Some of the ignite guru's can tell you I guess.

And the mirror option is better then the dd option, since you might copy a very inconsistent disk if you do dd, because the system will keep running.

Add the disk to vg00 (remember: pvcreate -B and mkboot), mirror all LVOL's to the disk, but skip (for now) swap, then pull the disk from the system after you ran the 'sync' command. Then lvreduce all lvols again on the running system.
You now at least have a real snapshot.