目次


Linux の 101 試験対策

システムのブート

BIOS から Linux システムが稼働状態になるまでの流れ

Comments

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です: Linux の 101 試験対策

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です:Linux の 101 試験対策

このシリーズの続きに乞うご期待。

概要

このチュートリアルでは、BIOS からブート完了までのブート・シーケンスを理解するために、以下の内容を学びます。

  • ブート・ローダーに一般的なコマンドを与える方法
  • ブート時にカーネルにオプションを指定する方法
  • ログ・ファイルでブート時のイベントを確認する方法

このチュートリアルは、Linux Professional Institute の Linux Server Professional (LPIC-1) 101 試験における主題 101 の項目 101.2 に備える上で役に立ちます。この試験項目の重要度は 3 です。

主に昔ながらの SysVinit プロセスと新しい systemd にフォーカスしますが、その他に upstart についても説明します。

コンピューターのブート

コンピューターの電源をオンにしたり、コンピューターを再起動したりしたときには、ユーザーが何らかの有用な作業を行うには、その前にコンピューターがオペレーティング・システムをロードしなければなりません。このプロセスは、コンピューターの「ブート」と呼ばれています。コンピューターは、ブートストラップが「ブート・ローダー」を使用することで、自らを立ち上げます。ほとんどの場合、このプロセスは自動的に行われますが、ユーザーが介入して、例えばインストール・メディアをブートしたり、修復モードでブートしたり、普段使用しているデフォルトのオペレーティング・システムとは別のオペレーティング・システムをブートしたりしなければならない場合もあります。そこでこのチュートリアルでは、一般的な Linux ブート・ローダーの場合、Linux のブート処理はどのような動作をし、ユーザーはこのプロセスとどのように対話を行って、プロセスをチェックすることができるかを説明します。

ブート・プロセスには、ほとんどのシステムに共通している側面もありますが、ハードウェアに関連する側面は、具体的なアーキテクチャーによって変わってきます。このチュートリアルでターゲットとするのは、BIOS を使用してシステムをブートする x86 および x86_64 アーキテクチャー・システムです。Intel Itanium アーキテクチャーと IA64 アーキテクチャーに対しては、16 ビット x86 BIOS アーキテクチャーのいくつかの限界を克服するために、特に Itanium が対象としている大規模サーバーをターゲットとして、Extensible Firmware Interface (EFI) と GUID Partition Table (GPT) を使用した新しいシステムが開発されました。Intel は 2005年に EFI の開発をバージョン 1.10 でストップし、その権利を Unified Extensible Firmware Interface (UEFI) Forum へと移管しました。EFI は現在、UEFI Forum によって UEFI として管理されています。UEFI は高い評判を得ており、サイズが 2 TB を超えるドライブを使用しているシステムでは特に人気を博しています。UEFI は、Windows 8 を実行しているコンピューターでも必要とされています。

前提条件

この連載のチュートリアルを最大限に活用するには、Linux の基礎知識と、記事に記載されたコマンドを演習できる実際の Linux システムが必要です。プログラムのバージョンによって出力のフォーマットに違いが出てくる場合もあるため、コマンドの実行結果は必ずしもここに記載するリストや図とまったく同じであるとは限りません。特に、BIOS の設定はシステムによって大幅に異なり、ブート・ローダーのスプラッシュ画面もディストリビューションごとにかなりの違いがあります。

また、チュートリアル「Linux の 101 試験対策: ハード・ディスクのレイアウト」 で説明している内容についても十分に理解している必要があります。

このチュートリアルの例では、特に断りがない限り、カーネル 4.0.4 と Fedora 22 を使用しています。他のシステムを使用する場合、結果が異なる可能性があります。

ブート・シーケンス

LILO、GRUB、GRUB2 などのブート・ローダーについて詳しく検討する前に、PC の起動 (つまり、ブート) がこれまで歴史的にどのように行われてきたかを復習しておきましょう。ROM、EEPROM、あるいはフラッシュ・メモリーなどの不揮発性メモリーには、BIOS (Basic Input Output Service) と呼ばれるコードが格納されています。このコードは、PC の電源を入れたとき、あるいは PC をリブートすると実行され、電源投入時自己診断テスト (Power-On Self Test、略称 POST) を行ってマシンをチェックします。さらに、使用可能なリムーバブル・ストレージ・デバイスまたは固定ストレージ・デバイスからブート・ドライブを判断し、そのブート・ドライブ上のマスター・ブート・レコード (Master Boot Record、略称 MBR) から 1 番目のセクターをロードします。ブート・ドライブは、従来のハード・ディスク・ドライブや、フラッシュ・メモリー・ドライブ (SSD)、USB メモリーまたは USB ドライブであることもあれば、フロッピー・ディスク、CD、DVD などのリブーバブル・メディアを搭載したドライブであることもあります。このチュートリアルではこれ以降、ハード・ディスク・ドライブにフォーカスして話を進めますが、その他のタイプのストレージ・デバイスの場合でもプロセスは同様です。

チュートリアル「Linux の 101 試験対策: ハード・ディスクのレイアウト」で説明したように、MBR にはパーティション・テーブルも含まれているため、MBR 内に格納される実行可能コードのサイズは 512 バイト未満と、あまり大きくありません。フロッピー・ディスク、CD、DVD、または USB メモリーなどの半導体デバイスを含め、すべてのディスクでは実行可能コードが MBR に格納されることに注意してください。実行可能コードが「Non-bootable disk in drive A: (ドライブ A のディスクはブート可能なディスクではありません)」のようなメッセージを出力することしかできないほどのサイズであっても、このことに変わりはありません。BIOS が 1 番目のセクターからロードするこのコードは、「第 1 ステージ・ブート・ローダー」、あるいは「ステージ 1 ブート・ローダー」と呼ばれます。

