Linuxの基本的な研究ノート-ブートプロセス、モジュール管理、ローダー

起動プロセス、モジュール管理、ローダー

1. Linuxブートプロセスの分析

1.1起動プロセスの概要

システムブートプロセスは、次のように要約できます。

1. BIOSのハードウェア情報を読み込み、セルフテストを実行し、設定に従って最初の起動可能なデバイスを取得します。
2. 最初のブートデバイス（つまり、grub2、spfdiskなどのプログラム）でMBRのブートローダーを読み取り、実行します。
3. ブートローダーの設定に従ってカーネルをロードすると、カーネルがハードウェアの検出とドライバーのロードを開始します。
4. ハードウェアドライブが成功すると、カーネルはsystemdプログラムをアクティブに呼び出し、default.targetプロセスで起動します。
   • systemdはsysinit.targetを実行してシステムを初期化し、basic.targetを実行してオペレーティングシステムを準備します。
   • systemdはmulti-user.targetの下でローカルサービスとサーバーサービスを実行します。
   • systemdはmulti-user.targetの下で/etc/rc.d/rc.loaclファイルを実行します。
   • systemdは、multi-user.targetの下でgetty.targetおよびログインサービスを実行します。
   • systemdは、グラフィカルが必要とするサービスを実行します。

1.2。BIOS、ブートローダー、カーネルローディング

最初に固有名詞について説明しましょう：

• BIOS：従来のBIOSとUEFI BIOSの両方を略してBIOSと呼びます。
• MBR：パーティションテーブルは従来のMBRと新しいGPTで構成されていますが、GPTはいくつかのMBR互換ブロックも予約しているため、以下の手順はブートローダーのインストールではMBRと呼ばれます。つまり、MBRは、ブートローダーをインストールできるディスクの最初のブロックを表しています。

1.2.1、BIOS、ブートセルフテスト、MBR / GPT

パーソナルコンピュータアーキテクチャで、システム全体を起動する場合は、最初にシステムにBIOSをロードさせ、BIOSを介してCMOS情報をロードし、CPUなどのCMOSの設定からホストのハードウェア構成を取得する必要があります。インターフェースデバイスとの通信頻度、起動デバイスの検索シーケンス、ハードディスクのサイズとタイプ、システム時間など

この情報を取得した後、BIOSは電源投入時自己診断（POST）も実行します。次に、ハードウェア検出の初期化の実行を開始し、PnPデバイスを設定し、起動可能なデバイスシーケンスを定義してから、起動デバイスのデータの読み取りを開始します。

私たちのシステムソフトウェアはほとんどハードディスクに置かれているからです！したがって、BIOSは起動デバイスを指定して、ディスク内のオペレーティングシステムカーネルを読み取ることができるようにします。ただし、オペレーティングシステムによってファイルシステムの形式が異なるため、ブート管理プログラムを使用してカーネルファイルの読み込みの問題を処理する必要があるため、このブート管理プログラムはブートローダーと呼ばれます。このブートローダーはどこにインストールされていますか？これは、ブートデバイスの最初のセクターにあります。これは、これまでMBR（マスターブートパーティション）と言ってきたものです。

カーネルファイルを読み込むにはローダーが必要なため、各オペレーティングシステムのローダーは異なります。この場合、BIOSはMBRのローダーをどのように読み込みますか？実際、BIOSはハードウェアINT 13割り込み機能を介してMBRを読み取ります。つまり、BIOSがディスクを検出できる限り（ディスクがSATAまたはSASインターフェイスであるかどうか）、INT 13チャネルを渡すことができます。ディスクの最初のセクターでMBRソフトウェアを読み取る。

1.2.2、ブートローダー機能

