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