I received two emails from different customers within a week – and both asked the same thing: Why is there a lib32 directory in Oracle 19.8.0 and 19.9.0? In one case, it was more like “We are wondering” but in the other case it caused issues during patching.
Photo by Erik Mclean on Unsplash
What happens?
Due to a packaging issue most likely, there is a lib32 directory appearing after you patch your homes to either 19.8.0 or 19.9.0. With the next RU, 19.10.0, this should not be the case anymore.
Why does this sound strage?
The first customer who raised this topic wondered about this directory as MOS Note: 883702.1 – $ORACLE_HOME/lib32 does not exist in Oracle database 11gR2 or higher. Why? tells you this for a looong time:
Starting from Oracle database 11gR2, 32-bit libraries are not being shipped with the 64-bit Oracle database server or 64-bit Oracle database client media. Hence after installing Oracle database 11gR2 or higher, you will not find lib32 folder inside $ORACLE_HOME.
If you want 32-bit libraries, you need to install 32-bit client which is shipped as a separate media. This should be installed only on a new Oracle home. You should neither install it on 64-bit server home nor on 64-bit client home.
So Chris’s findings and questions were very valid:
- What is the lib32/libacfs19.so doing on a 64-bit DB only installation that does not use ACFS?
- Why has the patch created so many lib32/libclntsh.so.* symbolic links to lib/libclntsh.so?
- Opatch rollback only removes lib32/libacfs19.so and leaves all the lib32/libclntsh.so.* symbolic links in place.
This does not look to be correct either.
I agree. And I investigated with the development team which confessed quickly a packaging error 19.9.0.
$ cd /u01/app/oracle/product/19/lib32 $ ls -lrt total 664 -rwxr-xr-x. 1 oracle dba 676424 Oct 8 06:34 libacfs19.so lrwxrwxrwx. 1 oracle dba 43 Oct 21 11:49 libclntsh.so.10.1 -> /u01/app/oracle/product/19/lib/libclntsh.so lrwxrwxrwx. 1 oracle dba 43 Oct 21 11:49 libclntsh.so.11.1 -> /u01/app/oracle/product/19/lib/libclntsh.so lrwxrwxrwx. 1 oracle dba 43 Oct 21 11:49 libclntsh.so.12.1 -> /u01/app/oracle/product/19/lib/libclntsh.so lrwxrwxrwx. 1 oracle dba 43 Oct 21 11:49 libclntsh.so.18.1 -> /u01/app/oracle/product/19/lib/libclntsh.so lrwxrwxrwx. 1 oracle dba 41 Oct 21 11:49 libocci.so.18.1 -> /u01/app/oracle/product/19/lib/libocci.so [CDB2] oracle@hol:/u01/app/oracle/product/19/lib32
Actually, you may see the lib32 directory with 19.8.0 as well potentially but only in case you have ACFS. But I didn’t drill deeper here. Though, unpublished BUG 31424388 (Files added by APF in DBRU drop conflicts with ACFS Drop) had been filed for 19.8.0, and not for 19.9.0.
But how can this be solved? Can the directory simply removed?
The solution
Very straight forward. If the directory lib32 did not exist prior to patching to 19.8.0 and/or 19.9.0, you can safely delete it.
Be aware that even when you rollback 19.8.0 or 19.9.0 to 19.7.0 or below, the lib32 directory will remain. But you can delete it safely if it didn’t exist in your 19.7.0 (or lower) home before)
When will this be fixed?
With Oracle Database RU 19.10.0, there should no lib32 directory anymore. At least, there shouldn’t be a new one created. In case you kept it from previous 19.8.0 and/or 19.9.0 patch runs, you may delete it if it didn’t exist prior to patching.
Wait a bit … and the second customer?
Right, I almost forgot to tell you. There was another case. Robert alerted me that his patching attempt with 19.9.0 in a GI environment failed:
2020-11-25_08:36:16 Patch 31771877: 2020-11-25_08:36:16 Copy Action: Directory is not writeable: "/ora01/app/oracle/grid_infrastructure/19.0.0.0" 2020-11-25_08:36:16 'oracle.usm.deconfig, 19.0.0.0.0': Cannot copy file from 'libacfs19.so' to '/ora01/app/oracle/grid_infrastructure/19.0.0.0/lib32/libacfs19.so' 2020-11-25_08:36:16 ]
with very strange error seeking to write into GI’s home. But ‘/ora01/app/oracle/grid_infrastructure/19.0.0.0/lib32/libacfs19.so’ does not exist there.
The customer has an Oracle Restart environment, and wanted to patch from 19.6.0 to 19.9.0 DB RU. But he got stuck due to the above error.
At first, you’d think permissions may help. Or then, you may create the directory. And the latter may fix the problem when applying the patch as well most likely.
But the correct way to workaround this ACFS patching issue is to edit the actions.xml file once you unpacked the patch. Please remove the below entry for the lib32 directory from 31771877/etc/config/actions.xml:
<oracle.usm.deconfig opt_req="O" patch_level="3" version="19.0.0.0.0">
<copy backup_in_zip="false" file_name="lib32/libacfs19.so" name="libacfs19.so" path="%ORACLE_HOME%/lib32" retain_permission="true" shaolue="0F48E02B8CFBC500D5B25C54A6EC98B5C5BC76E4"/>
</oracle.usm.deconfig>
Robert couldn’t reproduce the issue when he setup the cluster again from scratch for testing.
But I would like to take the chance and thank Chris and Robert for their analysis and testing. This was really helpful to nail down the issues right away. And thanks to our dev team, too, which reacted very quickly and helped us here.
Further Information and Links
- MOS Note: 883702.1 – $ORACLE_HOME/lib32 does not exist in Oracle database 11gR2 or higher. Why?
- (Non public) MOS Note: 2731316.1 – Oct2020 Database Release Update – P31771877 Creates Lib32 Directory In ORACLE_HOME
- (Unpublished) BUG 31424388 – Files added by APF in DBRU drop conflicts with ACFS Drop (19.8.0)
- (Unpublished) BUG 32178263 – OCT2020 DATABASE RELEASE UPDATE – P31771877 CREATES LIB32 DIRECTORY IN ORACLE_HOME (19.9.0)
- Install and Patch in one single action with OUI
–Mike