私はちょうどと述べローダーの主な機能は、オペレーティングシステムのファイル形式を認識し、それに応じて実行のためにメモリにロードすることです。異なるオペレーティングシステムのファイル形式には一貫性がないため、各オペレーティングシステムには独自のブートローダーがあり、独自のブートローダーを使用しないと、独自のカーネルファイルをロードできません。問題は、複数のシステムについて聞いたことがあるはずですよね？これは、複数の異なるオペレーティングシステムは、ホストにインストールされているされています。ので、（1）独自のオペレーティングシステムのカーネルをロードするために、独自のローダを使用し、しなければならない（2）あなたは、単一のホストを持つことができますどのようにして、一つだけMBRありますか？複数のシステムを同時にインストールするのはどうですか？

ファイルシステムの機能を呼び出す必要があります。実際には、すべてのファイルシステムは、ブートローダーをインストールするには、オペレーティング・システムを提供するために、ブートセクタを予約します、そして通常のオペレーティングシステムは、そのルートディレクトリがデフォルトで配置されているファイルシステムのブートローダーにローダーのコピーをインストールします。いずれかのホストにWindowsとLinuxをインストールした場合、ブートセクター、ブートローダー、MBRの相関関係は次のようになります。

上の図に示すように、各オペレーティングシステムは、デフォルトで一連のブートローダーを独自のファイルシステム（つまり、各ファイルシステムの左下隅にあるボックス）にインストールします。Linuxシステムをインストールするときに、ブートローダーをインストールするように選択できます。 MBRに移動します。インストールしないことも選択できます。MBRへのインストールを選択した場合、理論的には、MBRとブートセクターの両方にブートローダープログラムのコピーを保持します。Windowsのインストールについては、デフォルトでMBRとブートセクターの両方にブートローダーが自動的にインストールされます。そのため、複数のオペレーティングシステムをインストールすると、MBRがさまざまなオペレーティングシステムのブートローダーによって上書きされることがよくあります。

今述べた問題はまだ解決されていません！各オペレーティングシステムはブートローダーをブートセクターにインストールできますが、オペレーティングシステムは独自のブートローダーを介してカーネルをロードできます。問題は、システムにMBRが1つしかないことです。どのようにしてローダーをブートローダーで実行しますか？これには、ブートローダーの主な機能を理解する必要があります。

• メニューの提供：ユーザーはさまざまなブート項目を選択できます。これもマルチブートの重要な機能です。
• カーネルファイルをロードします。ブート可能なプログラムセクションを直接ポイントして、オペレーティングシステムを起動します。
• 他のローダーに転送：ブート管理機能を他のローダーに転送して管理します。

メニュー機能により、ブートする別のカーネルを選択できます。また、コントロール転送機能のため、ローダーを他のブートセクターにロードできます。ただし、Windowsローダーにはデフォルトでコントロール転送機能がないため、Windowsローダーを使用してLinuxローダーをロードすることはできません。

上の図に示すように、私のMBRはLinuxのgrub2ブート管理プログラムを使用しており、すでに3つのメニューがあると想定しています。最初のメニューはLinuxカーネルファイルを直接ポイントし、カーネルを直接ロードして起動します。2番目のメニューはブート管理をWindowsに制御します。このとき、Windowsローダーがブートプロセスを引き継ぎます。この時点で、Windowsを起動できます。3番目のメニューは、ブートローダーでLinuxのブート管理プログラムを使用することです。このとき、別のgrub2メニューがポップアップします。

• 単一選択：MBR（grub2）→カーネルファイル→起動
• メニュー2：MBR（grub2）→ブートセクター（Windowsローダー）→Windowsカーネル→ブート
• メニュー3：MBR（grub2）→ブートセクター（grub2）→ブート

1.2.3、カーネルをロードしてハードウェアとinitramfs関数を検出する

ブートローダーの管理下でカーネルファイルの読み取りを開始すると、Linuxはカーネルファイルをメモリに圧縮し、カーネルの機能を使用して、ストレージデバイス、CPU、ネットワークカード、サウンドカードなど 現時点では、Linuxカーネルは独自の機能でハードウェアを再検出し、BIOSが検出したハードウェア情報を必ずしも使用しません。つまり、カーネルがBIOSの作業を正式に引き継ぎました。では、コアファイルは通常どこに保存されますか？一般的に、それは/ bootに置かれ、/ boot / vmlinuzという名前になります。

