Solaris Boot Process


The boot process loads the binary kernel from a bootable system disk into physical memory, initializes the kernel structure, sets system tunable parameters, starts system processes and brings the system to a known, usable state.

the basic steps of booting are :

1. The 'boot' command reads and loads the bootblock into memory.
2. The bootblock locates and loads the secondary boot program, ufsboot, into memory and passes control to it.
3. Ufsboot locates and loads the core kernel images and the required kernel runtime linker into memory and passes control to the loaded kernel.
4. The core kernel locates and loads mandatory kernel modules from the root-disk directory tree and executes the main startup code.
5. The kernel startup code executes, creating and initializing kernel structures, resources and software components.
6. The system executes shell scripts from the system directories, bringing that system upto the init state specified in /etc/inittab.


The initial stage of the boot process requires support from system firmware, typically loaded into a PROM,
such that a bootable device can be addressed and that some minimal I/O functionality exists for reading of a promary bootblock.

For SPARC, the firmware is known as OpenBoot PROM or OBP and is written in forth programming language.

Immediately after system is powered on, OBP does the following :
1. Provide a Power-On Self Test or POST.
2. Test and initialize the system hardware.
3. Determine the hardware configuration.
4. Boot the operating system.
5. Provide interactive debugging facilities for testing hardware and software.

The OBP (Open Boot PROM) program loads the bootblk(located on physical disk sectors 1 through 15) primary boot program from the boot-device. A copy of the bootblk is available at /usr/platform/`arch -k`/lib/fs/ufs/bootblk. The utility dd(1) is used to copy the bootblock to the specified disk partition. If the bootblk is not present or needs to be regenerated, it can be installed by running the installboot command after booting from a CDROM or the network.

Then the secondary boot program, /platform/`arch -k`/ufsboot is run. This program loads the kernel core image files. If this file is corrupted or missing, a bootblk: can't find the boot program or similar error message will be returned.

The kernel is loaded and run. For 32-bit Solaris systems, the relevant files are:

    \* /platform/`arch -k`/kernel/unix
    \* /kernel/genunix

For 64-bit Solaris systems, the files are:

    \* /platform/`arch -k`/kernel/sparcV9/unix
    \* /kernel/genunix

As part of the kernel loading process, the kernel banner is displayed to the screen. This includes the kernel version number (including patch level, if appropriate) and the copyright notice.

The kernel initializes itself and begins loading modules, reading the files with the ufsboot program until it has loaded enough modules to mount the root filesystem itself. At that point, ufsboot is unmapped and the kernel uses its own drivers. If the system complains about not being able to write to the root filesystem, it is stuck in this part of the boot process.

The boot -a command singlesteps through this portion of the boot process. This can be a useful diagnostic procedure if the kernel is not loading properly.
/etc/system: The /etc/system file is read by the kernel, and the system parameters are set.

Then the kernel is initialized. The kernel creates PID 0 ( sched) and starts PID 1 (init).The sched process is sometimes called the "swapper".

The init process reads the /etc/inittab and /etc/default/init and follows the instructions in those files.

Then the rc scripts execute the files in the /etc/rc#.d directories. They are run by the /sbin/rc# scripts, each of which corresponds to a run level.
A system's run level defines what services and resources ae available to users. A system can be in only one run level at a time.
Presently, Solaris environment has eight run levels.

Run level                        Init State                                   Description
0                               Power-down state                       Shut down the operating system to safely power off the system
1                               Administrative state                    Allows accessing all available file systems with user login allowed.
2                               Multiuser state                            For normal operations. Multiusers can access the system. All daemons are running except the NFS
                                                                                    server daemons.
3                               Multiuser                                    For normal operations with NFS resource sharing available
4                               Alternative Multiuser state         Currently unavailable
5                               Power-down state                     To shut down the operating system to safely power it off
6                               Reboot state                              To shutdown the system to run level 0 and to reboot
s or S                        Single-user state                        To run as a single user with all file systems mounted and accessible.

 So thats is how Solaris boots after getting powered on. Please leave a comment if you want.