MS-DOS、PC DOS、そして Windows オペレーティング・システムが使用する標準的なハード・ディスクの MBR は、パーティション・テーブルを調べて、「アクティブ」であることを示すマークが付けられたブート・ドライブのプライマリー・パーティションを見つけます。そしてそのパーティションから最初のセクターをロードし、ロードしたコードの先頭に制御を渡します。ロードされたこの新しいコードは、「パーティション・ブート・レコード」としても知られています。パーティション・ブート・レコードは、実際にはもう 1 つのステージ 1 ブート・ローダーですが、これにはパーティションからブロック一式をロードするだけのインテリジェンスしかありません。この新しいブロック一式に格納されているコードは、「ステージ 2 ブート・ローダー」と呼ばれます。ステージ 2 ブート・ローダーは MS-DOS および PC DOS で使用されることから、そのまま直接、オペレーティング・システムの残りの部分をロードします。これが、オペレーティング・システムが自ら起動して、稼働状態になる仕組みです。

上記のプロセスは、オペレーティング・システムが 1 つしかないシステムでは上手く動作しますが、複数のオペレーティング・システムを使用するとしたらどうなるでしょう?例えば、OS/2、Windows 7、そして 3 つの異なる Linux ディストリビューションを使用する場合を考えてみてください。この場合、何らかのプログラム (DOS FDISK プログラムなど) を使用してアクティブ・パーティションを変更し、リブートするという方法もありますが、それでは厄介です。さらに、ディスク上に作成できるプライマリー・パーティションは最大 4 つしかなく、標準的な MBR が管理できるアクティブなプライマリー・パーティションは 1 つだけで、論理パーティションからのブートには対応することができません。けれども、この仮説の例で引用しているオペレーティング・システムは 5 つあり、そのそれぞれにパーティションが必要です。これは困ったことになりました。

この問題を解決する典型的なソリューションは、特殊なコードを使用して、ブート対象のオペレーティング・システムをユーザーが選択できるようにするものでした。いくつかのソリューションは長年にわたって使われてきましたが、それらの一例としては、以下のプログラムが挙げられます。

Loadlin
実行中の DOS システムから Linux パーティションをブートするために呼び出される DOS 実行可能プログラム。マルチブート・システムのセットアップが複雑で危険なプロセスであった頃に、よく使われていました。
OS/2 Boot Manager
小さなサイズの専用パーティションにインストールして使っていたプログラム。このプログラムがインストールされたパーティションにはアクティブのマークが付けられ、標準的な MBR ブート・プロセスが OS/2 Boot Manager を起動すると、ブートするオペレーティング・システムを選択できるメニューが表示されるというものでした。
スマート・ブート・ローダー
オペレーティング・システムのパーティションに常駐可能なプログラムで、アクティブ・パーティションのパーティション・ブート・レコード、またはマスター・ブート・レコードのいずれかから呼び出されます。一般的な Linux ブート・ローダーとしては以下のものが挙げられます。
  • LILO (LInux LOader)
  • GRUB (GRand Unified Boot loader): 現在、GRUB Legacy と呼ばれています。
  • GRUB 2: 多くの一般的なディストリビューションにインストールされている最新のブート・ローダー。
  • Syslinux: MS-DOS FAT ファイルシステム用の軽量ブート・ローダー (SYSLINUX)、ネットワーク・ブート用プログラム (PXELINUX)、El Torito 準拠のブート可能 CD-ROM (ISOLINUX)、Linux の ext2/ext3/ext4 または btrfs ファイルシステム (EXTLINUX) からなるグループ

このチュートリアルでは、主に GRUB2 にフォーカスして説明し、GRUB と LILO については、スマート・ブート・ローダーの歴史的視点での説明にほとんど終始します。

システムの制御を 512 バイトより大きなコードのプログラムに渡すことができれば、論理パーティションから、あるいはブート・ドライブ上にはないパーティションからブートするのも不可能な話でないのは明らかです。上記のソリューションはいずれも、そうしたことが可能です。そのような形でのブートが実現可能な理由は、これらのソリューションが任意のパーティションからブート・レコードをロードできるため、あるいはブート・プロセスを開始するためにはどのファイルをロードすればよいかを理解しているためです。

チェーン・ロード

制御を受け取ったブート・マネージャーがロードできるものの 1 つは、別のブート・マネージャーです。ブート・マネージャーが別のブート・マネージャーをロードすることを、チェーン・ロードと呼びます。最も頻繁に行われるチェーン・ロードは、MBR に置かれたブート・マネージャーが、パーティション・ブート・レコードにあるブート・ローダーをロードする場合です。Linux ブート・ローダーが Windows または DOS のパーティションをブートするように指示されると、ほぼ必ずと言ってよいほどチェーン・ロードが行われます。また、あるシステムの Linux ブート・ローダーが別のシステムのブート・ローダーをロードするように指示されたときにチェーン・ロードが行われることもあります。例えば、あるパーティションの LILO を使用して別のパーティションの GRUB をチェーン・ロードすることによって、その別のパーティションの GRUB にアクセスするなどです。

EFI と UEFI

このチュートリアルの導入部分で説明したように、EFI は Intel によって x86 BIOS アーキテクチャー (特に Itanium が対象としている大規模サーバーをターゲットとした 16 ビット・アーキテクチャー) のいくつかの限界を克服するために開発されました。Intel は 2005年に EFI の開発をバージョン 1.10 でストップし、その権利を Unified Extensible Firmware Interface (UEFI) Forum へと移管しました。EFI は現在、UEFI Forum によって UEFI として管理されています。2013年以降、UEFI Forum はデバイス構成および電源管理のための仕様である、Advanced Configuration and Power Interface (ACPI) の管理もしています。