[root@li ~]# ls  --format=single-column -F /boot
config-3.10.0-1127.el7.x86_64		#此版本内核被编译时选择的功能与模块配置文件
efi/		
grub/		#旧版的
grub2/		#就是开机管理程序 grub2 相关数据目录
initramfs-0-rescue-1b1f29b2be3d4dafbdcac2da7f5a3c15.img		#底下是虚拟文件系统文件！
initramfs-3.10.0-1127.el7.x86_64.img
symvers-3.10.0-1127.el7.x86_64.gz
System.map-3.10.0-1127.el7.x86_64
vmlinuz-0-rescue-1b1f29b2be3d4dafbdcac2da7f5a3c15*
vmlinuz-3.10.0-1127.el7.x86_64*		#内核文件。最重要的文件！

ハードウェア開発者や他のカーネル機能開発者の便宜のために、Linuxカーネルはカーネルモジュールを動的にロードできます。カーネルモジュールは、通常/ lib / modulesディレクトリに配置されます。モジュールはディスクのルートディレクトリに配置されるため（/ libは/とは別のパーティションに配置できないことに注意してください）、カーネルモジュールがドライバー機能を提供できるように、ブートプロセス中にルートディレクトリにハングアップする必要があります。また、ディスク内のファイルシステムへの影響を心配するために、ルートディレクトリは起動プロセス中に読み取り専用でマウントされます。

仮想ファイルシステムは通常、ファイル名/ boot / initrdまたは/ boot / initramfsを使用します。このファイルの特徴は、ブートローダーを介してメモリにロードでき、ファイルがメモリ内のルートディレクトリとして圧縮およびシミュレーションされることです。そして、メモリ内のこのシミュレートされたファイルシステムは、起動プロセス中に最も必要なカーネルモジュールをロードするための実行可能プログラムを提供できます。通常、これらのモジュールはUSB、RAID、LVM、SCSIおよびその他のファイルシステムとディスクインターフェイスです。ドライバー。ヘルプカーネルがsystemdを再度呼び出して、後続の通常のブートプロセスを開始するまで待ちます。

上の図に示すように、ブートローダーはカーネルとinitramfsをロードし、ルートディレクトリと呼ばれるメモリ内のinitramfsを解凍できます。カーネルはこれから適切なドライバーをロードし、最終的に仮想ファイルシステムを解放して、実際のルートディレクトリをマウントします。ファイルシステムは、後続の通常のブートプロセスを開始できます。

カーネルが完全に読み込まれると、ホストが正常に動作し始め、次にシステムの最初のプログラムsystemd！

1.3、最初のプログラムはsystemdで、default.targetを使用してブートプログラム分析に入ります

カーネルが読み込まれ、ハードウェアの検出とドライバーの読み込みが完了すると、ホストハードウェアはこの時点で準備ができているはずです。この時点で、カーネルはsystemdである最初のプログラムをアクティブに呼び出します。これが、pstree -pコマンドを使用すると、systemdのPID番号が1であることがわかります。systemdの主な機能は、システムのホスト名、ネットワーク設定、言語処理、ファイルシステム形式、その他のサービスの起動など、ソフトウェアを実行するための環境を準備することです。すべてのアクションは、systemdのデフォルトの起動サービスセット、つまり/etc/systemd/system/default.targetを通じて計画されます。また、systemdは長年使用されてきたランレベルを廃止しました。

1.3.1、共通の動作環境ターゲットと互換性およびランレベルレベル

事前設定の動作環境として使用できる主な項目は、multi-user.targetおよびgraphic.targetです。もちろん、rescue.target、shutdown.target、emergency.targetなどの特別な動作環境や、initrd.targetもあります。

しかし、以前はsystemVはランレベルという概念を使用してシステムを起動していましたが、systemdは古いスタイルのsystemV操作動作との互換性を保つために、ランレベルとオペレーティング環境を組み合わせています。

SystemV	システム
init 0	systemctl poweroff
init 1	systemctlレスキュー
init [234]	systemctl isolate multi-user.target
init 5	systemctl分離グラフィカル。ターゲット
init 6	systemctl reboot

