I came across one unique parameter which I would like to share on our gurkulindia, specially for small business organisations where we dont have seperate power backups for DC.

Has anyone noticed while working on Solaris boxes if you will power down (init 5 or poweroff from LOM/ALOM/ILOM) the Solaris boxes, they wont come up automatically after physical power on (only LOM boots but No OS). Which is a serious concern if any power outage occur or any power unit failure occurs etc etc…

Ex: Suppose a power outage occurred in any DC and 100 Solaris boxes went down. Now after power restoration, you wont be able to see any Solaris Box up and running. Manual intervention is required and SA need to power on the boxes manually from LOM prompt. Practically this situation is highly unacceptable in any organisation and this is the default feature of Solaris.

After a long investigation and googling and PDF’s I safely landed on earth and the landmark is below. There is a parameter on LOM/ALOM (for Sparc arch.) and ILOM (for intel arch.) which you wont find in help. The default value for that parameter is FALSE which wont allow your OS instance to boot up and hence it just stuck and wait for manual intervention at LOM level only.

I have tested the same in large scaled Solaris environment while performing hardware replacements & upgrades, when the value is FALSE the server stuck at LOM and OS wont come up, on the other hand if the value is changed to TRUE and power restored the Box comes up. Full Story

Possible reasons for a boot failure:

1. The boot device cannot be opened.
2. The system cannot be be booted from unusable or stale plexes.
3. A UNIX partition is invalid.
4. There are incorrect entries in /etc/vfstab.
5. Configuration files are missing or damaged

Full Story

Boot arguments may include more than one string. All argument strings are passed to the secondary boot program; they are not interpreted by OpenBoot. If any arguments are specified on the boot command line, then neither the boot-file nor the diag-file nvram variable is used. The contents of the nvram variables are not merged with command line arguments.

For example, the command

ok boot -s

ignores the settings in both boot-file and diag-file; it interprets the string “-s” as arguments. boot will not use the contents of boot-file or diag-file. The commands                                 

ok boot net         

ok boot cdrom

have no arguments; they will use the settings in boot-file or diag-file, if they are set, as default filename and arguments and pass them to boot. Accordingly, if boot-file is set to the 64-bit kernel filename and you attempt to boot the installation CD with boot cdrom, boot will fail if the installation CD contains only a 32-bit kernel.

A. Common boot Syntax 

                        ok boot [device-specifier] [arguments]

 This behavior is found on most OpenBoot 2.x and 3.x based systems. Note that differences may occur on some platforms. Full Story

Here I’m discuss some simple checks that helps to troubleshoot problems with startup scripts. Full Story