16 ビット BIOS とは異なり、UEFI は 32 ビットまたは 64 ビットのいずれかです。64 ビット・プロセッサー (例えば、多くのタブレットや小型のノート PC で使われている Intel Atom プロセッサーなど) 上で 32 ビット UEFI を使用することは可能ですが、ブート・ローダーは UEFI に対応している必要があります。つまり、32 ビット UEFI に対しては 32 ビット・ブート・ローダー、64 ビット UEFI に対しては 64 ビット・ブート・ローダーを使用する必要があります。すべてではありませんが多くの UEFI 実装では、UEFI モードまたは Legacy BIOS モードのいずれかでブートすることが可能です。このようなシステムでは、UEFI をサポートしていないブート・ローダーでブートすることが可能ですが、システムが UEFI しかサポートしていない場合には、GRUB2 などの適切な UEFI ブート・ローダーが必要になります。

Linux のブート・ローダー

ここからは、最新の Linux ディストリビューションのほとんどに付属しているブート・ローダー、GRUB2 にフォーカスします。LILO は初期の Linux ディストリビューションの多くで使われていたブート・ローダーであり、GRUB はその後に登場しました。当初の GRUB は現在、GRUB Legacy と呼ばれるようになっており、Free Software Foundation の主導の下に開発が進められている最新バージョンが GRUB2 です (詳細は「参考文献」を参照)。LILO の新しいバージョンは ELILO と呼ばれており、EFI を使用するシステムのブート用に開発されたものですが、現在はアクティブな開発は行われておりません。ELILO についての詳細は、「参考文献」を参照してください。

PC のブート・プロセスは、以下のように要約することができます。

  1. PC の電源を入れると、BIOS が自己診断テストを行います。
  2. マシンが自己診断テストに合格すると、BIOS は MBR を、通常はブート・ドライブの最初の 512 バイトのセクターからロードします。ほとんどの場合、ブート・ドライブはシステム上の最初のハード・ディスク・ドライブですが、フロッピー・ディスク、CD、または USB メモリーにすることもできます。
  3. ハード・ディスク・ドライブ用に、MBR はステージ 1 ブート・ローダーをロードします。Linux システムで一般にロードするのは、LILO または GRUB ステージ 1 ブート・ローダーです。これも同じく、512 バイトの単一セクターのレコードです。
  4. 一般に、ステージ 1 ブート・ローダーは一連のレコードをロードします。このレコード一式は、ステージ 2 ブート・ローダーと呼ばれます (ステージ 1.5 ローダーと呼ばれることもあります)。
  5. ステージ 2 ブート・ローダーはオペレーティング・システムをロードします。Linux の場合、これはカーネルと、おそらくは初期 RAM ディスク (initrd または initramfs) です。

ブート・ローダーのインストールや基本的なブート操作について復習するには、関連チュートリアル「Linux の 101 試験対策: ブート・マネージャーのインストール」を参照してください。

システムのブート・プロセスを操作したい場合には、次の方法があります。

  1. ブート対象のデバイスを変更します。普段はハード・ディスク・ドライブからブートしているとしたら、フロッピー・ディスクや USB メモリー、CD、DVD、あるいはネットワークからブートする必要があるかもしれません。このような代わりのブート・デバイスをセットアップするには、そのデバイスに応じて BIOS を適切に構成する必要があり、それにはブート時に特定のキー入力をして選択項目を表示する必要があるかもしれません。図 1 に、私が使っているシステムで表示される選択項目の 1 つを示します。ブート・デバイスをセットアップして起動時にブート・デバイスを選択する方法は、システムとその BIOS によって異なります。この点についても、この LPI の目標で必要とされる範囲には含まれないため、詳細についてはお使いのシステムのドキュメントを参照してください。
    図 1. ブート・デバイスの選択
    起動デバイス・メニューのスクリーン・キャプチャー。表示されているブート・デバイスの選択項目のうち、Optiarc DVD RW デバイスが選択されて強調表示されています。
    起動デバイス・メニューのスクリーン・キャプチャー。表示されているブート・デバイスの選択項目のうち、Optiarc DVD RW デバイスが選択されて強調表示されています。
  2. ブート・ローダーを操作して、選択可能ないくつかの構成の中からブートする構成を選択するか、あるいはブート構成を編集するかします。このチュートリアルでは、GRUB2 でこれを行う方法を説明します。
  3. ブート・ローダーによってカーネルがロードされたら、カーネルがシステムを起動する方法を制御するためのパラメーターをカーネルに渡します。

LILO と GRUB での例は、関連チュートリアル「Linux の 101 試験対策: ブート・マネージャーのインストール」に記載されています。

GRUB2 ブート・メニュー

GRUB2 がロードされると、構成ファイルの情報が表示されます。構成ファイルは、一般的には /boot/grub/ または /boot/grub2/ にある grub.cfg ファイルです。リスト 1 に Fedora 22 システムでの grub.cfg ファイルのごく一部を示します。チュートリアルとして公開するために、このリストの一部の行には改行を入れており、それらの行の末尾にはバックスラッシュ (\) が付けられています。