1.3.2、systemd処理フロー

/etc/systemd/system/default.targetのデフォルトの操作インターフェースを取得した後、システムは次に何をしますか？まず、/ usr / lib / systemd / system /ディレクトリにリンクして、multi-user.targetまたはgraphic.targetのいずれかを取得します。graphic.targetを使用していると仮定すると、systemdは次のディレクトリである2つの場所で設定を探します。

• /etc/systemd/system/graphic.target.wants/：ユーザーはロードされたユニットを設定します
• /usr/lib/systemd/system/graphical.target.wants/：デフォルトでロードされるユニット

次に、構成ファイル/usr/lib/systemd/system/graphical.targetに次の内容が含まれています。

[root@li ~]# cat /usr/lib/systemd/system/graphical.target
[Unit]
Description=Graphical Interface
Documentation=man:systemd.special(7)
Requires=multi-user.target		#必须先加载 multi-user.target 
Wants=display-manager.service	#启动完 graphical.target 之后，还必须启动 display-manager.service
Conflicts=rescue.service rescue.target
After=multi-user.target rescue.service rescue.target display-manager.service
AllowIsolate=yes

[root@li ~]# cat /usr/lib/systemd/system/multi-user.target
[Unit]
Description=Multi-User System
Documentation=man:systemd.special(7)
Requires=basic.target		#必须先加载 basic.target
Conflicts=rescue.service rescue.target
After=basic.target rescue.service rescue.target
AllowIsolate=yes

システムによってデフォルトでロードされるユニットは何ですか？

[root@li ~]# ls /usr/lib/systemd/system/multi-user.target.wants/
dbus.service           plymouth-quit-wait.service      systemd-update-utmp-runlevel.service
getty.target           systemd-ask-password-wall.path  systemd-user-sessions.service
plymouth-quit.service  systemd-logind.service

ユーザー定義の単位は何ですか？

[root@li ~]# ls /etc/systemd/system/multi-user.target.wants/
auditd.service      kdump.service           rhel-configure.service  vmtoolsd.service
crond.service       NetworkManager.service  rsyslog.service
firewalld.service   postfix.service         sshd.service
irqbalance.service  remote-fs.target        tuned.service

実際、システムのサービス起動プロセスを知る最も簡単な方法は、systemctl list-dependencies graphic.targetコマンドです。ただし、背後にある構成ファイルの意味を知りたい場合は、/ etcおよび/ usr / libのそれぞれのGraphical.target.wants /ディレクトリにあるデータを見つける必要があります。もちろん、構成ファイルのRequiresの値で表されるサービスも最初にロードする必要があります。

1.3.3、systemdはmulti-user.targetの下でサービスを開始します

カーネルドライバーハードウェアが読み込まれた後、sysinit.targetの初期化プロセスを通じてシステムにアクセスでき、basic.targetが追加されて、システムがオペレーティングシステムの基礎になり、サーバーがスムーズに実行するために必要なさまざまなホストサービスが作成されます。そして、サーバー機能を提供するネットワークサービスのスタート。これらのサービスの起動は、ほとんどがmulti-user.targetオペレーティング環境に関連付けられています。/etc/systemd/system/multi-user.target.wants/に移動して、デフォルトの起動サービスを確認できます。つまり、一般的に言えば、サービス起動スクリプトの設定は次のディレクトリにあります。

• / usr / lib / systemd / system：システムのデフォルトのサービス起動スクリプト設定
• / etc / systemd / syetem：管理者によって開発および設定された起動スクリプト

ユーザーがホストのローカルサービスとサーバーネットワークサービスのさまざまなユニットを包括したい場合は、それを/etc/systemd/system/multi-user.target.wants/ディレクトリに配置してリンクを作成します。起動時に自動的に起動できます。

[root@li lib]# systemctl enable vsftpd.service
Created symlink from /etc/systemd/system/multi-user.target.wants/vsftpd.service to /usr/lib/systemd/system/vsftpd.service.
[root@li lib]# systemctl disable vsftpd.service
Removed symlink /etc/systemd/system/multi-user.target.wants/vsftpd.service.