Please refer :
docs.sun.com  to know more or you can refer OpenSolaris source code  :  /usr/src/psm/stand/bootblks/common/boot.fth
To know more about Forth programming language, please refer :
http://www.forth.com/starting-forth/
http://www.softsynth.com/pforth/pf_tut.html

Thank you.

Comments:

nice article..
well written..
keep it up!
ATB,
~@ngshu

Posted by angshu on August 19, 2009 at 07:31 AM RET #

nice.. thanks.

Posted by parça kontör on August 19, 2009 at 06:34 PM RET #

thanks

Posted by kontor on August 19, 2009 at 06:35 PM RET #

thankyou

Posted by kontör on August 19, 2009 at 06:36 PM RET #

thank you

Posted by turkcell parça kontör on August 19, 2009 at 06:37 PM RET #

Dear Amrita,

Nice to read your technical article which is very well described and upto the point of the context of the theme taken. Even though I do not use Solaris, it is quiet interesting to know many issues behind the booting process. Really WORTH in spending time to read this article.

My heartiest wishes to come up with many more articles in the series.

One suggestion: Please organize the article which will increase the readability. Thanks ...

With regards
Rajendra

Posted by Dr Rajendra Prasath R on August 22, 2009 at 09:11 AM RET #

init 0 should drop it to firmware...useful for landing to OBP {ok} prompt//

Posted by Anshumali Sharma on August 24, 2009 at 10:42 PM RET #

Yes..
For more information, please refer to OpenBoot Command Reference Manual at docs.sun.com ...

Posted by Amrita Sadhukhan on August 26, 2009 at 06:53 AM RET #

Amrita,

can you explain more specific how does the boot block find ufsboot?

I'm trying to improve qemu emulation of 32 bit SPARCS so that it would be possible to run Solaris as a guest there.

Solaris 2.5.1 loads bootblock, then ufsboot and then fails with the message "(Can't deduct msgbuf from physical memory list)"

Solaris versions 2.6 - 9 load a bootblock and can not find ufsboot. "bootblk: can't find the boot program".

Can you tell me where the bootblk tries to load ufsboot to? For me it's important to understand, what is currently failing scsi/dma subsystem or mmu.

Also, it seems that under 64 bit Solaris, the boot block is a Forth program, and under 32 bit - an ELF executable. Do you know why?

Artyom

Posted by artyom on September 17, 2009 at 05:55 AM RET #

The boot(1M) program, ufsboot, is loaded from disk by the bootblock program which resides in the boot area of a disk partition.
# installboot /usr/platform/sun4u/lib/fs/ufs/bootblk /dev/dsk/{root-disk}
The prom can't read the bootblk from the fs, it reads it from the first block of the partition. instalboot puts the bootblk where
the prom expects it.
Hope I answered your question.

Posted by Amrita Sadhukhan on September 24, 2009 at 06:45 AM RET #

Not quite. The questions are, in what part of ram does bootblock load ufsboot, and how exactly does it search for ufsboot.

Does it make a whole fs scan?

Or does it know ufs, so it just reads the directory listing (probably multiple times, descending to /platform/`arch -k`/)?

Is the search algorithm different in 32- and 64- bit systems? Why does 64 bit Solaris use Forth boot loader whereas the 32 bit version an ELF program?

Posted by artyom on September 24, 2009 at 07:15 AM RET #

Very Informative. Thank you

Posted by Joy Young on October 27, 2009 at 06:11 AM RET #

as of update 6 ( 10/08 ) release, the ufsboot program is replaced by boot_archive, as part of SPARC newboot feature, also delivered in 137137-09.
So boot_archive is basically a miniroot that is managed bu bootadm and is generated during shutdown by svc.startd calling umountall, which calls bootadm to update the archive. The archive is loaded in ramdisk by bootblk and boot_archive then bootstraps the system to a state where it hands off control to the kernel once it has loaded enough modules etc.
Enda

Posted by Enda O'Connor on November 10, 2009 at 01:46 PM RET #

I am looking for this for a long time.

Posted by Daniel Zhou on November 04, 2010 at 12:49 AM RET #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Amrita Sadhukhan

Search

Recent Posts
Top Tags
Categories
Archives
« July 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
  
       
Today