リスト 1. Fedora 22 をブートするための GRUB2 構成メニュー・エントリー
### BEGIN /etc/grub.d/10_linux ###
menuentry 'Fedora (4.0.6-300.fc22.x86_64) 22 (Twenty Two)' --class fedora \
--class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option \
'gnulinux-4.0.6-300.fc22.x86_64-advanced-7aefe7a0-97d5-45ec-a92e-00a6363fb1e4' {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_msdos
	insmod ext2
	set root='hd0,msdos5'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos5 \
        --hint-efi=hd0,msdos5 --hint-baremetal=ahci0,msdos5  \
        7aefe7a0-97d5-45ec-a92e-00a6363fb1e4
	else
	  search --no-floppy --fs-uuid --set=root 7aefe7a0-97d5-45ec-a92e-00a6363fb1e4
	fi
	linux16 /boot/vmlinuz-4.0.6-300.fc22.x86_64 \
        root=UUID=7aefe7a0-97d5-45ec-a92e-00a6363fb1e4 ro rhgb quiet 
	initrd16 /boot/initramfs-4.0.6-300.fc22.x86_64.img
}

GRUB2 が構成ファイルを読み取ると、通常は図 2 に示すようなメニューが表示されます。一般には、短いタイムアウトの後、デフォルト・エントリーがブートされます。デフォルト・エントリーは強調表示され、タイマーがカウント・ダウンされていくのが見えるはずです。ここに示す (下図の) メニュー・エントリーは、上記リストをデフォルトの選択肢としています。アクションがない場合、35 秒でブートされます。

図 2. GRUB2 でブートの選択肢を選択する
GRUB2 でブートの選択肢を選択する画面のスクリーンショット
GRUB2 でブートの選択肢を選択する画面のスクリーンショット

メニューが表示されているときに Enter キーを押すことで、選択されているエントリーが即座にブートされます。あるいは、他のキーを押すことでタイムアウトを停止することもできます。その場合、別のエントリーをハイライト表示してブートすることや、「e」を押して選択されているエントリーを編集することや、「c」を押して GRUB2 コマンド・プロンプトを開くこともできます。 : タイムアウトが 0 に設定されている場合、GRUB2 は即座にシステムのブートへと進みます。この場合、他のデバイスからレスキュー・メディアをブートする必要があります。詳細は、関連チュートリアル「Linux の 101 試験対策: ブート・マネージャーのインストール」を参照してください。こちらのチュートリアルでは、GRUB2 コマンドラインの使用方法についても説明しているので、今回のチュートリアルではこの説明は省きます。

次は、カーネル・パラメーターと init プロセスを見て行った後、GRUB2 エントリーを編集してパラメーターを渡す方法を紹介します。

カーネル・パラメーター

カーネル・パラメーター (ブート・パラメーターとも呼ばれます) は、カーネル自体では判断できないようなハードウェア・パラメーターに関する情報をカーネルに提供するために使用され、無効にしなければ検出されてしまう可能性がある値を無効にしたり、不適切な値が検出されないようにしたりします。多少古いカーネル・レベルでは、システム上で特定の RAM 容量を上回る大容量メモリーをサポートできるようにするには、パラメーターが必要になります。システムを修復するためにシングル・ユーザー・モードでブートしたり、SMP システムをユニプロセッサー・モードでブートしたり、代替ルート・ファイルシステムを指定したりする必要があるかもしれません。あるいは、新たにビルドしたカスタム・カーネルがブートしない理由を明らかにできるように、以前に動作していたカーネルを指定する必要があるかもしれません。こうしたすべての作業は、ブート・パラメーターを使用して実現することができます。

ブート・パラメーターは、カーネル・コマンドライン上で提供されます。そのほとんどは以下のような形式をとります。

name[=value_1][,value_2]...[,value_10]

ここで、name はカーネルのどの部分が関連する値を受け取るかを識別するための一意に決まるキーワードです。これらのパラメーターは、以下の順番でチェックされます。

  1. カーネルは、引数が 'root='、'nfsroot='、'nfsaddrs='、'ro'、'rw'、'debug'、または 'init' のいずれかの特殊な引数であるかどうかを調べます。
  2. カーネルは、セットアップ関数の一覧をくまなく調べ、指定された引数ストリングがセットアップ関数に関連付けられているかどうかを確認します。
  3. セットアップ関数として受け付けられない 'foo=bar' という形式のものは、いずれも環境変数として解釈されて設定されます。
  4. 上記 1、2 のカーネルによるチェックで条件に当てはまらなかった引数のうち、上記 3 でも環境変数として解釈されずに残った引数は、いずれもプロセス 1 (通常、プロセス 1 は init プログラムです) に渡されます。

ブート・パラメーターの詳細は、info bootparam または man bootparam コマンドを使用して、man ページで調べることができます。最新の情報は、kernel-doc パッケージに含まれている kernel-parameters.txt でも提供されています。注: このチュートリアルを作成している時点の Fedora 22 には、kernel-doc パッケージや kernel-parameters ファイルが含まれていないようです。

カーネル・パラメーターを変更する必要がある場合、あるいは新しいカーネル・パラメーターを追加する必要がある場合、さもなければメニュー・エントリーから grub.cnf ファイル内で値を変更する必要がある場合を考えてみましょう。GRUB2 メニューを表示させた場合、変更する必要があるメニュー・エントリーを選択して「e」を押すことで、そのエントリーを編集することができます。その後の画面は図 3 のようになるはずです。この画面には、リスト 1 において波括弧で囲われたコード行が先頭から順に表示されていることがわかります

図 3. Fedora 22 GRUB2 メニュー・エントリーを編集する