1.3.4、互換性のあるsystemV rc-local.service

過去にLinuxを使用したことがあるユーザーは、システムの起動後にシステムで追加のプログラムを実行したい場合は、プログラムの命令またはスクリプトの絶対パス名を/etc/rc.s/rcに書き込むことができることをおそらく知っています。このファイルに.local。新しいsystemdメカニズムでは、systemd起動スクリプト設定ファイルを/ etc / systemd / systemに直接書き込んでから、rc.localファイルを直接使用するのではなく、systemctl enableメソッドを使用して設定および起動することをお勧めします。

systemdの新しいバージョンに互換性のある方法はありますか？もちろん、それはrc-local.serviceサービスの機能です。このサービスを開始する必要はありません。このサービスを開始するかどうかを決定する実行権限が/etc/rc.d/rc.localにあるかどうかを決定します。

#1、先看一下 /etc/rc.d/rc.local 的权限，然后检查一下 multi-user.target 有没有这个服务
[root@li lib]# ll /etc/rc.d/rc.local
-rw-r--r--. 1 root root 473 8月   7 01:30 /etc/rc.d/rc.local

[root@li lib]# systemctl status rc-local.service
● rc-local.service - /etc/rc.d/rc.local Compatibility
   Loaded: loaded (/usr/lib/systemd/system/rc-local.service; static; vendor preset: disabled)
   Active: inactive (dead)
[root@li lib]# systemctl list-dependencies multi-user.target | grep rc-local
#明明就有这个服务，但是 rc.local 不具有执行的权限，因此这个服务不会被执行

#2、加入 x 权限后，再看一下 rc-local 是否可被执行
[root@li lib]# chmod a+x /etc/rc.d/rc.local; ll /etc/rc.d/rc.local
-rwxr-xr-x. 1 root root 473 8月   7 01:30 /etc/rc.d/rc.local
[root@li lib]# systemctl daemon-reload
[root@li lib]# systemctl list-dependencies multi-user.target | grep rc-local
● ├─rc-local.service		#这个服务确实被记录到启动的环境下了

chmod a + x /etc/rc.d/rc.localにより、スクリプトの多くをファイル/etc/rc.d/rc.localに置くことができ、システムが起動するたびに、このファイル内のファイルが実行されます命令。

1.3.5。起動プロセスで使用される主な設定ファイル

基本的に、systemdには独自の構成ファイル処理メソッドがありますが、systemVとの互換性を保つために、多くのスクリプト設定は/ etc / sysconfig /にある環境構成ファイルを読み取ります。一般的な構成ファイル：

• モジュールについて：/etc/modprode.d/ .confおよび/etc/modules-load.d/ .conf

  実際、モジュールのロードの問題に対処する場所は2つあります。

  • /etc/modprode.d/*.conf：モジュールをロードするカーネルの場所が必要なだけです。
  • /etc/modules-load.d/*.conf：モジュールパラメータの場所を追加できます。

• / etc / sysconfig / *

  • authconfig

    このファイルは主に、ローカルの/ etc / passwd、/ etc / shadowなどを使用するかどうか、および/ etc / shadowパスワードレコードに使用されるアルゴリズム暗号化など、ユーザーのID認証メカニズムを規制するために使用されます。

  • cpupower

    このファイルは、cpupower.serviceサービスの開始時に読み取られます。

  • firewalld、iptables-config、etables-config

    ファイアウォールに関連するパラメーター

  • network-scripts /

このファイルは、ローカルの/ etc / passwd、/ etc / shadowなどを使用するかどうか、および/ etc / shadowパスワードレコードを暗号化するアルゴリズムなど、ユーザーのID認証メカニズムを主に規制します。

• cpupower

  このファイルは、cpupower.serviceサービスの開始時に読み取られます。

• firewalld、iptables-config、etables-config

  ファイアウォールに関連するパラメーター

• network-scripts /

  ネットワークカード設定パラメーター