11.2.0.1GI in linux6.1 ohasdfailedtostartat/u0

Some errors occur when users install oracle11.2.0.1GI in redhat6.1. After the previous asmssh authentication is completed, the asmdbaasmadminasmoper group cannot be displayed during systemgroup installation, this is because this friend did not set up a grid group during the installation, and the new fish

Some errors occurred when installing oracle 11.2.0.1 GI on redhat 6.1. Xiaoyu remotely went to help with the installation. After the above asm ssh authentication was solved, during GI installation, the asmdba asmadmin asmoper group cannot be displayed in the system group installation stage. This is because this friend did not set up a grid group during installation, and the following sub-accounts are new.

Some errors occurred when installing oracle 11.2.0.1 GI on redhat 6.1. Xiaoyu remotely went to help with the installation. After the above asm ssh authentication was solved, during GI installation, the asmdba asmadmin asmoper group cannot be displayed in the system group installation stage. This is because this friend did not create a grid group during installation, after the new ainemo is created, but it still cannot appear, select and restart the machine to solve the problem.

However, the following error always occurs during root. sh execution.

CRS-4124: Oracle High Availability Services startup failed.
CRS-4000: Command Start failed, or completed with errors.
ohasd failed to start: Inappropriate ioctl for device
ohasd failed to start at /u01/11.2.0/grid/crs/install/rootcrs.pl line 443.

On Mos, I found the article 11gR2 ohasd Fails to Start (Document ID 1157905.1)

There are many reasons why ohasd can fail to start. This document provides some details to find out what is going wrong. It is applicable to 11.2.0.1 CRS under Linux X64, though some sections described here can apply to other platforms and are marked as 'generic'.

In each case you will need to make the requested changes and rerun the root.sh script. If root.sh prompts to say that

| CRS is already configured on this node for crshome=0 Cannot configure
| two CRS instances on the same cluster.
| Please deconfigure before proceeding with the configuration of new home.

then you must run the deconfigure setup before rerunning root.sh.
The deconfigure process is described in Note 942166.1

1. "ohasd failed to start: Inappropriate ioctl for device":

Please reference Note 1069182.1 for troubleshooting "OHASD Failed to Start".
Actually the "ioctl for device" part of the message looks relevant but is in fact a red herring.
This is unpublished bug 9648820, fixed in 11.2.0.2.0 (unpublished bug 10122468)

Solution 1 corresponds to the same installation scenario. oracle proposed that this was an undisclosed bug and was resolved in version 11.2.0.2, this bug occurs in linux 6.1. If it does not exist in linux 5, it is not clear whether other linux 6 versions exist.

2. Many known causes is listed in note 1050908.1, refer to Section "Case 1: OHASD.BIN does not start" of the note for details.

3. CRS-4124, CRS-4000 could be due to have configured IPv6 instead of IPv4. Problem described on Bug 9065141 (Closed, Not a bug).
IPv6 is not supported with 11GR2 release of RAC. Reference: http://www.oracle.com/technetwork/database/enterprise-edition/oracledatabaseipv6sod-2141330.pdf
Configure IPv4 as indicated on "Oracle Clusterware Installation Guide" and restart a new fresh installation
Notice that IPv4 and IPv6 can coexist on moderm systems, so you don't need to disable IPv6, just do not use it for RAC configurations

This article describes how to enable ip6 and the ohasd cannot be started.

4. Check if init.ohasd is running (generic)

init.ohasd is used to control ohasd (which runs as a binary 'ohasd.bin').
If init.ohasd is not running ohasd won't be able to start.
# ps -ef | grep init.ohasd
root 14324 1 0 Jul16 ? 00:00:00 /bin/sh /etc/init.d/init.ohasd run

init.ohasd is spawned by an entry in /etc/inittab. This is picked up when the machine boots. The scripts run by root.sh will create an entry in /etc/inittab and then call init (s_crsconfig_lib.pm) to start init.ohasd.

If you have no init.ohasd running then
check /etc/inittab contains

h1:35:respawn:/etc/init.d/init.ohasd run >/dev/null 2>&1

5. Check if ohasd.bin is actually running (generic)

It's possible that the error reported is just because of a slow startup of ohasd. So check if it really started:
[root@gbr10094]# ps -ef | grep ohasd.bin

root 23763 1 0 Jul16 ? 00:00:04 /u01/app/oracle/product/11.2.0/crs/bin/ohasd.bin reboot

If you selected a Standalone install (SIHA) then ohasd.bin should run as the crs owner. If configured for a cluster it will run as root.

If ohasd is running (it's probably worth checking 5 minutes after the root.sh error) then everything may actually be okay

Check status of OHAS and CRS stack. From the grid_home/bin directory run
# crsctl check crs
Output must display all stack ‘online’.

Here we will only discuss the solution to the first case. The solution to this bug is not found on mos. However, there are some statements on the network. The most common one is to execute root. sh is executed continuously on another terminal.

dd if=/var/tmp/.oracle/npohasd of=/dev/null bs=1024 count=1

The file does not exist at the beginning, but when root. sh is executed to adding daemon to inttab, the dd Command needs to be executed.
Peer user cert
Pauser cert
Adding daemon to inittab

Here, we recommend that you keep running the dd on another terminal. If an error is reported after the root. sh command is executed, the problem cannot be solved by specifying the dd.

Because the previous ainemo is not clear about this status, some information about root. sh must be uninstalled before the root. sh is re-executed.
/U01/11.2.0/grid/crs/install/roothas. pl-deconfig-force-verbose

Remember the location of the above script $ ORACLE_HOME/crs/install/roothas. pl. This is used to uninstall the root. sh, and a script for uninstalling RAC. The storage location is $ ORACLE_HOME/deinstall.

Follow the above root. when sh is running, running the dd command on another terminal is successful. However, some friends on the Internet mentioned that ohasd may not be able to start after the restart, you need to use the same method to manually crsctl start crs and then keep dd on another terminal. It seems that you really should not run the GI of 11.2.0.1 in linux 6.1. Here, we recommend that you install 11.2.0.2 or later.


Original article address: 11.2.0.1 GI in linux 6.1 ohasd failed to start at/u0, thanks to the original author for sharing.