init プロセスに渡される最も一般的な引数は、シングル・ユーザー・モードでコンピューターをブートするよう init プロセスに指示する single という単語で、この引数が指定された場合、通常のデーモンのすべてが起動されるようにはなりません。一般にこの引数は、何らかのレスキュー・オペレーションで使用されます。カーソルを下に移動させると、画面がスクロールして、「linux16」で始まって「ro rhgb quiet」で終わる行が表示されるはずです。ここに示す例では、この行の末尾にカーソルを移動させて Backspace キーを使って「quiet」、そして「rhgb」という単語を消去します。こうすることで、Fedora が通常のブート時に表示する Red Hat グラフィック・ブート画面が表示されなくなり、通常生成されるメッセージの多くを非表示にする機能も停止されます。最後に、シングル・ユーザー・モードでブートするための行に「single」という単語を追加します。すると、図 4 に示すような内容の表示になります。

図 4. Fedora 22 がシングル・ユーザー・モードでブートするように設定する

ここで、Ctrl-x を押すと、システムがシングル・ユーザー・モードでブートされます。いくつかのメッセージがスクロール表示された後、画面にはリスト 2 のような何行かが表示されます。

リスト 2. シングル・ユーザー・モードの Fedora 22
Welcome to emergency mode! After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, "systemctl default" or ^D to 
boot into default mode.
Give root password for maintenance
(Or press ^D to continue):

ここで root のパスワードを入力すると、システムをレスキューするために必要なあらゆることを実行することができます。その後、リブートするか、通常モードで実行を継続することができます。

シングル・ユーザー・モードが正確にはどのように表示されるかは、システムごとに異なります。パスワードを入力する必要がない root プロンプトに直接遷移するシステムもあれば、ここに示す例のように、パスワードの入力を求められるシステムもあります。どのように遷移するかは、システムが昔ながらの System V init プロセスを使用しているか、最新の upstart や systemd を使用しているかによって異なります。

次は、さまざまな init プロセスを見て行きましょう。

init プロセス

カーネルがロードを完了すると、通常は /sbin/init を起動します。このプログラムは、システムがシャットダウンされるまで実行され続けます。このプログラムには必ずプロセス ID として 1 が割り当てられます。昔ながらの System V init プロセスを使用しているシステムや、新しい Upstart による初期化を使用しているシステムでは、このプロセスに「init」という名前が付けられます。ただし、Systemd による初期化プロセスを使用しているシステムでは、/sbin/init が /lib/systemd/system における systemd init プロセスへのリンクになっています。以上の内容を Fedora 22 の場合について示したのがリスト 3 です。

リスト 3. init プロセス
[ian@atticf22 ~]$ ls -l /sbin/init
lrwxrwxrwx. 1 root root 22 Jun  9 09:16 /sbin/init -> ../lib/systemd/systemd
[ian@atticf22 ~]$ ps --pid 1
  PID TTY          TIME CMD
    1 ?        00:00:02 systemd

通常のオペレーションでは、昔ながらの System V init プロセスは、実行可能な 4 つのマルチユーザー・モードのランレベル 2 から 5 のいずれかで実行されます。使用するランレベルは、システムごとに決められますが、最も高いランレベルとして使用されるのは、通常は X Window System でのグラフィカル・オペレーション用のランレベルです。/etc/inittab ファイルは、それぞれのランレベルでどのプロセスが起動されるかを制御します。起動されるものを定義するために、upstart を使用するシステムには「ジョブ」の概念がある一方で、systemd を使用するシステムでは「ユニット」の概念を用います。このそれぞれのシステムでは、昔ながらの System V のランレベルに、適切なジョブまたはユニットをマッピングします。これにより、telinit などの多くのコマンドが、新しいスタートアップ・プロセスに対応した意味を持てるようになります。systemd のユニットの多くは、/usr/lib/systemd/system/ に保管されます。リスト 4 に、それぞれのランレベルに相当するターゲットから、systemd でそれぞれに対応するターゲットへのマッピングを示します。

リスト 4. ランレベルのターゲットに対応する systemd のユニット
[ian@atticf22 l-lpic1-101-2]$ cd /usr/lib/systemd/system/
[ian@atticf22 system]$ ls -l runlevel*.target
lrwxrwxrwx. 1 root root 15 Jun  9 09:16 runlevel0.target -> poweroff.target
lrwxrwxrwx. 1 root root 13 Jun  9 09:16 runlevel1.target -> rescue.target
lrwxrwxrwx. 1 root root 17 Jun  9 09:16 runlevel2.target -> multi-user.target
lrwxrwxrwx. 1 root root 17 Jun  9 09:16 runlevel3.target -> multi-user.target
lrwxrwxrwx. 1 root root 17 Jun  9 09:16 runlevel4.target -> multi-user.target
lrwxrwxrwx. 1 root root 16 Jun  9 09:16 runlevel5.target -> graphical.target
lrwxrwxrwx. 1 root root 13 Jun  9 09:16 runlevel6.target -> reboot.target

従来、シングル・ユーザー・モードは、ランレベル 1 と等価でしたが、実際にシステムをシングル・ユーザー・モード (ランレベル 1) で立ち上げるためには、「single」ではなく「1」と入力することができました。同様に「3」と入力すると、システムはネットワーク機能ありで X Window System を除くすべてを起動できるマルチユーザー・モードで起動され、「5」と入力すると、システムは完全なグラフィカル・デスクトップとして起動されます。上記リストのシンボリック・リンクからわかるように、現在の systemd ではシングル・ユーザー・モードでシステムを起動するために、rescue.target ユニットを使用しています。従って、以下のいずれかを指定したとします。

  • single
  • 1
  • s
  • systemd.unit=runlevel1.target
  • systemd.unit=rescue.target

この場合、いずれも同じくシングル・ユーザー・モードでシステムを起動することになります。systemd のユニットとターゲットについての詳細は、man ページで調べることができます。info systemd または man system を入力して試してください。

