Once the update is installed and committed you can run FLRTVC (Fix level recommendation tool vulnerability checker) to determine which efixes need to be installed. That way your update won't fail due to a locked fileset. Prior to any updates (efix or other) you should always run a commit to make sure everything is committed: updateios -commitįor updates you should also remove any efixes. You can still use emgr to check these are installed as follows: # emgr -P On VIO 3.1.3.14 there are two efixes that are needed (as of )-the one for lscore above and openssh_fix14.
Updateios -install -accept -dev /usr/local/software/flrtfixes/lscore_fix-vio So the file I need to copy into a directory is:. In my case it is 3.1.3.14 and there is a line in the file that shows: 3.1.3.14 key_w_fix To determine the correct file open the Advisory.asc file and search for the level you are running. Now I put the efix into its own directory (only copy the epkg.Z file for 3.1.3.14).
Igrade tips and tricks Patch#
On VIO 3.1.3.14 there is a patch for lscore which can be downloaded from:įtp./aix/curity/lscore_fix.tar
Igrade tips and tricks install#
Until recently I didn’t use updateios for putting on efixes, but it turns out that you can and should install efixes that way. I also do my SSH, SSL and Java updates the same way: updateios -dev /updates/javasshssl -install -accept updateios -dev /updates/vios31314 -install -accept I put all my VIOS updates into a directory and run updateios against that. This is typically done using the updateios -dev /path -install command. This is how we put on updates to a VIO server within a version (i.e. Most of us are familiar with the updateios command. If your rootvg is mirrored, then you can unmirror it and take a clone to the disk that was freed up.
If I have to back out later then I set the bootlist to hdisk1 and reboot the VIO on the old version. To take the clone I do the following: exportvg altinst_rootvg I have a second disk in the system that I use for this. I also always take a clone before I start. This protects me if there is a network or NFS issue during the update process. Additionally, although all of my updates live on an NFS server I copy them into a local filesystem and do the update from there. That protects me if something happens to the network on the VIO during my updates. I ssh to the HMC then use vtmenu to get a list of servers and LPARs and select the VIO server I want to work on. I always do my updates by logging into the VIO server via the HMC. You can then upload the snap to IBM.įor dual VIO, you should take a snap on both VIO servers so IBM gets the complete picture. You will need to rename this file to TS?. where TS? is the problem number for the case you open with IBM. If you’re using an SSP cluster then please pay careful attention to the instructions in the readme file specific to SSPs.ġ. The tips below are for VIO servers that are not running in an SSP cluster. Further reading added a few more tips as well. Many thanks to those who asked questions and provided suggestions during the session. During and after that presentation I picked up some tips that I would like to share here. Last month I presented on VIOS Top Tips to the Power Virtual Users Group.
0 kommentar(er)
