|Contents||Bulletin||Scripting in shell and Perl||Network troubleshooting||History||Humor|
|News||Recommended Links||Forth||Getting Help in OpenBoot||NVRAM variables||OpenBoot Diagnostics|
|Forcing Solaria into OK prompt||System Run States||PROM Device Tree||The nvedit Line Editor||Humor||Etc|
The primary function of the OpenBoot firmware is to start up the system. Starting up is the process of loading and executing a standalone program (for example, the operating system or the diagnostic monitor). In case of Solaris the standalone program that is being started is the two-part operating system kernel. After the kernel is loaded, the kernel starts the Solaris OS, mounts the necessary file systems, and runs /sbin/init to bring the system to the initdefault state that is specified in /etc/inittab. Stages of this process is known as "System Run States".
The OpenBoot architecture consists of the following components:
The OpenBoot user interface is based on the programming language
Forth, which provides an interactive programming environment.
Forth is used for direct communication between humans and machines. It can be quickly expanded and
adapted to special needs and different hardware systems. Forth is used not only by Sun but also
by other hardware vendors such as Hewlett-Packard.
The normal Solaris boot process has five main phases:
Basic hardware detection (memory, disk, keyboard, mouse, and the like) and executing the firmware
system initialization program . In Solaris this is called Boot PROM phase—After
you turn on power to the system, the PROM displays system identification information and runs self-test
diagnostics to verify the system's hardware and memory. PROM chip contains Forth OpenBoot firmware,
and it is executed immediately after you turn on the system. The primary task of the OpenBoot firmware
is to boot the operating system either from a mass storage device or from the network. OpenBoot
contains a program called the monitor that controls the operation of the system before the
kernel is available. When a system is turned on, the monitor runs a power-on self-test (POST) that
checks such things as the hardware and memory on the system. If no errors are found, the automatic
boot process begins. OpenBoot contains a set of instructions that locate and start up the system's
boot program and eventually start up the Unix operating system.
Locating and running the initial boot program (IPL or bootloader) from a predetermined
location on the disk (MBR in PC). In Solaris the primary boot program, called bootblk,
is loaded from its location on the boot device (usually disk) into memory.
Locating and starting the Unix kernel. The kernel image file to execute may be determined
automatically or via input to the bootloader. In Solaris the bootblk program finds
and executes the secondary boot program (called ufsboot) from the Unix file system (UFS)
and loads it into memory. After the ufsboot program is loaded, the ufsboot
program loads the two-part kernel.
The kernel initializes itself and then performs final, high-level hardware checks, loading
device drivers and/or kernel modules as required. In Solaris the kernel initializes itself
and begins loading modules, using ufsboot to read the files. When the kernel has
loaded enough modules to mount the root file system, it unmaps the ufsboot program
and continues, using its own resources.
The kernel starts the init process, which in turn starts system processes (daemons) and initializes all active subsystems. When everything is ready, the system begins accepting user logins. In Solaris kernel starts the Unix operating system, mounts the necessary file systems, and runs /sbin/init to bring the system to the initdefault state specified in /etc/inittab. The kernel creates a user process and starts the /sbin/init process, which starts other processes by reading the /etc/inittab file. The /sbin/init process starts the run control (rc) scripts, which execute a series of other scripts. These scripts (/sbin/rc*) check and mount file systems, start various processes, and perform system maintenance tasks.
The following user query and control commands (forth words) are available on PCI based systems.
Use the show-pci-devs command to show all devices on a specific PCI bus.
Use the show-pci-devs-all command to show all PCI devices.
- ok show-pci-devs /pci@1f,2000 (show pcia devices)
- ok show-pci-devs /pci@1f,4000 (show pcib devices)
Use the show-pci-config command to show configuration space registers for a given PCI device.
- ok show-pci-devs-all (show all pci devices)
Use the show-pci-configs command to show configuration space registers for all PCI devices on a PCI bus.
- ok show-pci-config /pci@1f,4000/network@1,1
Use the show-pci-configs-all command to show configuration space registers for all PCI devices on all PCI busses.
- ok show-pci-configs /pci@1f,4000
Use the probe-pci command to probe all devices on a specific PCI bus.
- ok show-pci-configs-all /pci@1f,4000
Use the probe-pci-slot command to probe a specific PCI slot on a specific PCI bus.
- ok probe-pci /pci@1f,4000
- probing /pci@1f,4000 at Device 3 scsi disk tape
- probing /pci@1f,4000 at Device 3 nothing there
- ok 3 probe-pci-slot /pci@1f,4000
- probing /pci@1f,4000 at Device 3 scsi disk tape
Having the latest version of OpenBoot PROM (OBP) on a SPARC processor-based workstation or workgroup server can be critical when adding new applications or hardware, or when upgrading the machine's Solaris Operating System (OS). Updating may also save some time and difficulty by resolving any latent bugs that have been detected and fixed since the previous releases. The paragraphs that follow guide you through the steps required to do the update.
Note: This Tech Tip does not cover larger servers; for those systems, see SunSolve document #41723
The firmware in Sun's boot PROM is called OpenBoot. The main features of openboot are initial program loading, & debugging features to assist kernel debugging .OpenBoot supports plug-in device drivers which are written in language Forth. . This plug in feature allows Sun or any third-party vendors to develop new boot devices but without making any changes to boot PROM.
See also Solaris Booting problems error messages & solutions
Softpanorama hot topic of the month
OpenBoot > OpenBoot Environment
Sun's "OpenBoot 3.x Command Reference Manual", Chapter 1. (Used to be at http://docs.sun.com/db/doc/805-4436/6j4719c8a?a=view).
Solaris 9 System Startup and Shutdown
The following objectives for the Solaris System Administrator Exam are covered in this chapter:
Explain how to execute boot PROM commands to
- Identify the system's boot PROM version
- Boot the system; access detailed information
- List, change, and restore default NVRAM parameters
- Display devices connected to the bus
- Identify the system's boot device
- Create and remove custom device aliases
- View and change NVRAM parameters from the shell
- Interrupt a hung system
- Given a scenario involving a hung system, troubleshoot problems and deduce resolutions.
- Explain how to perform a system boot, control boot processes, and complete a system shutdown, using associated directories, scripts, and commands.
You need to understand the primary functions of the OpenBoot environment, which includes the programmable read-only memory (PROM. You need to have a complete understanding of how to use many of the OpenBoot commands and how to set and modify all the configuration parameters that control system bootup and hardware behavior.
You must understand the entire boot process, from the proper power-on sequence to the steps you perform to bring the system into multiuser mode.
You must be able to identify the devices connected to a system and recognize the various special files for each device.
Occasionally, conventional shutdown methods might not work on an unresponsive system or on a system that has crashed. This chapter introduces when and how to use these alternative shutdown methods to bring the system down safely.
You must understand how the system run levels define which processes and services are started at various stages of the boot process. You need to understand all the run levels that are available in Solaris.
You need to understand how to add and modify run control scripts to customize the startup of processes and services on Solaris systems. You need to have a detailed understanding of the programs and configuration files involved at the various run levels.
Booting a System
- Powering On the System
- The Boot PROM and Program Phases
The OpenBoot Environment
- Entry-Level to High-End Systems
- Accessing the OpenBoot Environment
- OpenBoot Firmware Tasks
The OpenBoot Architecture
The OpenBoot Interface
- The Restricted Monitor
- The Forth Monitor
Getting Help in OpenBoot
PROM Device Tree (Full Device Pathnames)
- OpenBoot Device Aliases
- The nvedit Line Editor
- Input and Output Control
OpenBoot PROM Versions
Booting a System
- The boot Command
System Run States
- The init Phase
- rc Scripts
- Using the Run Control Scripts to Stop or Start Services
- Adding Scripts to the Run Control Directories
- Commands to Shut Down the System
- The /usr/sbin/shutdown Command
- The /sbin/init Command
- The /usr/sbin/halt Command
- The /usr/sbin/reboot Command
- The /usr/sbin/poweroff Command
Stopping the System for Recovery Purposes
Turning Off the Power to the Hardware
Apply Your Knowledge
The following study strategies will help you prepare for the exam:
- When studying this chapter, you should practice on a Sun system each step-by-step process that is outlined. In addition to practicing the processes, you should practice the various options described for booting the system.
- You should display the hardware configuration of your Sun system by using the various OpenBoot commands presented in this chapter. You need to familiarize yourself with all the devices associated with your system. You should be able to identify each hardware component by its device pathname.
- You should practice creating both temporary and permanent device aliases. In addition, you should practice setting the various OpenBoot system parameters that are described in this chapter.
- You should practice booting the system by using the various methods described. You need to understand how to boot into single-user and multiuser modes and how to specify an alternate kernel or system file during the boot process.
- During the boot process, you should watch the system messages and familiarize yourself with every stage of the boot process. You should watch the system messages that are displayed at bootup. You need to understand each message displayed during the boot process from system power-on to bringing the system into multiuser mode.
- You need to thoroughly understand all the system run states, including when and where to use each of them. In addition, you must understand run control scripts and how they affect the system services. You should practice adding your own run control scripts.
- You should practice shutting down the system. You should make sure you understand the advantages and disadvantages of each method presented.
System startup requires an understanding of the hardware and the operating system functions that are required to bring the system to a running state. This chapter discusses the operations that the system must perform from the time you power on the system until you receive a system logon prompt. In addition, it covers the steps required to properly shut down a system. After reading this chapter, you'll understand how to boot the system from the OpenBoot programmable read-only memory (PROM) and what operations must take place to start up the kernel and Unix system processes.
Plagiarism?By David, Feb 3, 2004 05:11 PM Much of this seems to be copied, with minor modification, from Sun's "OpenBoot 3.x Command Reference Manual", Chapter 1. (Currently at http://docs.sun.com/db/doc/805-4436/6j4719c8a?a=view).
For example, the Sun documentation says: "OpenBoot deals directly with hardware devices in the system. Each device has a unique name representing the type of device and where that device is located in the system addressing structure."
In the this article, it's been changed slightly to read: "OpenBoot deals directly with the hardware devices in the system. Each device has a unique name that represents both the type of device and the location of that device in the device tree."
Sometimes, the minor changes alter the meaning. For example, the Sun doc says: "A full device path name is a series of node names separated by slashes (/). The root of the tree is the machine node, which is not named explicitly but is indicated by a leading slash (/). Each node name has the form:
In the copied version posted here, though, it's: "A device tree is a series of node names separated by slashes (/).The top of the device tree is the root device node. Following the root device node, and separated by a leading slash /, is a bus nexus node. Connected to a bus nexus node is a leaf node, which is typically a controller for the attached device. Each device pathname has this form:
The first sentence is incorrect, and the last sentence is confusing. It's each nodename that has that form, not the pathname, which is a series of slash delimited nodenames.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes. If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner.
ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no less then 90 days. Multiple types of probes increase this period.
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least
Copyright © 1996-2015 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License.
Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down currently there are two functional mirrors: softpanorama.info (the fastest) and softpanorama.net.|
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Last modified: June 04, 2016