PACKAGE: Update Release 2.2.6.51
IOSLEVEL: 2.2.6.51
|
VIOS level is |
NIM Master level must be equal to or higher than |
|
Update Release 2.2.6.51 |
AIX 7100-05-05 or AIX 7200-04-01 |
Please refer to the VIOS Maintenance Strategy here for more details regarding the change to the VIOS release numbering scheme.
Be sure to heed all minimum space requirements before installing.
Review the list of fixes included in Update Release 2.2.6.51
To take full advantage of all the functions available in the VIOS, it may be necessary to be at the latest system firmware level. If a system firmware update is necessary, it is recommended that the firmware be updated before you update the VIOS to Update Release 2.2.6.51.
Microcode or system firmware downloads for Power Systems
If
the VIOS being updated has filesets installed
from the VIOS Expansion Pack, be sure to update those filesets with the latest VIOS Expansion Pack if updates are
available.
Update Release 2.2.6.51 updates your VIOS partition to ioslevel 2.2.6.51. To determine if Update Release 2.2.6.51 is already installed, run the following command from the VIOS command line.
$ ioslevel
If Update Release
2.2.6.51 is installed, the command output is 2.2.6.51.
Outdated Fileset Info
This release
removes the dependency on Java 7 from many filesets. If you would like to remove these filesets,
and Java 7 itself, which goes out of support in July 2022, you can use the
following command:
$
updateios -remove_outdated_filesets
Please ensure that your rootvg contains at least 30 GB and that there is at least 4GB free space before you attempt to update to Update Release 2.2.6.51. Run the lsvg rootvg command, and then ensure there is enough free space.
Example:
$ lsvg rootvg VOLUME GROUP: rootvg VG IDENTIFIER: 00f6004600004c000000014306a3db3dVG STATE: active PP SIZE: 64 megabyte(s)VG PERMISSION: read/write TOTAL PPs: 511 (32704 megabytes)MAX LVs: 256 FREE PPs: 64 (4096 megabytes)
LVs: 14 USED PPs: 447 (28608 megabytes)OPEN LVs: 12 QUORUM: 2 (Enabled)TOTAL PVs: 1 VG DESCRIPTORS: 2STALE PVs: 0 STALE PPs: 0ACTIVE PVs: 1 AUTO ON: yesMAX PPs per VG: 32512 MAX PPs per PV: 1016 MAX PVs: 32LTG size (Dynamic): 256 kilobyte(s) AUTO SYNC: noHOT SPARE: no BB POLICY: relocatable PV RESTRICTION: none INFINITE RETRY: no
If you are planning to update a version of VIOS lower than 2.1, you must first migrate your VIOS to VIOS version 2.1.0 using the Migration DVD. After the VIOS is at version 2.1.0, the Update/Fixpack 2.2.6.10 must be applied to bring the VIOS to the latest Fix Pack VIOS 2.2.6.10 level. The Update Release 2.2.6.51 can then be applied to bring the VIOS to the latest level.
Note that with this Update Release 2.2.6.51, a single boot alternative to this multiple step process is available to NIM users. NIM users can update by creating a single, merged lpp_source that combines the contents of the Migration DVD with the contents of this Update Release 2.2.6.51.
A single, merged lpp_source is not supported for VIOS that uses SDDPCM. However, if you use SDDPCM, you can still enable a single boot update by using the alternate method described at the following location:
SDD and SDDPCM migration procedures when migrating VIOS from version 1.x to version 2.x
After the VIOS migration is complete, from 1.X to 2.X, you must set the Processor Folding, described here under "Migration DVD":
Instructions to disable Processor Folding are detailed at the
link below.
See the "Migration DVD" section:
Virtual I/O Server support for Power Systems
VIOS Update Release 2.2.6.51 may be applied directly to any VIOS that is at either level 2.2.6.0 or 2.2.6.10.
On a VIOS with a level between 2.2.1.1 and 2.2.5.x, a Single Step update procedure can be used to update to level 2.2.6.51.
Instructions: Single Step Update
To update to Update Release 2.2.6.51 from a level between 2.2.1.1 and 2.2.5.x in a single step, put the 2.2.6.10 updates in the same location as your 2.2.6.51 updates and do the update using the updateios command.
Warning: The update may fail if there is a loaded media repository.
To check for a loaded media repository, and then unload it, follow these steps.
1. To check for loaded images, run the following command:
$ lsvopt
The Media column lists any loaded media.
2. To unload media images, run the following commands on all Virtual Target Devices that have loaded images.
$ unloadopt -vtd <file-backed_virtual_optical_device >
3.
To verify
that all media are unloaded, run the following command again.
$ lsvopt
The command output should show No
Media for all VTDs.
The Virtual I/O Server (VIOS) Version 2.2.2.1 or later, supports rolling updates for SSP clusters. The VIOS can be updated to Update Release 2.2.6.51 using rolling updates.
Version Specific Instructions: Version 2.2.1.3 or earlier.
A cluster that is created and configured on a VIOS at version 2.2.1.3 or earlier must be migrated to version 2.2.1.4 or 2.2.1.5 prior to utilizing rolling updates. This allows the user to keep their shared storage pool devices.
Version Specific Instructions: Version 2.2.1.4 or later.
The rolling updates enhancement allows the user to apply Update Release 2.2.6.51 to the VIOS logical partitions in the cluster individually without causing an outage in the entire cluster. The updated VIOS logical partitions cannot use the new SSP capabilities until all VIOS logical partitions in the cluster are updated.
To upgrade the VIOS logical partitions to use the new SSP capabilities, ensure that the following conditions are met:
· All VIOS logical partitions must have VIOS Update Release version 2.2.1.4 or later installed.
· All VIOS logical partitions must be running. If any VIOS logical partition in the cluster is not running, the cluster cannot be upgraded to use the new SSP capabilities.
Instructions: Verify the cluster is running at the same level as your node.
1.
Run the
following command:
$ cluster -status -verbose
2. Check the Node Upgrade Status field, and you should see one of the following terms:
UP_LEVEL: This means that the software level of the logical partition is higher
than the software level the cluster is running at.
ON_LEVEL: This means the software level of the logical partition and the
cluster are the same.
There is now a method to verify the VIOS update files before installation. This process requires access to openssl by the 'padmin' User, which can be accomplished by creating a link.
Instructions: Verifying VIOS update files.
To verify the VIOS update files, follow these steps:
1. $ oem_setup_env
2. Create a link to
openssl
# ln -s /usr/bin/openssl /usr/ios/utils/openssl
3.
Verify
the link to openssl was created
# ls -alL /usr/bin/openssl /usr/ios/utils/openssl
4. Verify that both files display similar owner and size
5. # exit
Use one of the following methods to install the latest VIOS Service Release. As with all maintenance, you should create a VIOS backup before making changes.
If you are running a Shared Storage Pool configuration, you must follow the steps in Migrate Shared Storage Pool Configuration.
Note: While running 'updateios' in the following steps, you may see accessauth messages, but these messages can safely be ignored.
Version Specific Warning: Versions between 2.2.1.1 and 2.2.5.x.
You must put the 2.2.6.10 and 2.2.6.51 on the same location to apply updates in single step. The single step approach fixes an update problem with the builddate on bos.alt_disk_install.boot_images fileset.
Version Specific Warning: Version 2.2.2.1, 2.2.2.2, 2.2.2.3, or 2.2.3.1
You must run updateios command twice to get bos.alt_disk_install.boot_images fileset update problem fixed.
Run the following command after the step of "$ updateios –accept –install –dev <directory_name >" completes.
$ updateios –accept –dev <directory_name >
Depending on the VIOS level, one or more of the LPPs below may be reported as "Missing Requisites", and they may be ignored.
MISSING REQUISITES:
X11.loc.fr_FR.base.lib 4.3.0.0 # Base Level Fileset bos.INed 6.1.6.0 # Base Level Fileset bos.loc.pc.Ja_JP 6.1.0.0 # Base Level Fileset bos.loc.utf.EN_US 6.1.0.0 # Base Level Fileset bos.mls.rte 6.1.x.x # Base Level Fileset
Warning: If VIOS rules have been deployed.
When the VIOS is the updated, some of the current rules may revert to the
system defaults. Additionally, those changes may have been applied to the
system.
If you notice this issue, the default rules can be re-deployed and captured to
current rules by running the commands below.
$ rules -o deploy -d
$ rules -o
capture
Note: This will overwrite any customized rules in the current rules file.
Applying Updates
Warning:
If the target node to be updated is part of a redundant VIOS pair, the VIOS partner node must be fully operational before beginning to update the target node.
Note:
For VIOS nodes that are part of an SSP cluster, the partner node must be shown in 'cluster -status ' output as having a cluster status of OK and a pool status of OK. If the target node is updated before its VIOS partner is fully operational, client LPARs may crash.
Note: The current level of the VIOS must be 2.2.2.1 or later if you use the Share Storage Pool.
Instructions: Applying updates to a VIOS.
2. Using ftp, transfer the update file(s) to the directory you created.
3. To apply updates from a remotely mounted file system, and the remote file system is to be mounted read-only, follow the steps:
$ shutdown -restart
Note: If shutdown –restart command failed, run swrole –PAdmin in order for padmin to set authorization and establish access to the shutdown command properly.
$ clstartstop -start -n <cluster_name > -m <hostname >
$ ioslevel
Instructions: Checking for an incomplete installation caused by a loaded media repository.
After installing an Update Release, you can use this method to determine if you have encountered the problem of a loaded media library.
Check the Media Repository by running this command:
$ lsrep
If the command reports: "Unable to retrieve repository date due to incomplete repository structure," then you have likely encountered this problem during the installation. The media images have not been lost and are still present in the file system of the virtual media library.
Running the lsvopt command should show the media images.
Instructions: Recovering from an incomplete installation caused by a loaded media repository.
To recover from this type of installation failure, unload any media repository images, and then reinstall the ios.cli.rte package. Follow these steps:
1. Unload any media images
$ unloadopt -vtd <file-backed_virtual_optical_device>
2. Reinstall the ios.cli.rte fileset by running the following commands.
To escape the restricted shell:
$ oem_setup_env
To install the failed fileset:
# installp –Or –agX ios.cli.rte –d <device/directory >
To return to the restricted
shell:
# exit
3. Restart the VIOS.
$ shutdown –restart
4. Verify that the Media Repository is operational by running this command:
$ lsrep
For additional details, including known capabilities, limitations, and additional install considerations, as well as some additional instructions, please reference the readme for 2.2.6.10 located here.
This version will include all fixes found in all previous 2.2.6.X releases. The fixes for the previous release can be found here.
|
APAR |
Description |
|
IJ16374 |
WITH IV92991 INSTALLED, FSCK MAY FAIL IN
"BMAP: INCORRECT SIZE" |
|
IJ11707 |
Very long lun names
prevent cfgmgr from configuring the lun |
|
IJ12244 |
VIO SERVER CRASH IN
INSERT_LARGESEND_OPTION - MBUF NOT PINNED |
|
IJ12470 |
HANG USING FAILOVER
ALGORITHM WHEN ADAPTER IS OUT OF CMD_ELEMS. |
|
IJ12640 |
SDK 8.0.0 64-bit SR5
FP27 - 18_04u2 |
|
IJ13155 |
2.2.6.301 UPDATE OF
IOS.ARTEX_PROFILE.RTE LIBVIOLOG.A NOT FOUND |
|
IJ14003 |
2.2.6.301 UPDATE OF
IOS.ARTEX_PROFILE.RTE LSATTR ERROR DISPLAYED |
|
IJ14059 |
SDK 7.0.0 32-bit SR10
FP40 |
|
IJ14062 |
SDK 7.0.0 64-bit SR10
FP40 - 19_01 |
|
IJ14064 |
SDK 8.0.0 64-bit SR5
FP30 - 19_01 |
|
IJ14444 |
CAA:CHCLUSTER NEEDS
FUNCTION TO REMOVE A GHOST DISK W/O HDISKX. |
|
IJ14599 |
VIOSUPGRADE -G CANNOT
HANDLE LIST FILE WITH EMPTY LINES |
|
IJ14734 |
KSH MAY OUTPUT
NON-ASCII CHARACTERS INCORRECTLY |
|
IJ15014 |
SDK 8.0.0 64-bit SR5
FP31 - 19_01u1 |
|
IJ15235 |
COMMANDS MAY HANG DUE
TO INFINITE RETRY OF GETFILESETSERVER |
|
IJ15345 |
CRASH IN
NPIV_FAIL_COMMAND AFTER DYNAMIC TRACKING EVENT |
|
IJ15457 |
ACCESS TO FABRIC
NAMESERVER COULD BE IMPARED IF LOGGED OUT |
|
IJ15458 |
ASSERT IN ADAPTER
DRIVER DURING ERROR RECOVERY |
|
IJ15488 |
Network not working
after viosupgrade |
|
IJ15526 |
Create 6.1 IPPs |
|
IJ15575 |
Create 6.1 IPPs |
|
IJ15678 |
Create 6.1 IPPs |
|
IJ15682 |
POOLFS STUCK STARTING
NEW SERVERS AFTER CHALLENGE DISK ERRORS |
|
IJ15992 |
System crash/hang in
npiv_stop_target_port |
|
IJ16016 |
SYSTEM CRASH DUE TO
IMPROPER T_LOCKCOUNT |
|
IJ16021 |
CLEARACA DURING
ADAPTER RESET NOT RETURNED TO DISK DRIVER |
|
IJ16065 |
VIOS crashes during
vhost adapter config in target_cdt_add |
|
IJ16225 |
FCSTAT -CLIENT MAY
REPORT CLIENT LPAR STAT UNDER THE WRONG HBA |
|
IJ16239 |
Update
bos.alt_disk_install.boot_images |
|
IJ16361 |
mbuf not DMA unmapped
in vioentdd |
|
IJ16362 |
PCIDMA error with NVMe
adapter |
|
IJ16364 |
DMA_ERR errlog
entries, adapters still configure |
|
IJ16365 |
Correct use of
ndd_parent_nddp pointer by SEA & Etherchannel |
|
IJ16366 |
Fix various Platform
Large Send related issues |
|
IJ16367 |
BACKUPIOS MAY FAIL
WITHOUT ANY ERROR MESSAGE |
|
IJ16368 |
Mutiple IPsec IKE
tunnels with IKEv2 PSK cannot be setup |
|
IJ16369 |
Unable to create
"test problem" from VIOS/IVM |
|
IJ16370 |
SEA becomes defined
state after enabling jumbo_frames. |
|
IJ16371 |
SSP logs slow disk IO
by mistake. |
|
IJ16372 |
TRACE CHANGES NEEDED
TO H_SEND_LOGICAL_LAN() FOR PERF TOOLS |
|
IJ16373 |
FAILURE MOUNTING 3RD
PARTY FILE SYSTEMS LIKE VXFS |
|
IJ16523 |
SSP snap or ffdc can
take longer than needed |
|
IJ16524 |
MFS pool start can
timeout due to large IOPGMap cache |
|
IJ16624 |
netstat prints some
messages incorrectly |
|
IJ16730 |
Segmentation fault in
srcmstr |
|
IJ16853 |
LKU operation may fail
with vios busy error. |
|
IJ16891 |
possible deadlock
between soshutdown and soreceive |
|
IJ16949 |
vio_daemon coredump @unnamed
block in getColumnDesciption |
|
IJ16989 |
VIOSUPGRADE FAILS TO
RESTORE THE INTERFACE WHEN REARRANGED |
|
IJ17019 |
topas/nmon is delaying
due to unknown lv's present in CuAt |
|
IJ17020 |
RMUSER FROM PADMIN
DOES NOT REMOVE ENTRY FROM /ETC/SECURITY/PASS |
|
IJ17021 |
During a firmware
update, the system dropped to KDB. |
|
IJ17060 |
NTPV3 MARCH 2019
SECURITY VULNERABILITIES |
|
IJ17074 |
Adapter performs
livedump on adapter parity error |
|
IJ17084 |
clstartstop fails to
start Node after addips |
|
IJ17134 |
partition migration
fails with large configurations |
|
IJ17135 |
System may crash
during certain error conditions |
|
IJ17235 |
System may crash
during error scenarios |
|
IJ17266 |
FC5899 RX may not work
properly when flow_ctrl was set to "no" |
|
IJ17397 |
SYSTEM CRASH IN
TSTART_MIGRATE() |
|
IJ17398 |
LSGROUP WITH -C AND -A
GIVES IMPROPERLY FORMATTED OUTPUT |
|
IJ17399 |
RMTCPIP -ALL REMOVES
LOCALHOST ADDRESS FROM HOSTS FILE |
|
IJ17400 |
Improving the name
resolution using /etc/hosts file. |
|
IJ17402 |
viosupgrade is failing
to create mksysb with ISOimage |
|
IJ17447 |
ADAPTER OPEN MIGHT
HANG UNDER CERTAIN ERROR CONDITION |
|
IJ17449 |
viosupgrade is failing
to create mksysb with ISOimage |
|
IJ17481 |
ikedb gives wrong
error message for IPSec_KeyOverlap |
|
IJ17482 |
IPSEC DOES NOT NEGOTIATE
WHEN IKEV2 IS CONFIGURED TO USE FQDN |
|
IJ17516 |
ike cmd=list db shows
incorrect IKE version and Remote ID |
|
IJ17520 |
VM migration fails if
SSP is down on source vios |
|
IJ17674 |
SHIENT_SW_ERR AND
LDMP_COMPLETE ERROR IN ERRPT |
|
IJ17754 |
REPLACEPV FAILS WHEN
PP SIZE OF A VG IS GREATER THAN 1024MB |
|
IJ17755 |
SYSTEM WITH LOW MEMORY
CAN CRASH IN LIO_LISTIO64() |
|
IJ17780 |
VIOS CRASHED IN
ngdisk_other_node_down |
|
IJ17781 |
WITH SEA USING MLXCENTDD
WITH DEFAULT FLIP_N_RUN=NO DEGRADES PER |
|
IJ17782 |
ikev2d leaks memory
during rekey |
|
IJ18033 |
spelling error in
viossecure command op. |
|
IJ18123 |
Adapter may not
recover from EEH resulting in IO Error |
|
IJ18148 |
WRITESRV DEAMON STUCK
LOOPING IN SIGSEGV CONSUMING CPU |
|
IJ18158 |
find_devices did not
fail when fc port disabled |
|
IJ18253 |
ADAPTER STATISTIC
RESET MAY FAIL IN RARE CASES |
|
IJ18359 |
AIX lpar crashed at
net_free |
|
IJ18360 |
alt_disk_mksysb reorders
ethernet logical device names |
|
IJ18361 |
adding bos.xerces to
NIM 6.1 lpp_sources |
|
IJ18363 |
cluster -create can
fail with viosecure high |
|
IJ18400 |
SEA: health_time from
CuAt might be out of new PdAt range |
|
IJ18498 |
IKEV2D COREDUMP IN
PROCESS_MSG |
|
IJ18499 |
Correct the TLSv1.1
flag name in ftpd.cnf |
|
IJ18500 |
Machine may hang
during controller failover on storage |
|
IJ18501 |
RNID ELS Response
Payload returns wrong size |
|
IJ18503 |
IO may fail during EEH
error conditions. |
|
IJ18504 |
Display transceiver
connection speed |
|
IJ18505 |
CHSEC DOESN'T MODIFY
LDAP_USER ATTRIBUTE W/O VALUE SPECIFIED |
|
IJ18556 |
DISABLE PLSO ON VEA
FOR LOADBALANCER |
|
IJ18557 |
Platform Large send
statistics are not reset after entstat -r |
|
IJ18558 |
Permanent EEH on
FC5899 after EEH gets injected |
|
IJ18559 |
IO may fail during EEH
error conditions |
|
IJ18580 |
Unable to create j2
filesystem on a super strict mirrorpool |
|
IJ18716 |
VLAN ACL status in VF
is not clear |
|
IJ18717 |
LPM validation fails
if vios has alredy 64 lpars on same FC port |
|
IJ18718 |
vioentdd not restoring
ndd_physaddr during close |
|
IJ18719 |
16MB size IO hang |
|
IJ18720 |
Incorrect resid value
reported to IBMi client |
|
IJ18721 |
DIFF COMMAND ON
DIRECTORIES FAILS ON NFS FILE SYSTEMS |
|
IJ18722 |
MEMORY LEAK IN LIBSM.A
GET_VGID_FROM_NAME |
|
IJ18736 |
SPLAT DUMPING CORE IN
0XE8A8 |
|
IJ18785 |
Potential crash on
reopen of device if reopen has failure |
|
IJ18914 |
One second delay when
opening ALUA disks |
|
IJ18916 |
Crash in
sn_start_mb_commands_timer: abend_trap |
|
IJ18918 |
FC5899 must signal
end-of-handling for interrupt offload |
|
IJ19255 |
NETSTAT -V LOGS
'PHYSICAL LINK DOWN' IN ERRPT -A |
|
IJ19256 |
cl_vg_fence_init hung
due to lock condition in disk driver |
|
IJ19257 |
System may crash if
memory allcoation fails |
|
IJ19259 |
SET_ADAPTER FAILS IF
THERE IS A BAD FC PORT ON SYSTEM |
|
IJ19263 |
viosupgrade fails to
identify the disk and shows prompt |
|
IJ19264 |
Etherchannel failover
takes more time after LPADUMP |
|
IJ19295 |
Excessive clusterwide snaps
being taken during election failure |
|
IJ19346 |
ISSUES WHEN TRYING TO
START PERSISTENT NMON VIA "SMITTY TOPAS" |
|
IJ19644 |
DSI - PROC
@percpu_iodone_offl+0004AC |
|
IJ19755 |
NVMe drive moved from
another OS does not work in AIX |
|
IJ19914 |
postgres connections
hang indefinitely if former DBN crashes |
|
IJ19915 |
commands are getting
hung |
|
IJ19996 |
Checksum error hit
after migrate -isolate |
|
IJ20117 |
Restarting VM on
different machine fails |
|
IJ20196 |
lpar got crashed
@abend_trap+000000 |
|
IJ20699 |
AIX SOFTWARE ERROR or
KDB running diag on EN0H adapter on POWER7 |
|
IJ20700 |
diag -cvd hung after
eeh on bell |
|
IJ20701 |
Diagnostic displays
random SFP speed test after wrap-plug test. |
|
IV46363 |
Change default option
for save replaced files. |