第3章 システムの初期化

Unified Extensible Firmware Interface (UEFI) は、UEFI 仕様書の一部としてブートマネージャーを定義します。ブートマナージャーは、コンピューター電源投入時にブート設定をチェックしその設定に基づき指定された OS ブートローダーかオペレーティングシステムのカーネル(通常ブートローダー)を実行するブートプロセスの第一段階です。ブート設定は、OS ローダーや OS カーネルまでのファイルシステムパスを示す変数を含めて、NVRAM に保存された変数に定義されています。

EFI システムパーティション (ESP) は UEFI 仕様書に準拠するコンピューターで使われるデーターストレージデバイスのパーティションです。それはコンピューター電源投入時に UEFI ファームウエアーによってアクセスされ、UEFI アプリケーションやそれらのアプリケーションが実行する必要のある OS ブートローダーを含めたファイルが保存されています。(旧式の PC システム上では MBR 中に保存された BIOS がこれに代え使われているかもしれません)

ブートローダーは UEFI によって起動されるブートプロセスの2段目です。それはシステムのカーネルイメージと initrd イメージをメモリーにロードし、それらにコントロールを引き継ぎます。この initrd イメージはルートファイルシステムイメージで、そのサポートは使われるブートローダーによります。

Debian システムは普通 Linux カーネルをデフォルトのシステムカーネルとして使います。現行の 5.x Linux カーネルのための initrd イメージは技術的には initramfs (initial RAM filesystem) イメージです。

多くのブートローダと設定オプションが利用可能です。

	警告
	grub-rescue-pc パッケージのイメージから作ったブート可能なレスキューメディア (CD かフロッピー) 無しにブートローダーを試してはいけません。これさえあると、ハードディスク上に機能するブートローダーが無くともシステムのブートができます。

UEFI システムの場合、GRUB2 は ESP パーティションを最初に読み、"/boot/efi/EFI/debian/grub.cfg" 中の search.fs_uuid に指定された UUID を使って GRUB2 メニュー設定ファイル "/boot/grub/grub.cfg" があるパーティションを決めます。

GRUB2 メニュー設定ファイルの重要部分は以下です:

menuentry 'Debian GNU/Linux' ... {
        load_video
        insmod gzio
        insmod part_gpt
        insmod ext2
        search --no-floppy --fs-uuid --set=root fe3e1db5-6454-46d6-a14c-071208ebe4b1
        echo    'Loading Linux 5.10.0-6-amd64 ...'
        linux   /boot/vmlinuz-5.10.0-6-amd64 root=UUID=fe3e1db5-6454-46d6-a14c-071208ebe4b1 ro quiet
        echo    'Loading initial ramdisk ...'
        initrd  /boot/initrd.img-5.10.0-6-amd64
}

/boot/grub/grub.cfg のこの部分に関して、このメニューエントリーは以下の意味があります。

	ヒント
	"/boot/grub/grub.cfg" 中の quiet を除くことでカーネルブートログを見えるようにできます。恒久的変更をするには、"/etc/default/grub" 中の "GRUB_CMDLINE_LINUX_DEFAULT="quiet"" 行を編集して下さい。

	ヒント
	"/etc/default/grub" 中の GRUB_BACKGROUND 変数をイメージファイル指すように設定するか、 "/boot/grub/" 中にイメージファイル自体を置くことで、GRUB のスプラシュイメージをカスタマイズできます。

"info grub" と grub-install(8) を参照下さい。

普通の Debian システムはミニ Debian システムによって起動されるブートプロセスの4段目です。ミニ Debian システムのシステムカーネルはこの環境ででも実行され続けます。ルートファイルシステムはメモリー上から本当にハードディスク上にあるファイルシステムに切り替えられます。

多くのプログラムを起動する主ブートプロセスを行う init プログラムは、PID=1 で最初のプログラムとして実行されます。init プログラムのデフォールトのファイルパスは "/usr/sbin/init" ですが、"init=/path/to/init_program" のようなカーネルブートパラメーターにより変更できます。

Debian 8 jessie (2015年リリース) 以降では "/usr/sbin/init" は "/lib/systemd/systemd" にシムリンクされています。

	ヒント
	ブートプロセスを高速化する最新のティップは Debian wiki: BootProcessSpeedup を参照下さい。

Debian システムが起動する時、/usr/lib/systemd にシムリンクされた /usr/sbin/init が、root (UID=0) が所有する init システムプロセス (PID=1) で起動されます。systemd(1) を参照下さい。

systemd の init プロセスは、SysV 的な手続き定義スタイルではなく宣言定義スタイルで書かれた unit 設定ファイルに従い並列で複数プロセスを起動します。(systemd-system.conf(5) 参照):

生成されたプロセスは、それらが所属するプライベート systemd ヒエラルキー中の所属する unit にちなんで名付けられた個別の Linux コントロール グループ中に置かれます(cgroups と 「Linux のセキュリティ機能」 を参照下さい。)

