Comments (11)
  • Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

1 8manishk commented Permalink

Hello Anthony. <div>&nbsp;</div> 1. As you said, if one has a good copy of mksysb, best would be to assign a disk to an already running AIX and do alt_disk_mksysb. In this case, if this server is not on the same level as of mksysb, then you may need to install the same level of boot images as of the mksysb level. <br /> And you will not be able to do any post mortem unless dump is sent for analysis. <div>&nbsp;</div> OR <div>&nbsp;</div> 2. If one doesnt have mksysb too.... <br /> Assign the failed system's disk to a AIX partition of same level. Activate that partition, from its original AIX image, and run recreatevg on that failed system's disk with some prefix on fs and lv names. Mount all fs with their new name. Then may be we will be able to chroot into that and do some diagnostics ? This is just a thought, never tried this :-). What do you say ? <div>&nbsp;</div> Manish

2 AnthonyEnglish commented Permalink

Hi Manish, <div>&nbsp;</div> Thanks for the feedback. <div>&nbsp;</div> I've since found out that the logical partition booted from SAN, and that there was a problem with the SAN which led them to lose that LUN but (I think) not the whole SAN. As there was no other disk to capture the dump, they had no dump. But if your SAN goes down, or even a single LUN, I suppose it's obvious what brought the rootvg down anyway. You can have an additional rootvg "disk" which is not on the SAN, just to capture system dumps. Pretty messy to maintain all of that, though. <div>&nbsp;</div> Option 2: I'm not sure you'd even need to do a recreatevg, since that seems to be for duplicate LUNs. An importvg on a different host would be sufficient. However, that would rename LVs and FS mount points if there were any duplicate names, so you'd never be able to boot from that as rootvg again. <div>&nbsp;</div> I'd use that option if I needed to recover data, say a file from a single file system. However, if the problem was nothing more than the boot list, you'd have damaged the whole rootvg. Maybe do a replication on the SAN level first to a spare LUN, and then you could do the diagnosis with that spare LUN. <div>&nbsp;</div> Thanks for your comment, Manish. I would never have thought of that second approach you suggested. Shows the value of bouncing ideas off others. <div>&nbsp;</div> Anthony

3 8manishk commented Permalink

Hello Anthony <div>&nbsp;</div> Yes, correct, replicate that LUN and then do the diagnostics. <br /> So, keeping in mind that we dont have NIM, aix media, or mksysb to boot from... I am just expanding the 2nd option as below: <br /> 1. Bring that failed rootvg LUN on a running aix system. <br /> 2. Allocate one more empty LUN to this server. <br /> 3. clear boot records using chpv -c "hdisk#" <br /> 4. import rootvg_test from that LUN which will eventually rename all LVs and FSs. <br /> 5. chroot into rootfs of newly imported rootvg_test. <br /> 6. (( I am not sure here, what names it will show for LVs )) <br /> 7. once in chrooted environment, all the fs-names will be shown like normal rootvg fs names. I guess :-) <br /> 8. if LVs are too shown as normal rootvg LVs, then probably proceed with next step. <br /> 9. run alt_disk_copy for this chrooted environment rootvg into a new empty LUN for phase_option = 1 <br /> phase - 1 will just make backup and restore it on target disk into alt_inst fs/lvs. <br /> 10. exit this chrooted environment. <br /> 11. complete phase 2 and 3 for alt_disk_copy. ( remove &amp; install same level of boot images as of failed rootvg's ) <br /> 12. now should be able to boot off this new LUN. <div>&nbsp;</div> Need a lab to test this all :-) :-) <div>&nbsp;</div> Manish

4 AnthonyEnglish commented Permalink

Thanks, Manish. I'm not sure of how you'll go with steps 5, 6 and 7 but I'd be interested to see if you can do the recreatevg/importvg and then still use that as a bootable rootvg. LV names don't strictly matter - multibos renames LVs for rootvg, but the file system mount points are going to be more of a challenge. <div>&nbsp;</div> If you get this going in a lab environment, I'd love to see the results. <div>&nbsp;</div> Anthony

5 AnthonyEnglish commented Permalink

Following up on the previous comments, it looks like the proposal is not going to work. The chroot option is a Linux command but I'm not aware of it in AIX. <div>&nbsp;</div> There's still some work to be done on the possible solution or workaround, but an importvg or a recreatevg (which includes the importvg) to an existing AIX logical partition will rename logical volumes and mount points that are duplicate with the existing rootvg LVs and FS. That would render the new disk effectively no longer bootable as a rootvg disk, although the file systems might still be worth mounting under new names for the sake of data recovery. Data recovery, but not the entire rootvg as a living, workable OS. <div>&nbsp;</div> As the original problem was to do with the boot of the disk, the solution raised in the comments doesn't look like it will do the job. Still, I'm grateful for the idea as it gets a few of us thinking of how best to recover in a tricky situation like my colleague faced a few days ago.

6 Malcolm_Preen commented Permalink

re: comment 5. <div>&nbsp;</div> chroot does exist in AIX... (in 5.3 all the way up to 7.1) <div>&nbsp;</div> bos.rte.control <div>&nbsp;</div> it lives at /usr/sbin/chroot <div>&nbsp;</div> $ls -l /usr/sbin/chroot <br /> -r-xr--r-- 1 bin bin 3132 20 Jun 2011 /usr/sbin/chroot <br /> $lslpp -w /usr/sbin/chroot <br /> File Fileset Type <br /> ---------------------------------------------------------------------------- <br /> /usr/sbin/chroot bos.rte.control File <br /> $

7 AnthonyEnglish commented Permalink

Thanks for pointing that out about chroot, Malcolm. I haven't used it before. I'll have a look at the command documentation for it, which is here: http://bit.ly/UIqnbF

8 iroman commented Permalink

Hi Anthony, <div>&nbsp;</div> If they have an mksyb image, as you mentioned, the easiest way is to create a bootable .iso image from mksysb, boot from it and restore.

9 AnthonyEnglish commented Permalink

Creating an ISO image from mksysb using the mkdvd command would have been an option if they had physical access to the server and could assign a DVD-ROM to the LPAR, or a VIOS Virtual Media Library. When I said they didn't have media, I should have explained they didn't have access to a media drive either.

10 RickySan commented Permalink

Download a trial of Sysback?