1992.4.29

SUBJECT: Solaris 2.x Boot and Run Levels

 * Boot and Run Levels


   1. Booting에관련된 것들.


        SunOS 4.x와 비교하여 변화한것들은 다음과 같다.

         - 더이상 kernel을 만들 필요가 없다.

         - device들은 처음에 open될때 자동으로 load되기때문에,kernel memory 소비를 줄이게된다.

         - file system은 단지 필요가 있을때만 check되기때문에 boot time이 더 빨라진다.

         - boot program이 옮겨져도 더이상 booting시 error가 없다.

        Solaris 2.0의 boot model은 UNIX Software Laboratories(USL)의 일반적인 SVR4 방법과는 다르다.

        Solaris 2.0의 model은 SPARC system을 위해 더 적당한 model이다.

        하지만,Solaris 2.0은 SVR4의 boot절차를 따른다.

        예를들면,process control과 system관리는 일반적인 SVR4와 거의 같다.


   2. SunOS 4.x와 Solaris 2.0의 주요차이


      2가지 관점에서 큰 차이가 있다.

      1) boot model이 개선됨.

         (1) self-configuring kernel

         (2) loadable kernel modules

         (3) autoloading drivers

      2) 전통적인 SVR4를 적용

         (1) system run level

         (2) logical device names


   3. Self-configuring kernel


      Solaris 2.0 kernel은 small static core 와 많은 dynamically loadable kernel module들로 구성된다.

      많은 kernel module들은 booting시 자동적으로 load된다.

      booting시에 필요없는 device는 그 device가 사용될때 자동으로 add된다.

      Solaris 2.0은 static kernel을 만들 필요가 없다.

      그러므로,third party들에서  모든 kernel level code,device drive,STREAMS module들과 다른 kernel level 

      code는 loadable module들을 제공하여야 한다. 

      작은 static core는 /kernel하에 있게되고 , unix라고 불리운다.

      /etc/system은 booting시 자동적으로 load되는 것과 되지않는 것을 무시하여 사용되는 kernel configuration 

      file이다. ( SunOS 4.x에서의 param.c function과 비슷하다 )


   4. Directory layout

      - the kernel directory

        
     /kernel --------- /drv    ( Drivers ) - device drivers & pseudo drivers

                       /exec   ( exeec() modules ) - ELF , a.out

                       /fs     ( file systems ) - ufs , nfs , proc , fifo , etc

                       /misc   ( miscellaneous modules ) 

                       /sched  ( scheduling classes ) - schedulong classes & dispatch tables

                       /strmod ( STREAMS modules ) 

                       /sys    ( loadable system calls ) - system accounting & semaphore operations


   5. Bootprom differences


      1) no new bootproms required

         bootfile은 이름은 /kernel/unix이다.

      2) new boot options

         새로운 hardware를 붙일때,사용자는 reconfigure을 하려면 -r option을 사용하여야 한다.

         logical device name은 physical device name에로 link된다.
        
      3) booting시에는 booting에 관련된 message가 defaults로는 나오지 않는다.

         만약 사용자가 booting시에 message가 나오게하려면 -v option을 사용하여야 한다.

         diagnotic을 위해서는 -b option을 사용하여야 한다.

      4) Bootprom differences

         (1) Solaris 2.0에서는 새로운 PROM이 요구되지 않는다.

         (2) PROM system의 boot parameter가 변하였다.

             ok setenv boot-device /sbus/esp@0,800000/sd@0,0

             ok setenv boot-file /kernel/unix

         (3) 3가지 새로운 options

             reconfigure ---- boot -r

             verbose -------- boot -v

             minimum boot --- boot -b

   6. System run state differences

      SunOS 4.X는 두가지 상태 즉,single 과 multiuser의 상태로 구분되나,Solaris 2.0은 8가지 상태로 구분되지만

      실제적으로는 halt , single user , multiuser , reboot의 4가지 상태를 가진다.

      Run level 1 은 SunOS 4.X의 single mode와 같다.

      Run level 3 는 SunOS 4.X의 multiuser mode와 같다.

   7. Run state comparison

      who -r은 지금 run되고 있는 system level을 보여준다.

      일반적인 SVR4는 Solaris 2.0과 세가지 경우에서 다르다.

      1) run level 0 는 prom monitor상태를 나타나게 된다.

      2) run level 2는 file system을 export하지는 않지만,network을 이용하여 booting이 가는하게 한다.

      3) run level 3는 file system을 export한다.

      * Run state 비교

        Run state    Solaris 2.0 action                  SVR4 action
        ---------  ----------------------           ------------------------
         s , S     single user mode                   single user mode

           0       PROM Monitor level                 Power off

           1       single user mode:                  single user mode:
                   Root & user mounted                system admin mode

           2       Multi user mode:                   Multi user mode:
                   No Resources exported              Network disabled

           3       Multi user mode:                   Multi user mode:
                   Machine Resources exported         Network enabled

           4       Not currently used                 Not currently used

           5       PROM Monitor level                 PROM Monitor level

           6       Halt and reboot to default state   Halt and reboot to default state


   8. Device Name differences

      device는 device와 logical name에 유일하게 동일화되는 physical device name을 가진다.

      UNIX command는 logical name을 사용한다.

      Solaris 2.0은 System 5의 logical device name들을 적용하였다.

      1) 예제

        /dev/dsk/c0t0d0s6 = /dev/sd0g

        /dev/rmt/01 = /dev/rst0

      2) device는 physical device name에 symbolic link되어있다.

        /dev/dsk/c0t0d0s6 --> /device/sbus@1,f8000000/esp@0,800000/sd@1,0:g

      3) SunOS 4.X의 device name은 사용이 가능하다.

   9. Local UFS bootup sequence

      bootblock dhk  boot program이 다르지만,boot sequence step은 본질적으로는 같다.

      새로운 boot device를 더하는 것은 bootblock와 boot program에서 다루어지는것이 아니므로 더 쉽다.

      bootblock은 Sbus card상에 혹은 bootprom에서 발견되는 driver들을 사용한다.

      그러므로,bootblock이나 boot program은 새로운 device를 지원하기위해 더이상 새로 만들어지지 않아도된다.

      * UFS를 bootblock program이 어떻게 읽는가 ?

        1.prom이 boot block에서 읽음.

        2.bootblock(ufsbootblk)이 boot program에서 읽음.

        3.boot program(ufsboot)이 kernel에서 읽음.

        4.kernel9/kernel/unix)이 system을 초기화하고 init를 시작시킴.

        5./sbin/init가 /etc/inittab를 읽고,rc script를 시작함.

   10. Network Bootup sequence

       1) inetboot

          network booting은 기본적으로 같다.

          다른것은 ufsboot에서 비슷한 기능을 수행하는 program이 inetboot라고 불리우는 것이다.

          inetboot는 kernel이 자신 및 다른 module들을 충분히 초기화 할때까지 kernel,unix,load module를 

          돕는다.

          root file system이 mount되면 kernel은 더이상 inetboot를 필요로하지 않는다.

          * diskless booting은 SunOS 4.X와 거의 같다.
         
          * bootp = Internet RFC for booting

            
                     server                                diskless client

                                             RARP
             RARP server sends IP address  <-------   prom broadcasts RARP request
                                            ------->

                                              TFTP
             TFTP server sends inetboot     <-------  prom makes TFTP request
                                             ------->

                                              whoami
             root server sends hostname     <-------  inetboot gets IP address & issues
             & domainname                    -------> bootparams "whoami"
             (root server = bootparams)

                                              getfile
             root server sends pathname to   <-------  inetboot makes bootparams "getfile"
             client's root partition & name   -------> request
             of its server

                                                NFS
             root server sends kernel(unix)   <------  inetboot makes NFS mount request and
                                               ------> reads in unix

         2) init and /etc/inittab

            (1) init

              init는 일반적인 process spawner이다.

              그것의 주요 역활은 /etc/inittab file에 저장된 정보로부터 process를 만드는 것이다.

              UNIX가 boot될때 init가 만들어지게되고,init는 /etc/inittab file을 조사하게된다.

              /etc/inittab file의 entry는 system이 booting할때 가지게되는 run level을 알려준다.

              SUN system에서 이것은 run level 3를 말하는것이다.

              * init의 주요임무는 default run level을 가져오느 것이다.

              *  /etc/inittab file은 init에게 다음을 알려준다.

                 1.default run level
                 2.process to start
                 3.process to monitor and restart if they die

               * init는 /etc/inittab를 다시 읽고,run level에 의존하는 rc script를 run하는 상태들사이에서
                 transition을 조정한다. 

             (2) inittab

                 첫번째 field는 entry를 증명하는데 사용되는 2 letter character이다.

                 두번째 field는 이 process가 init에의해 만들어지는 run level을 명시한다.

                 action field는 process를 어떻게 다루어야하는지를 init에게 알린다.

                 process field는 발생되는 command와 그command의 arguments로 구성된다.

                 * /etc/inittab

                   ex) s3:3:wait:/sbin/rc3  > /dev/console 2>&1  s3 : id를 나타낸다.(첫번째 field)
                        
                             3 : rstate를 나타낸다.(두번째 field)

                            wait : action을 말한다 (action field)

                            /sbin/rc3 : process를 나타낸다(process field)

 
                    ex) /etc/inittab

                    ap::sysinit:/sbin/autopush -f /etc/iu.ap
                    fs::sysinit:/sbin/bcheckrc > /dev/console 2>&1 /dev/consile2>&1 /dev/consile2>&1 /dev/consile2>&1   /sbin/autopush
                                    |
                                    |
                                    V 

                              /sbin/bcheckrc
                                    |
                                    |
                                    V 
  
                              /sbin/rc2    -------------------->  /etc/rc2.d/K*,S*
                                    |
                                    |
                                    V
                              /sbin/rc3    -------------------->  /etc/rc3.d/K*,S*
                                    |
                                    |                              S10syslog      S20nis
                                    V                              S15nfs.server  S20rfs

                               /usr/lib/saf/sac
                                    |
                                    |
                                    V

                               /usr/lib/saf/ttymon

   11. shutdown process

       init와 telinit command는 control process를 초기화하거나 run state level을 변경할때 사용된다.

       init 0  와 telinit 0 는  시스템을 정지시키고 prom monitor에 control을 주게한다.

       init 1 과 telinit 1은 시스템을 single user상태로 만들고 모든 시스템은 mount되고,어떤 사용자도 

       login할수없게된다.

       * SunOS 와 Solaris 2.0의 비교

        SunOS 4.X command         Solaris 2.0 command
        ------------------        -------------------

             halt                 halt,int0,telinit0,init5 or telinit 5

             fasthalt             init 0,telinit 0,init 5,telinit 5

             reboot               reboot,init 6,telinit 6

             kill -1 1            init q,init Q,telinit q,telinit Q

             shutdown             /usr/ucb/shutdown or /sbin/shutdown

    12. Modify system startup / shutdown

        system bootup sequence는 booting을 위해 필요한 kernel module의 subset을 자동으로 load한다.

        그리고,/etc/inittab file을 수정하여 booting시의 절차를 변경가능하다.

        
    13. Loading Modules

        /etc/system file을 수정하여 booting시의 loading을 변경가능하다.

        forceload command 다음의 entry 추가를 하면된다.

        system이 running되는 동안에 module을 load하기위해서는 modload command를 이용한다.

    14. Unloading modules

        /etc/system file을 수정하면된다.

        system이 running되는 동안에는 modunload command를 사용하면된다.

        * 절대  /kernel에서 kernel module을 지우지말아야한다.

        * loading을 막기위해서는 /etc/system에서 다음과 같이 하면된다.

          exclude /kernel/fs/rfs

    15. Ways to change run states

        install S* , K* script를 수정하면된다.

        script는 alphanumeric order로 작동된다.

    16. Summary of differences

        SunOS 4.X                Solaris 2.0                  Description
        ---------                -----------              ------------------------
   
         bootsd                   ufsbootblk              load ufsboot from disk

         boot                     ufsboot                 load unix from disk

         vmunix                   unix                    bootable kernel image

         boot.sun4c.sunos.4.1.1   inetboot                mount /usr and check file systems

         rc.local                 /etc/rc3 , /etc/rc3d/*  system config script

         /etc/config              modload,add_drv         modules loaded when needed

         single/multiuser         8 run states            system run levels

         /dev/sd1g                /dev/dsk/c0t01ds6       logical device names

         MAKEDEV                  boot -r                 make device nodes

evision History
Created                 on 29 Apr , 1992