Booting Process and Runlevels

-

Booting Process:

Solaris 10 contains 5 phases of booting process, but in Solaris 9 have only 4 booting process.

1. Boot PROM phase
2. Boot Program Phase
3. Kernel Initialization Phase
4. Init Phase

these phase contains both Solaris 9 & Solaris 10. but  from Solaris 10 onwards added extra phase that is,

5. Svc.started Phase.

I will explain in-depth what will happen in each phase.

Boot PROM Phase:


        when you switch on the machine it will start the boot PROM phase. In this phase  PROM runs the  PSOT( Power on self Test). in this test it will verify's the all the  Hardware attached to server.
Then PROM displays the Banner with System identification Number, Model type, Processor type, Processor speed, Keyboard status, RAM information, serial number, Ethernet address, Hostid.

In this Phase PROM locates the boot device by reading parameter boot-device. PROM reads the Disk vtoc on zero sector on default boot device PROM find the boot block located at 1-15 sectors. and it loads the boot block into the memory.

Boot Program Phase:


In this Phase primary boot block loads the  secondary boot program called as ufs boot block. which is installed by installboot command. ufs boot find and loads the appropriate Kernel.

Kernel Initialization Phase:


In this phase kernel loads itself, and kernel reads the /etc/system configuration file  and loads all the modules.

INIT Phase:


In this phase Kernel reads the /etc/inittab file and brings the server into appropriate Run level.  Kernel starts the master daemon svc.started daemon. which is responsible for the starting and stopping the services .

svc.started Phase:


 Svc.started daemon will starts the SMF. which is called master starter and re starter. It will mount all the local file systems and plumbs the network interfaces.

Run levels:


Run levels:

 It’s nothing but the system's state. We are having 8 different run levels:


Run levels Description


0-- This run level ensures that the system is running the PROM monitor.
s or S -- This run level runs in single user mode with critical file systems mounted & accessible.
1-- This run level ensures that the system running in a single user administrative, and it has access to all available file systems.
2 --In this run level system supports multiuser operations. At this run level, all system daemons, except the Network File System(NFS) server & some other network resource server related daemons, are running.
3 -- At this run level, the system supports multiuser operations. All system daemons including the NFS resource sharing & other network resource servers are available.
4 -- Not yet implemented.
5 -- This is intermediate run level between the OS shutdown /powered off.
6 -- This is a transitional run level when the OS shuts down & the system reboots to the default run level.
                                            
Determining the systems current run level:

#who -r

Changing the current run level using init command:
init s: Single user mode
init 1: Maintenance mode
init 2: Multi-user mode
init 3: Multi-user server mode
init 4: Not implemented
init 5: Shutdown/power off
init 6: shutdown & reboot
init 0: Shutdown & skips the maintenance to OBP

init s: When we are booting the machine to single user mode all the user logins, terminal logins, file system including all servers are disabled. The reason we are booting the server to the single user mode is for troubleshooting.

init 1: When the server is booting to maintenance mode the existing user logins will stay active & terminal logins get disconnected. Later on the new user & terminal logins both get disconnected. File Systems are mounted but all services are disabled.

init 2: It is the run levels where all the user logins, terminal logins, file systems including all services are enabled except NFS (Network File System) service.

init 3: It is default run level in SOLARIS. In this run level all the use logins, terminal logins, file system and all services are enabled including NFS.


Comments

Post a Comment

Popular posts from this blog

Veritas Cluster Server (VCS) Commands - Cheat Sheet

-
 LLT and GRAB VCS uses two components, LLT and GAB to share data over the private networks among systems. These components provide the performance and reliability required by VCS. LLT LLT (Low Latency Transport) provides fast, kernel-to-kernel comms and monitors network connections. The system admin configures the LLT by creating a configuration file (llttab) that describes the systems in the cluster and private network links among them. The LLT runs in layer 2 of the network stack GAB GAB (Group membership and Atomic Broadcast) provides the global message order required to maintain a synchronised state among the systems, and monitors disk comms such as that required by the VCS heartbeat utility. The system admin configures GAB driver by creating a configuration file ( gabtab). LLT and GAB files /etc/llthosts --> The file is a database, containing one entry per system, that links the LLT system ID with the hosts name. The file is identical on each server in the cluster. /etc...
Read more

Solaris 11.4 Network Administration Cheatsheet

-
 Here we discuss the Commonly used Network Commands for Solaris network Administration. How to list the Physical Network card's information : # dladm show-phys LINK            MEDIA         STATE      SPEED  DUPLEX    DEVICE net0            Ethernet      down       0      unknown   i40e0 net1            Ethernet      down       0      unknown   i40e1 net2            Ethernet      down       0      unknown   i40e2 net3            Ethernet      down       0      unknown   i40e3 net4            Ethernet    ...
Read more

Oracle Logical Domains (LDOM) Back up & Restoration from Backup Files

-
Saving Domain Configurations for Future Rebuilding The basic process is to save the resource constraints information for each domain into an XML file, which can then be re-issued to the Logical Domains Manager, for example, after a hardware failure to rebuild a desired configuration. Restore a Domain Configuration From an XML File ( ldm add-domain )  works for guest domains, but not for the control ( primary ) domain. You can save the  primary  domain's constraints to an XML file, but you cannot feed the file back into the  ldm add-domain -i  command. However, you can use the  ldm init-system  command and the resource constraints from the XML file to reconfigure your  primary  domain. You can also use the  ldm init-system  command to reconfigure other domains that are described in the XML file, but those domains are left inactive when the configuration is complete. The method that follows does not preserve actual bindings, only the ...
Read more