どの初期化プログラムを使用するとしても、初期化プログラムはシステムの残りの部分をブートするために、一連のスクリプトを実行します。System V init の場合、これらのスクリプトは通常、/etc/rc.d/init.d または /etc/init.d にあり、システムのホスト名の設定、ファイルシステムのエラー・チェック、追加ファイルシステムのマウント、ネットワークの有効化、印刷サービスの起動、などのサービスを実行します。これらのスクリプトがすべて完了した時点で、initgetty というプログラムを起動します。このプログラムによって、コンソールにログイン・プロンプトが表示されるという仕組みです。グラフィカル・ログイン画面は、グラフィカル・ディスプレイ・マネージャー (例えば Gnome の GDM など) によって処理されます。

さまざまなスタートアップ・プロセスについての詳細な情報は、関連チュートリアル「Linux の 101 試験対策: ランレベル、シャットダウン、およびリブート」を参照してください。

システムがカーネルをロードしても、init を正常に実行できない場合には、代わりの初期化プログラムを指定することで、リカバリーを試みることができます。例えば、init=/bin/sh を指定すると、システムは root 権限でシェル・プロンプトにシステムをブートするので、そこからシステムを修復できる可能性があります。

言うまでもありませんが、ブートするたびに同じ追加パラメーター一式を適用しなければならない場合には、それらのパラメーターを構成ファイルに追加してください。

初期 RAM ディスク

お気づきのことと思いますが、リスト 5 にもう一度示す GRUB2 の構成例の最後の数行では、linux16 の行でどのカーネルをロードするのかを指定し、initrd16 の行で初期 RAM ディスクを指定しています。カーネル・パラメーターを変更する方法については既に見てきましたが、初期 RAM ディスクとは何なのでしょう?

 
linux16 /boot/vmlinuz-4.0.6-300.fc22.x86_64 \
root=UUID=7aefe7a0-97d5-45ec-a92e-00a6363fb1e4 ro rhgb quiet 
initrd16 /boot/initramfs-4.0.6-300.fc22.x86_64.img

UNIX が登場した頃まで遡ると、デバイスの種類は少なく、カーネルのサイズは小さいものでした。ほとんどのデバイスは常時、物理的にコンピューターに接続されており、カーネルは通常、搭載されているハードウェアそのものをサポートするようにビルドされました。時が経過して、デバイスの数や種類が急激に増えるのに伴い、デバイス・サポートはロード可能なカーネル・モジュールの中へ移されることが多くなりました。カーネル・モジュールは、明確に定義されたエントリー・ポイントを持つ関数のライブラリーのようなものであり、カーネルの中にデバイス・サポートが集約されていないデバイスを、そのカーネルで使用できるようにします。これにより、カーネルをロードすることが可能となり、今度はそのカーネルがシステム内に実際に搭載されたデバイスのみのサポートをロードできるようになります。しかし、ディスクやファイルシステムをフルにサポートしてないとしたら、どのようにしてこれらのモジュールを見つけてディスクからロードするのでしょう?

その答えが、初期 RAM ディスク (つまり、initrd または initramfs) です。初期 RAM ディスクは、ロード可能なカーネル・モジュールが含まれたファイルであり、通常は圧縮されていて、ブート・ローダーによって RAM にロードされます。カーネルは、初期 RAM ディスクがまるでマウントされたファイルシステムであるかのように、初期 RAM ディスクにアクセスすることができます。file コマンドを使用して initrd ファイルを検証すれば、このファイルでどのような圧縮を使用しているかがわかります。圧縮方式がわかったら、その initrd ファイルのコピーを解凍すると、通常はその内部に cpio アーカイブを見つけることができます。システムによっては (Fedora 12 以降の Fedora などでは)、dracut というユーティリティーを使用して initrd ファイルが作成されます。この場合、initrd ファイルは cpio アーカイブのように見えますが、このファイルを解凍してみると、ほとんど何も表示されず、initrd ファイルのサイズが示すよりも遥かに小さいサイズになる可能性があります。initrd ファイルの中身を一覧表示するには lsinitrd コマンドを使用することができます。

ブート・イベント

Linux のブート・プロセスが実行されている間、コンソールにはカーネルがブート中であることや、システムのハードウェアやその他のカーネル関連の情報を伝えるために、メッセージが大量に出力されます。これらのメッセージは次々と現れては消えるので、ブート・プロセスが、例えばタイム・サーバーやチェック対象のファイルシステムに到達できないために待機状態になって遅延が生じない限り、メッセージを読むことはできないのが通常です。けれども Linux Bootsplash プロジェクト (「参考文献」を参照) の登場により、メッセージをグラフィックの背景に重ねて表示することや、メッセージを非表示にして単純なステータス・バーに置き換えることができるようになっています。お使いのディストリビューションが非表示モードをサポートしているとしたら、通常は F2 などのキーを押すことによって、ブート・メッセージを表示するように切り替えることができるはずです。

dmesg

カーネル・メッセージを再表示して確認できるのは便利なことです。標準出力はプロセスに関連しており、さらにカーネルにはプロセス ID がないことから、カーネル (およびモジュール) の出力メッセージはカーネル・リング・バッファーに保持されます。dmesg コマンドを使用してカーネル・リング・バッファーを表示すると、これらのメッセージを標準出力に表示することができます。もちろん、後で分析したり、デバッグのためにカーネル開発者に転送したりできるように、このコマンドの出力はファイルにリダイレクトすることも可能です。リスト 6 に例として、出力の一部を抜粋して記載します。ここでもチュートリアルとして公開するために、長い行には改行を入れており、それらの行の末尾にはバックスラッシュ (\) が付けられています。

