undefined reference to `nnfyboot'

When installing or relinking Oracle executables, it may be possible to see such error. The solution is :
1. Install addtitional packages (if not installed, 32bit packages such as glibc-32bit,glibc-devel-32bit,gcc-32bit and other required).
2. look through install.log and search messages kind of 'No such file or directory'. Try to fix errors (see item 1) and run all failed commands by hand in console, using oracle account.
For example, in following text

INFO: (if [ "compile" = "compile" ] ; then \
          echo "Building 32bit version of nnfgt.o"; \
          /opt/oracle/product/10gR2/db/bin/gennfgt > nnfgt.c ;\
          gcc -m32  -c nnfgt.c ;\
          rm -f /opt/oracle/product/10gR2/db/lib32/nnfgt.o ;\
          mv nnfgt.o /opt/oracle/product/10gR2/db/lib32/ ;\
          /usr/bin/ar rv /opt/oracle/product/10gR2/db/lib32/libn10.a /opt/oracle/product/10gR2/db/lib32/nnfgt.o ;\
          echo "Building 64bit version of nnfgt.o"; \
          /opt/oracle/product/10gR2/db/bin/gennfgt > nnfgt.c ;\
          gcc  -c nnfg
INFO: t.c ;\
          rm -f /opt/oracle/product/10gR2/db/lib/nnfgt.o ;\
          mv nnfgt.o /opt/oracle/product/10gR2/db/lib/ ;\
          /usr/bin/ar rv /opt/oracle/product/10gR2/db/lib/libn10.a /opt/oracle/product/10gR2/db/lib/nnfgt.o ; fi)

INFO: Building 32bit version of nnfgt.o

INFO: In file included from /usr/include/features.h:371,
                 from /usr/include/sys/types.h:27,
                 from nnfgt.c:7:
/usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or directory

INFO: mv: cannot stat `nnfgt.o': No such file or directory

INFO: /usr/bin/ar: /opt/oracle/product/10gR2/db/lib32/nnfgt.o: No such file or directory

INFO: Building 64bit version of nnfgt.o

INFO: r - /opt/oracle/product/10gR2/db/lib/nnfgt.o

The file gnu/stubs-32.h, needed to build 32-bit version of nnfgt.o, needed for construction of libclntsh.so, is absent. Install required package glibc-devel-32bit and run by hand above commands.

3. relink executables running relink command.

The active version of Oracle Clusterware is not 10g Release 2

Silent install of 10gR2 database on 12c or 11g clusterware environment fails with following error :

"The active version of Oracle Clusterware is not 10g Release 2"

Flags such as "-ignore..." don't help.

So the solution is to edit file /stage/prereq/db/db_prereq.xml and remove whole PREREQUISITE NAME="Detect10.2CRS" section, or remove its content,related to rules.

After that you'll be able to complete the installation. 

And don't forget to pin cluster nodes with:

/bin/crsctl pin css -n

Hanged or stalled Grid Infrastructure (11g or 12c) installation performing remote operations on Linux

The installation process goes fine, but suddenly is's stalled in the middle (50-60%) for unknown reason. That's becouse java installation process unable to transmit copied data (files and dirs) to oracle processes named ractrans, running on remote nodes in listening mode and basically performing all work for filling up remote oracle homes.

In my case that was becouse of sysctl.conf settings.

The content I had :

net.core.rmem_default = 25165824
net.core.wmem_default = 25165824
net.core.rmem_max = 25165824
net.core.wmem_max = 25165824
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
net.ipv4.tcp_rmem = 134217728 134217728 134217728
net.ipv4.tcp_wmem = 134217728 134217728 134217728
net.core.netdev_max_backlog = 300000

The content I had to modify :

net.core.rmem_default = 4194304
net.core.wmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_max = 262144
net.ipv4.tcp_rmem = 4096        87380   174760
net.ipv4.tcp_wmem = 4096        16384   131072
net.core.netdev_max_backlog = 1000

Honestly, I suspect, only net.ipv4.tcp_rmem and net.ipv4.tcp_wmem parameters play main role in this issue. Just in case I decided to set default values for other in the list above.

I.e., decreasing amount of memory per tcp socket and buffer space, slowing ethernet speed, took results.

P.S.

1. Just as surveillance. Oracle Universal Installer creates six (6) process per remote node to sync contents of grid_home. If you perform installation only for two nodes, you could not face with this issue.

2. It generally depends on speed of your public network stack. If you have fast enough switches and adapters, probably you will not bump into it.

3. It also depends on speed your storage (including mounting options). Any measure decreasing speed of copying files, can help.