新システムの起動と動作テスト
新システムの起動テスト
カーネルのビルド・インストールが終わりました。 これで、新システムの起動に必要なものは全て揃いました。
ただし、まだ、起動はできません。 ブートローダであるGRUBが、新システムの存在を知らないためです。
ここでは、GRUBに新システムを認識させ、実際に起動テストを行います。
FedoraのGRUBメニューへの追加
開発機のハードディスクのマスターブートレコード上にあるブートローダはGRUBです。 このブートローダは、Fedoraのインストーラによって、Fedoraのインストール時に作成されました。
現状、ブートローダは新システムの存在を知りません。 新システムをGRUBのメニューに追加させるため、以下を実行して、GRUBに新システムを認識させます。
grub2-mkconfig -o /boot/grub2/grub.cfg
以下のように "unknown Linux distribution" が認識されていれば問題ありません。
Generating grub configuration file ... Found linux image: /boot/vmlinuz-4.2.3-300.fc23.i686 Found initrd image: /boot/initramfs-4.2.3-300.fc23.i686.img Found linux image: /boot/vmlinuz-0-rescue-e0c29f9903d9415db6032f825c9fe336 Found initrd image: /boot/initramfs-0-rescue-e0c29f9903d9415db6032f825c9fe336.img Found unknown Linux distribution on /dev/sda3 done
起動テスト
では、新システムを起動してみましょう。 開発機を再起動してください。
上図のようにGRUBのメニューに "unknown Linux distribution" の項目が追加されます。 キーボードのカーソルキーの下(↓)を押して、"unknown Linux distribution" の行を選択してください。
上図のように"unknown Linux distribution" の行を選択し、キーボードのEnterキーを押します。
上図のように新システムの起動が開始され、カーネルメッセージが画面に表示されます。 ログインプロンプトが表示されるまで、何もせずそのまま待ちます。
上図のようにログインプロンプトが表示されます。 ログインプロンプトの前半部分には、ホスト名が表示されます。
では、rootでログインしましょう。 "root" と入力し、続けてパスワードを入力し、キーボードのEnterキーを押します。
上図のようにログインに成功したでしょうか。
新システムの動作テスト
続いて、動作テストを行います。 個々のソフトウェアについてはすでにテストを実施済みですので、ここでは、新システム全体の簡単なテストを実施します。
なお、ログインできることは確認できましたし、ホスト名が設定されていることもすでに確認できています。 ここでは、主にネットワーク関係のテストを実施します。
まずは、ネットワークデバイスが正しく設定されているかを確認します。
ip addr
以下のように、IPアドレス、サブネットマスク、ブロードキャストアドレスが設定されていることを確認します。
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default
link/sit 0.0.0.0 brd 0.0.0.0
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
link/ether 00:0c:29:45:f2:d7 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.103/24 brd 192.168.0.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 2001:a452:7542:c800:5eef:8004:52ea:b33a/64 scope global noprefixroute dynamic
valid_lft 14280sec preferred_lft 12480sec
inet6 fe80::3cb9:fa3b:abb9:e863/64 scope link
valid_lft forever preferred_lft forever
続いて、デフォルトゲートウェイが設定されていることを確認します。 デフォルトゲートウェイを表示してみましょう。
ip route
以下のように、デフォルトゲートウェイが設定されていることを確認します。
default via 192.168.0.1 dev eth0 metric 203 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.103 metric 203
さらに、名前解決が動作することを確認します。 www.kernel.orgのIPアドレスを引いてみましょう。
nslookup www.kernel.org
以下のように、IPアドレスが引けることを確認します。
Server: 192.168.0.1 Address: 192.168.0.1#53 Non-authoritative answer: www.kernel.org canonical name = pub.all.kernel.org. Name: pub.all.kernel.org Address: 149.20.4.69 Name: pub.all.kernel.org Address: 198.145.20.140 Name: pub.all.kernel.org Address: 199.204.44.194
最後に、インターネット上のサーバへの到達テストを行います。 インターネット上の任意のサーバに PING を打ちます。
[root@my1cdilnux ~]# ping -c 1 mydomain.jp PING mydomain.jp (149.20.4.69): 56 data bytes 64 bytes from 149.20.4.69: icmp_seq=0 ttl=54 time=127.010 ms --- mydomain.jp ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max/stddev = 127.010/127.010/127.010/0.000 ms
このように、応答が返ってくることを確認します。
起動の流れ
ここでは、作成した新システムがどのように起動しているかを説明します。 開発機の電源が投入されてからログインプロンプトが表示されるまでの流れを説明します。
BIOSへの制御の移行
動作を開始したCPUは、まずはCPU内部の初期化を行います。 続いて、CPUは、メモリの特定のアドレスから実行を開始します。 そのアドレスには、BIOSへのジャンプ命令があるため、BIOSに制御が移ることになります。
BIOSによる起動メディアの決定
BIOSは、記録されている起動優先順位に従ってメディアを探し、そのメディアが起動可能かどうかを調べます。
起動可能かどうかは、先頭セクタ ( 512バイト ) の内容によって判断されます。 先頭セクタの最後の2バイトが、0xAA55 であれば、それはブートローダであると判断されます。
先頭セクタがブートローダであると判断されると、セクタの内容がメモリにロードされ、制御が移されます。 つまり、ブートローダに制御が移ります。
プライマリブートローダ
制御が移されたブートローダは、まだLinuxシステムは起動はしません。 正確に言えば、起動しないのではなく、起動できないのです。 先頭セクタはわずか512バイトしかないため、Linuxシステムをロードできるだけの機能は持っていないのです。
最近の巨大化したOSでは、ブートローダは512バイトには収まりません。 そのため、ブートローダの処理は2段階に分けられています。 先頭セクタに格納されているのは、その第1段階であり、プライマリブートローダと呼ばれます。
現在メモリ上で実行されているプライマリブートローダの役目は、第2段階であるセカンダリブートローダを起動メディアから探してメモリにロードし、制御を移すことです。 今回の新システムでは、セカンダリブートローダはFedoraのパーティションに置かれています。
プライマリブートローダは、Fedoraのパーティションからセカンダリブートローダ ( /boot/grub/stage2 ) をメモリにロードし、制御を移します。
セカンダリブートローダ
制御が移されたセカンダリブートローダは、FedoraのパーティションからGRUBの設定ファイル ( /boot/grub2/grub.cfg ) を探して読み込みます。 セカンダリブートローダは、読み込んだ設定ファイルに従ってGRUBメニューを表示します。
利用者は、GRUBメニューから起動するOSをキーボードを使って選択し、Enterキーで確定します。
利用者がLinux系OSを選択した場合は、セカンダリブートローダはカーネルをメモリにロードし、制御を移します。
カーネル
制御が移されたカーネルは、まずは、カーネル内部の初期化処理を行います。 続いて、カーネルは、ルートファイルシステムをリードオンリーでマウントします。
ルートファイルシステムをマウントしたカーネルは、ルートファイルシステムから /sbin/init を起動します。
initプロセス
カーネルから起動されたinitプロセス ( /sbin/init ) は、/etc/inittab を読み込みます。 読み込んだ、/etc/inittab に従って、以下が実行されます。
rc.sysinitの実行
/etc/inittabの、
si::sysinit:/etc/rc.d/rc.sysinit
に従って、/etc/rc.d/rc.sysinitが実行されます。
rc.sysinitでは、/proc仮想ファイルシステムのマウント、ルートファイルシステムの再マウントなどが行われます。
rcの実行
/etc/inittabの、
r0:0:wait:/etc/rc.d/rc 0 r1:1:wait:/etc/rc.d/rc 1 r2:2:wait:/etc/rc.d/rc 2 r3:3:wait:/etc/rc.d/rc 3 r4:4:wait:/etc/rc.d/rc 4 r5:5:wait:/etc/rc.d/rc 5 r6:6:wait:/etc/rc.d/rc 6
に従って、/etc/rc.d/rcが実行されます。 ランレベルが 3 であるため、
r3:3:wait:/etc/rc.d/rc 3
のみが実行されます。
rcでは、/etc/rc.d/rc3.dディレクトリにあるシンボリックリンクから、ファイル名が "S" で始まるものを探し、ファイル名の順で実行します。 具体的には、
- S10sysklogd ( 実体は /etc/init.d/sysklogd )
- S20random ( 実体は /etc/init.d/random )
- S20udev ( 実体は /etc/init.d/udev )
- S30network ( 実体は /etc/init.d/network )
が順に実行されます。 つまり、各種デーモンの起動や初期化処理が行われます。
rc.localの実行
/etc/inittabの、
lc:2345:once:/etc/rc.d/rc.local
に従って、/etc/rc.d/rc.localが実行されます。
なお、rc.localには、何の処理も記述されていません。
agettyの起動
/etc/inittabの、
c1:2345:respawn:/sbin/agetty tty1 9600 c2:2345:respawn:/sbin/agetty tty2 9600 c3:2345:respawn:/sbin/agetty tty3 9600 c4:2345:respawn:/sbin/agetty tty4 9600 c5:2345:respawn:/sbin/agetty tty5 9600 c6:2345:respawn:/sbin/agetty tty6 9600
に従って、agettyが起動されます。 全部で6プロセスが起動されます。
agettyは端末制御を行うためのプロセスであり、ログインプロンプトを表示し、ログイン処理を行っています。 つまり、上記の6プロセスは、各コンソールのログインを待ち受けているプロセスです。
ハードディスクの先頭セクタを見てみよう
開発機のハードディスクの先頭セクタの中身をちょっと覗いてみましょう。
なお、ここからの作業は、Fedoraを起動して実施してください。 また、チェンジルートはせずにFedora上で作業してください。
まずは、ハードディスクのブートセクタ(512バイト)を /tmp/bootsector に書き出します。 以下のように、
dd if=/dev/<@デバイス名@> of=/tmp/bootsector bs=512 count=1
とすることで書き出すことができます。
例えば、仮想マシンで作業しているのであれば、/dev/sda のはずですので、
dd if=/dev/sda of=/tmp/bootsector bs=512 count=1
とすることで書き出すことができます。
[root@localhost ~]# dd if=/dev/sda of=/tmp/bootsector bs=512 count=1 1+0 レコード入力 1+0 レコード出力 512 バイト (512 B) コピーされました、 0.00456663 秒、 112 kB/秒 [root@localhost ~]#
続いて、書き出したファイルをダンプしてみましょう。
hexdump /tmp/bootsector
[root@localhost ~]# hexdump /tmp/bootsector 0000000 63eb 1090 d08e 00bc b8b0 0000 d88e c08e 0000010 befb 7c00 00bf b906 0200 a4f3 21ea 0006 0000020 be00 07be 0438 0b75 c683 8110 fefe 7507 0000030 ebf3 b416 b002 bb01 7c00 80b2 748a 8b01 0000040 024c 13cd 00ea 007c eb00 00fe 0000 0000 0000050 0000 0000 0000 0000 0000 8000 0001 0000 0000060 0000 0000 faff 9090 c2f6 7480 f605 70c2 0000070 0274 80b2 79ea 007c 3100 8ec0 8ed8 bcd0 0000080 2000 a0fb 7c64 ff3c 0274 c288 be52 7c05 0000090 41b4 aabb cd55 5a13 7252 813d 55fb 75aa 00000a0 8337 01e1 3274 c031 4489 4004 4488 89ff 00000b0 0244 04c7 0010 8b66 5c1e 667c 5c89 6608 00000c0 1e8b 7c60 8966 0c5c 44c7 0006 b470 cd42 00000d0 7213 bb05 7000 76eb 08b4 13cd 0d73 845a 00000e0 0fd2 de83 be00 7d85 82e9 6600 b60f 88c6 00000f0 ff64 6640 4489 0f04 d1b6 e2c1 8802 88e8 0000100 40f4 4489 0f08 c2b6 e8c0 6602 0489 a166 0000110 7c60 0966 75c0 664e 5ca1 667c d231 f766 0000120 8834 31d1 66d2 74f7 3b04 0844 377d c1fe 0000130 c588 c030 e8c1 0802 88c1 5ad0 c688 00bb 0000140 8e70 31c3 b8db 0201 13cd 1e72 c38c 1e60 0000150 00b9 8e01 31db bff6 8000 c68e f3fc 1fa5 0000160 ff61 5a26 be7c 7d80 03eb 8fbe e87d 0034 0000170 94be e87d 002e 18cd feeb 5247 4255 0020 0000180 6547 6d6f 4800 7261 2064 6944 6b73 5200 0000190 6165 0064 4520 7272 726f 0a0d bb00 0001 00001a0 0eb4 10cd 3cac 7500 c3f4 0000 0000 0000 00001b0 0000 0000 0000 0000 7729 c3c7 0000 2080 00001c0 0021 fe83 ffff 0800 0000 d000 01dc fe00 00001d0 ffff fe82 ffff d800 01dc c800 001d fe00 00001e0 ffff fe83 ffff a000 01fa 6000 0605 0000 00001f0 0000 0000 0000 0000 0000 0000 0000 aa55 0000200 [root@localhost ~]#
最後の2バイトが aa55 になっていることが確認できました。