リスト 6. dmesg を実行した場合の出力の抜粋
[root@atticf22 ~]#  dmesg | head -n 30
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 4.0.6-300.fc22.x86_64 (mockbuild@bkernel02.phx2.fedoraproject.org) \
(gcc version 5.1.1 20150618 (Red Hat 5.1.1-4) (GCC) ) #1 SMP Tue Jun 23 13:58:53 UTC 2015
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.0.6-300.fc22.x86_64 \
root=UUID=7aefe7a0-97d5-45ec-a92e-00a6363fb1e4 ro single
[    0.000000] tseg: 0000000000
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009ebff] usable
[    0.000000] BIOS-e820: [mem 0x000000000009ec00-0x000000000009ffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000000e4000-0x00000000000fffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000cff7ffff] usable
[    0.000000] BIOS-e820: [mem 0x00000000cff80000-0x00000000cff8dfff] ACPI data
[    0.000000] BIOS-e820: [mem 0x00000000cff8e000-0x00000000cffcffff] ACPI NVS
[    0.000000] BIOS-e820: [mem 0x00000000cffd0000-0x00000000cfffffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000ff700000-0x00000000ffffffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000012fffffff] usable
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] SMBIOS 2.5 present.
[    0.000000] DMI: System manufacturer System Product Name/M3A78-EM, BIOS 2003    10/12/2009
[    0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.000000] e820: last_pfn = 0x130000 max_arch_pfn = 0x400000000
[    0.000000] MTRR default type: uncachable
[    0.000000] MTRR fixed ranges enabled:
[    0.000000]   00000-9FFFF write-back
[    0.000000]   A0000-EFFFF uncachable
[    0.000000]   F0000-FFFFF write-protect
[    0.000000] MTRR variable ranges enabled:
[    0.000000]   0 base 000000000000 mask FFFF80000000 write-back
[    0.000000]   1 base 000080000000 mask FFFFC0000000 write-back

カーネル・リング・バッファーは、システムがブートした後に発生したイベントにも使用されます。例えば、特定のプログラムの失敗や、ホットプラグなどのイベントです。リスト 7 に、USB メモリーの接続に関するエントリーを示します。ボリュームが適切にアンマウントされなかったという警告が出力されていることに注意してください。

リスト 7. カーネル・リング・バッファーに保持されたブート後のイベント
[root@atticf22 ~]# dmesg | tail -n 21
[68209.847331] usb 4-2.4: new full-speed USB device number 5 using ohci-pci
[68209.928078] usb 4-2.4: device descriptor read/64, error -62
[68225.055771] usb 4-2.4: device descriptor read/64, error -110
[68225.231218] usb 4-2.4: new full-speed USB device number 6 using ohci-pci
[68225.340868] usb 4-2.4: New USB device found, idVendor=19ae, idProduct=2403
[68225.340875] usb 4-2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[68225.340877] usb 4-2.4: Product: MSC
[68225.340879] usb 4-2.4: Manufacturer: ATMEL ASF
[68225.340881] usb 4-2.4: SerialNumber: 123123123123
[68225.343447] usb-storage 4-2.4:1.0: USB Mass Storage device detected
[68225.352501] scsi host15: usb-storage 4-2.4:1.0
[68226.357737] scsi 15:0:0:0: Direct-Access     ATMEL    SD/MMC Card Slot 1.00 PQ: 0 ANSI: 3
[68226.358727] sd 15:0:0:0: Attached scsi generic sg7 type 0
[68226.367683] sd 15:0:0:0: [sdf] 7774208 512-byte logical blocks: (3.98 GB/3.70 GiB)
[68226.377646] sd 15:0:0:0: [sdf] Write Protect is off
[68226.377653] sd 15:0:0:0: [sdf] Mode Sense: 0f 00 00 00
[68226.387610] sd 15:0:0:0: [sdf] No Caching mode page found
[68226.387618] sd 15:0:0:0: [sdf] Assuming drive cache: write through
[68226.442450]  sdf:
[68226.484318] sd 15:0:0:0: [sdf] Attached SCSI removable disk
[68227.882986] FAT-fs (sdf): Volume was not properly unmounted. Some data may be corrupt.\
Please run fsck.

システム・メッセージをログに記録する

システムが /sbin/init を実行する時点になると、カーネルは引き続き前述のリング・バッファーにイベントを記録する一方、プロセスはデーモンを使用してメッセージをログに記録します。昔ながらの System V init システムでは、これを行うのは syslogd デーモンであり、通常はこのデーモンがログを /var/log/messages に記録します。systemd ベースのシステムでは、systemd-journald デーモンを使用してメッセージをログに記録し、それらのメッセージを調査する際には journalctl コマンドが使用されます。

/var/log/messages

リング・バッファーとは対照的に、syslog の各行にはタイム・スタンプが付けられ、このファイルはシステムが再起動しても維持されます。ブート・プロセスで init スクリプトの実行段階に発生したエラーを調べる場合、最初に調べるのはこのファイルです。

ほとんどのデーモンの名前は、「d」で終わります。リスト 8 には、リブート後にデーモンの最新のステータス・メッセージをいくつか表示する方法を示します。このリストでは、あらゆるタイプのメッセージを含む最新のメッセージ 10 個を表示しています。この例は、CentOS 6 システムの例です。