systemd.unit(5) 中に記載された "System Unit Search Path (システムユニット探索パス)" からシステムモード用の unit がロードされます。主要なパスは優先順位順に以下です:

相互依存関係は "Wants="、"Requires="、"Before="、"After="、 … ("MAPPING OF UNIT PROPERTIES TO THEIR INVERSES" in systemd.unit(5) 参照) 等の指示定義によって規定される。リソースのコントロールは (systemd.resource-control(5) 参照)によっても定義されます。

unit 設定ファイルのサッフィックスにそのタイプを以下のように折込みます:

システムの始動 (init) されると systemd プロセスは (普通 "graphical.target" にシムリンクされている) "/lib/systemd/system/default.target を起動しようとします。. 最初に、"local-fs.target" や "swap.target" や "cryptsetup.target" 等のいくつかの特殊ターゲット unit (systemd.special(7) 参照) が引き込まれファイルシステムをマウントします。そして、他のターゲット unit が、ターゲット unit の依存関係で引き込まれます。詳細に関しては bootup(7) を読んで下さい。

systemd はバックワードコンパティビリティー機能を提供します。"/etc/init.d/rc[0123456S].d/[KS]name" 中の、SysV-スタイルのブートスクリプトは依然として読み込まれ処理されますし、telinit(8) は systemd の unit のアクティベーション要求に変換されます。

gdm3(8)、sshd(8)、等々経由で Debian システムにユーザーがログインする際に、当該ユーザーが所有するユーザーサービス マネージャー プロセスとして /lib/systemd/system --user が起動されます。systemd(1) を参照下さい。

systemd の ユーザーサービス マネージャーは、宣言定義スタイルで書かれた unit 設定ファイルに従い並列で複数プロセスを起動します。(systemd.unit(5) や user@.service(5) 参照):

systemd.unit(5) 中に記載された "User Unit Search Path (ユーザーユニット探索パス)" からユーザーモード用の unit がロードされます。主要なパスは優先順位順に以下です:

• "~/.config/systemd/user/*": ユーザー設定 unit

• "/etc/systemd/user/*": 管理者が作成したユーザー units

• "/run/systemd/user/*": 実行時 unit

• "/lib/systemd/user/*": ディストリビューション パッケージ マネージャーがインストールしたユーザー unit

これらは、「Systemd init」と同様の手法で管理されます。

普通のディスクやネットワークのファイルシテムのマウントオプションは "/etc/fstab" で設定されます。fstab(5) と 「マウントオプションによるファイルシステムの最適化」を参照下さい。

暗号化されたファイルシステムの設定は "/etc/crypttab" で設定されます。crypttab(5) を参照下さい。

mdadm(8) を用いるソフトウェアー RAID は "/etc/mdadm/mdadm.conf" で設定されます。mdadm.conf(5) を参照下さい。

systemd下の現代的な Debian デスクトップ環境では、ネットワークインターフェースは、lo が "networking.service" で、他のインターフェースが "NetworkManager.service" で典型的には初期化されます。

どのように設定するのかは 5章ネットワークの設定 を参照下さい。.

クラウドシステムインスタンス "Debian オフィッシャルクラウドイメージ" とか類似のイメージのクローンとしてローンチされるかもしれません。そのようなシステムインスタンスの場合、ホスト名やファイルシステムやネットワーキングやロケールや SSH キーやユーザーとかグループとかは cloud-init や netplan.io パッケージが提供する機能を使って、オリジナルのシステムイメージ中に置かれたファイルとかそのローンチ時に供給される外部データー等の複数のデーターソースを用いて設定されます。これらのパッケージは YAML データーを使った宣言的なシステム設定を可能にします。

詳しくは "Debian とその系統でのクラウドコンピューティング"や"Cloud-init ドキュメンテーション"や「クラウドのための現代的なネットワーク設定」を参照下さい。

デフォルトのインストールでは、多くのネットワークサービス(6章ネットワークアプリケーション を参照) はブート時に systemd によってブート時に network.target の後に起動される。"sshd" も例外ではありません。カスタム化の例としてオンデマンド起動に "sshd" をかえましょう。

最初に、システムがインストールしたサービスの unit を無効化しましょう。

 $ sudo systemctl stop sshd.service
 $ sudo systemctl mask sshd.service

古典的 Unix サービスでは indetd (または xinetd) スーパーサーバーによりオンデマンドでソケットをアクティベーションしました。systemd では、*.socket や *.service unit 設定ファイルを追加することでこれと同等のことが できます。

聞くソケットを指定するには sshd.socket

[Unit]
Description=SSH Socket for Per-Connection Servers

[Socket]
ListenStream=22
Accept=yes

[Install]
WantedBy=sockets.target

sshd.socket に対応するサービスファイルの sshd@.service

[Unit]
Description=SSH Per-Connection Server

[Service]
ExecStart=-/usr/sbin/sshd -i
StandardInput=socket

そして、再ロードします。

 $ sudo systemctl daemon-reload