• Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

Comments (9)

1 AnthonyEnglish commented Permalink

Chris, the last line of your update from 14 Dec 2011 (about 'multibos -R' not cleaning up /bos_inst) made me curious, so I ran a test. My starting point was an AIX 7.1 system. The multibos cleanup operation looks to be fixed on AIX 7.1. I created a multibos instance on an AIX 7.1 logical partition (7100-01-00-0000) and logged into it successfully (multibos -s). The /bos_inst directory had several files and directories underneath it, as you'd expect. <div>&nbsp;</div> After logging out of the standby instance, the /bos_inst directory was there, but only contained the four mount points for the file systems that exist underneath /bos_inst <div>&nbsp;</div> /bos_inst # du <br /> 0 ./opt <br /> 0 ./usr <br /> 0 ./var <br /> 0 . <div>&nbsp;</div> Once again, no surprises. <br /> I then removed the multibos instance (multibos -R) and it removed ALL standby BOS file systems, including /bos_inst <br /> Removing all standby BOS file systems ... <br /> Removing standby BOS file system /bos_inst/opt <br /> Removing standby BOS file system /bos_inst/var <br /> Removing standby BOS file system /bos_inst/usr <br /> Removing standby BOS file system /bos_inst <div>&nbsp;</div> I then tried to change directory to /bos_inst and it was (thankfully) not there: <br /> cd /bos_inst <br /> ksh: /bos_inst: not found. <div>&nbsp;</div> This is on AIX 7.1, and since nimadm is only for going to a new AIX release, we'll have to wait for AIX 8 to come out to take advantage of this when migrating from AIX 7.1. Still, it looks to be solved. <div>&nbsp;</div> Next test: since AIX 6.1 TL 6 has many features backported from AIX 7.1, does multibos -R remove /bos_inst on AIX 6.1?

2 cggibbo commented Permalink

Thanks Anthony. Some very interesting tests. <div>&nbsp;</div> The same issue was found on several AIX 6.1 systems. <div>&nbsp;</div> I'm not sure if it's an issue with multibos or if there's an issue with the way the customer has used multibos in the past. I don't enough info to make a call either way.

3 cggibbo commented Permalink

One thing I will say however is.....perhaps a more meaningful error message such as '/bos_inst exists: please remove this directory and re-try the nimadm operation"....would be somewhat more useful than "alt_disk_copy: 0505-218 ATTENTION: init_multibos() returned an unexpected result." :) <div>&nbsp;</div> Cheers. <div>&nbsp;</div>

4 omahony commented Permalink

Chris <div>&nbsp;</div> Apologies for Necro'ing a thread, but I have something similar i was hoping you might have an idea. <div>&nbsp;</div> I am migrating AIX5.3 TL12 SP7 to AIX7.1 TL2 SP3. I created a lppsource and spot from the 7100-01-04 dvds, and upgraded that to 7100-02-03. <br /> The command i am using: <br /> nimadm -j devnim7_vg -c devdb3 -s spot_7100-02-03_full -l lpp_source_7100-02-03_full -d "hdisk2 hdisk3" -YV <div>&nbsp;</div> I get no errors in it, and the migration seems fine. I am keeping a mirrored pair of both rootvg's. <div>&nbsp;</div> However when I reboot into the new version, almost everything in opt is missing. Including the freeware which has my ssh configs etc. <div>&nbsp;</div> I kicked this off a second time, and watched. During the cachevg, the /opt folder didnt contain any of the folders. However, it had almos 2GB free, so it wasnt a space issue. <br /> This is then visible later in the migration logs when it is calling stuff from freeware or rpm, but it just skips it and continues. <div>&nbsp;</div> Its pretty awkward as getting downtime on this is quite hard, and i cant wake up the 7.1 alt_disk from an AIX5.3 <div>&nbsp;</div> So two questions: <br /> 1. Any help on what may be the cause? <br /> 2. Any way to get nimadm to pause or stop after phase 3 so i dont have to go through the whole process.

5 cggibbo commented Permalink

Hi omahony, <div>&nbsp;</div> Try installing the bos.alt_disk_install.rte for AIX 7.1 on the AIX 5.3 system. Then try the nimadm operation again. <div>&nbsp;</div> Cheers. <div>&nbsp;</div> Chris

6 AndreKoonings commented Permalink

Hi Chris, <br /> Try something different: <div>&nbsp;</div> Have you tried moving the AIX 5.3 partition to a WPAR? You can use an mksysb to recreate the system on a 7.1 lpar?

7 cggibbo commented Permalink

Hi AndreKoonings, <div>&nbsp;</div> Sure! <div>&nbsp;</div> Take a good look at Versioned WPARs. <div>&nbsp;</div> https://www.ibm.com/developerworks/community/blogs/aixpert/entry/aix_5_3_within_a_versioned_wpar_just_give_it_ago_it_s_easy1?lang=en <div>&nbsp;</div> Cheers. <div>&nbsp;</div> Chris

8 Tivoli-n-more commented Permalink

Brian, I bet I know what have hit you as suffered from it 18 months ago when I had to upgrade AIX 5.3 to 6.1 for a customer. The short answer is: "nimadm -j".

The long answer is the 32-bit legacy used by NIM to move the files from the NIM client to the master's cache VG. If there is a file larger than a 32-bit signed integer can accomodate (2GB-1B) in a rootvg filesystem the copy to the master is silently abandoned. If the file is buried deep in the FS tree, one will see the files/subdirs before it copied and all files/dirs in the directory and all its parents not copied.
The workaround is to use `find <FS> -xdev` and to identify all files larger than 2GB and to move them to a non-root VG. In your case you have a large file in /opt. Move/archive/delete it and re-run nimadm.</FS>

9 Tivoli-n-more commented Permalink

Chris, <br /> bos.alt_disk_install.rte on the AIX 5.3 will do no good. Hopefully no harm either. nimadm is running most of the commands from the master's SPOT. Maybe save the alt_rootvg creation but I am not sure either.

Add a Comment Add a Comment