I had a drive go bad. I have replaced the drive and have my system up. I have a 1-to-1 mirror raid. My mirrored boot drive brings the system up. I issued a reboot command. The system comes up gives me a login prompt and generates the error: failed write of utmpx entry:"i2".
What is i2?
The "i2" you see is the first two characters in the id of an inittab entry in the file /etc/inittab.
Per SCO's Technical Articles:
failed write of utmpx entry: xx
PROBLEM
The above error is known to happen when the init process is in the midst of creating an entry for the init job xx in the /etc/utmpx file, and gets interrupted by a SIGCLD signal, because some previously launched init job dies and needs to be cleaned up by init. Upon death of one of these child processes, the SIGCLD signal is generated and caught by init, which interrupts the current activity in order to perform the cleanup operation. Such "interruption" is usually normal. However, if a flurry of terminating init jobs happens at just the right time, the logging of another process by init in /etc/utmpx might fail with an internal error (i.e., "interrupted system call" or EINTR), and the console error shown above will appear. Of course, the end result is that the utmpx entry never gets logged.
SOLUTION
This problem has been reported to SCO Engineering. Currently, the workaround depends on the significance of the inittab entry in question and the impact of not recording the corresponding utmpx entry in /etc/utmpx:
1) if the inittab entry is configured by SCO by default, for example,
i2o1:23:once:/usr/sbin/i2otrans > /dev/console 2>&1
then you might simply remove the entry from inittab and the problem will disappear at the next reboot. In this example, the "i2otrans" job can usually be removed if you are not using an i2o-enhanced HBA. Make sure to make the appropriate omissions in /etc/conf/init.d as well, to prevent the inittab entry from reappearing upon the next kernel rebuild.
2) if the inittab entry must be retained, and the logging of the utmpx entry is also desired (e.g., if desired results from the "who" or "uptime" utilities require that proper utmpx logging by the targeted inittab entry occur) you might avoid the unfortunate timing window described above by simply moving the entry to a different location in the inittab file.
3) if the inittab entry must be retained but logging of the utmpx entry is not necessary, then nothing needs to be done. The occurrence of the console error message "failed to write utmpx entry" does not affect the proper startup of the system in any other way.