リスト 8. /var/log/messages に記録されたデーモン・メッセージ
[root@attic4-cent ~]# grep "Jul 22.........[^:]*d\:" /var/log/messages
Jul 22 21:45:23 attic4-cent rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" \
x-pid="2051" x-info="http://www.rsyslog.com"] start
Jul 22 21:45:23 attic4-cent cpuspeed: Enabling ondemand cpu frequency scaling governor
Jul 22 21:45:26 attic4-cent acpid: starting up
Jul 22 21:45:26 attic4-cent acpid: 1 rule loaded
Jul 22 21:45:26 attic4-cent acpid: waiting for events: event logging is off
Jul 22 21:45:27 attic4-cent acpid: client connected from 2423[68:68]
Jul 22 21:45:27 attic4-cent acpid: 1 client rule loaded
Jul 22 21:45:32 attic4-cent abrtd: Init complete, entering main loop
Jul 22 21:45:33 attic4-cent libvirtd: Could not find keytab file: /etc/libvirt/krb5.tab: \
No such file or directory
[root@attic4-cent ~]# tail /var/log/messages
Jul 22 21:46:00 attic4-cent kernel: XFS (sda6): Mounting Filesystem
Jul 22 21:46:00 attic4-cent kernel: XFS (sda6): Ending clean mount
Jul 22 21:46:00 attic4-cent kernel: TECH PREVIEW: btrfs may not be fully supported.
Jul 22 21:46:00 attic4-cent kernel: Please review provided documentation for limitations.
Jul 22 21:46:00 attic4-cent kernel: Btrfs loaded
Jul 22 21:46:00 attic4-cent kernel: device fsid d9cb309d-e15d-4b00-9b2f-e3cc08db412c \
devid 1 transid 52 /dev/sda9
Jul 22 21:46:00 attic4-cent kernel: btrfs: disk space caching is enabled
Jul 22 21:46:00 attic4-cent kernel: BTRFS: couldn't mount because of unsupported \
optional features (140).
Jul 22 21:46:00 attic4-cent kernel: btrfs: open_ctree failed
Jul 22 21:46:47 attic4-cent pulseaudio[3252]: ratelimit.c: 9 events suppressed

シャットダウン・イベントもログに記録されるため、システムのシャットダウンがすべて順調に行われているわけではない場合には、最新のシャットダウンで記録されたログ情報の中にその原因を見つけられる可能性があります。

/var/log には、その他多くのシステム・プログラムのログも格納することができます。例えば、X Window System の起動ログもここで見つけることができます。

journalctl

新しい systemd の傘下には数多くの関数がありますが、それとともに systemd-journald デーモンによって管理される新しいジャーナリング関数があります。このデーモンを使用しているシステムの場合、ログはこのデーモンによって管理され、メッセージを表示するには journalctl コマンドを使用することができます。リスト 9 に journalctl -xb コマンドによる出力の最初のページを示します。このコマンドは、最新のブートによるジャーナル・エンティティーを表示します。

リスト 9. journalctl -xb コマンドを使用して最新のブートによるログ・エントリーを表示する
-- Logs begin at Tue 2015-06-02 12:38:08 EDT, end at Wed 2015-07-22 22:04:23 EDT
Jul 22 22:02:25 atticf20 systemd-journal[106]: Runtime journal is using 8.0M (ma
Jul 22 22:02:25 atticf20 systemd-journal[106]: Runtime journal is using 8.0M (ma
Jul 22 22:02:25 atticf20 kernel: Initializing cgroup subsys cpuset
Jul 22 22:02:25 atticf20 kernel: Initializing cgroup subsys cpu
Jul 22 22:02:25 atticf20 kernel: Initializing cgroup subsys cpuacct
Jul 22 22:02:25 atticf20 kernel: Linux version 4.0.6-300.fc22.x86_64 (mockbuild@
Jul 22 22:02:25 atticf20 kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-4.0.6-30
Jul 22 22:02:25 atticf20 kernel: tseg: 0000000000
Jul 22 22:02:25 atticf20 kernel: e820: BIOS-provided physical RAM map:
Jul 22 22:02:25 atticf20 kernel: BIOS-e820: [mem 0x0000000000000000-0x0000000000
Jul 22 22:02:25 atticf20 kernel: BIOS-e820: [mem 0x000000000009ec00-0x0000000000
Jul 22 22:02:25 atticf20 kernel: BIOS-e820: [mem 0x00000000000e4000-0x0000000000
Jul 22 22:02:25 atticf20 kernel: BIOS-e820: [mem 0x0000000000100000-0x00000000cf
Jul 22 22:02:25 atticf20 kernel: BIOS-e820: [mem 0x00000000cff80000-0x00000000cf
Jul 22 22:02:25 atticf20 kernel: BIOS-e820: [mem 0x00000000cff8e000-0x00000000cf
Jul 22 22:02:25 atticf20 kernel: BIOS-e820: [mem 0x00000000cffd0000-0x00000000cf
Jul 22 22:02:25 atticf20 kernel: BIOS-e820: [mem 0x00000000ff700000-0x00000000ff
Jul 22 22:02:25 atticf20 kernel: BIOS-e820: [mem 0x0000000100000000-0x000000012f
Jul 22 22:02:25 atticf20 kernel: NX (Execute Disable) protection: active
Jul 22 22:02:25 atticf20 kernel: SMBIOS 2.5 present.
Jul 22 22:02:25 atticf20 kernel: DMI: System manufacturer System Product Name/M3
Jul 22 22:02:25 atticf20 kernel: e820: update [mem 0x00000000-0x00000fff] usable
lines 1-23

systemd-journald と journalctl についての詳細は、例によって man ページを参考にしてください。

以上で、Linux システムのブート・プロセスについての説明は終わりです。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux
ArticleID=1026770
ArticleTitle=Linux の 101 試験対策: システムのブート
publish-date=02112016