PK
パーネルカニック研究所
今日もどこかでkernel panic。
root@pk-lab:~#

LFSとは何か:Linuxの心臓部を自らの手で組み立てる旅

連載ナビ

この連載は「Linuxを使えるようになる」ではなく、「Linuxがどう動いているのか」を理解するための実践シリーズです。

今回は Linuxを理解する 〜 LFSで学ぶLinux内部構造 〜 の Part 3 / 第1回として、仕組みのつながりを意識しながら学びます。

—

LFSは配布物ではなく、OSを丸ごとソースからビルドする「手順書」

Linux From Scratch(LFS)と聞くと、UbuntuやFedoraのような「ダウンロードしてインストールするOS」の一種だと思うかもしれません。違います。

結論から言うと、LFSとは、コンパイラ・Cライブラリ・シェル・カーネル・ブートローダまで、Linuxシステムを構成するすべてのソフトウェアをソースコードからビルドして1つのOSに組み上げるための、公式の手順書(LFSブック)と、それに沿った学習プロジェクトです。成果物はISOイメージではなく、あなたの手元で make を何十回も実行した末に起動する、あなただけのLinuxシステムです。

LFSブックは linuxfromscratch.org で無償公開されており、使用するパッケージのバージョンと、実行するコマンドがすべて1冊にまとまっています。つまりLFSでやることは「本に書かれたコマンドを、意味を理解しながら順番に実行していくこと」です。魔法でも職人芸でもなく、再現可能な手順の積み重ねです。

ビルド済みバイナリを使う限り、「何が・どの順で・なぜ」が見えないから

なぜわざわざ全部ソースからビルドするのか。理由は、Part 1でも触れたとおり、普段のディストリビューションではビルドと依存解決がすべて済んだ状態で配られるため、部品同士の依存関係が一切見えないからです。

たとえば apt install gcc は数十秒で終わりますが、その裏には次のような依存の連鎖が隠れています。

  • GCC をビルドするには、アセンブラ as とリンカ ld(Binutils)が先に必要
  • GCC で作ったプログラムを動かすには、標準Cライブラリ(Glibc)が必要
  • ところが Glibc 自体も GCC でビルドする必要がある(鶏と卵の循環依存)
  • さらに Glibc のビルドには Linux カーネルのヘッダファイルが必要

この循環をどう断ち切るか、という問いに対する答えが、LFSの最初の山場である「クロスツールチェーンの構築」です。ビルド済みバイナリの世界にいる限り、この問いに出会うことすらありません。LFSは、依存関係の地図を白紙から自分で描かせることで、「Linuxがどう成り立っているか」を体験として理解させてくれます。

LFSブックの実際の工程:大きく4つのステージ

LFSブック(現行は12系)の構成を、実際の作業に即して整理します。

1. ホストシステムの準備

既存のLinux環境(UbuntuのVMなど)に、LFS専用のパーティションを用意してマウントし、環境変数 LFS(例: /mnt/lfs)を設定します。ブックには「ホストに bash・gcc・make などの必要ツールが揃っているか」を確認するチェックスクリプトも載っています。

2. クロスツールチェーンの構築

$LFS/tools 以下に、ホストから独立した一時的なツールチェーンを作ります。ビルド順は Binutils(1回目)→ GCC(1回目)→ Linuxカーネルヘッダ → Glibc → libstdc++ と厳密に決まっています。GCCを2回ビルドするのは、1回目の時点ではまだGlibcが存在しないため、機能を絞った暫定版を先に作り、Glibc完成後に完全版を作り直す必要があるからです。

3. chroot環境への移行と一時ツールの整備

chroot コマンドで、ルートディレクトリを $LFS に切り替えた隔離環境に入ります。実際に実行するのは、おおよそ次のようなコマンドです。

`bash

sudo chroot "$LFS" /usr/bin/env -i \

HOME=/root TERM="$TERM" PS1='(lfs chroot) \u:\w\$ ' \

PATH=/usr/bin:/usr/sbin /bin/bash –login

`

env -i で環境変数を空にしてから入るのがポイントで、ホスト側の PATH や設定が新システムのビルドに混入する事故を防ぎます。ここから先は、ホストのコマンドやライブラリには一切頼れません。

4. 最終システムの構築と起動

chroot内で、基本システムを構成する約90個のパッケージ(Glibc、Bash、Coreutils、systemdなど)を依存順に1つずつ ./configure && make && make install していきます。最後にLinuxカーネルをビルドし、GRUB(ブートローダ)を設定して再起動。うまくいけば、自分の手で組んだシステムのログインプロンプトが表示されます。

工程の一つひとつが「なぜ」を突きつけてくる

この工程を淡々とこなすだけでも動くOSはできますが、LFSの本当の価値は、各手順が具体的な「なぜ」を突きつけてくることです。たとえば次のような問いに、作業を終える頃には自分の言葉で答えられるようになります。

  • なぜBinutilsを最初にビルドするのか — GCCのビルド自体が、内部でアセンブラ as とリンカ ld を呼び出すから。工具を作る工具が先、という順序が実物で確認できます。
  • なぜGCCを2回(実際には最終システムも含め複数回)ビルドするのか — 前述の循環依存を段階的に解消するため。1回目は「Glibcなしでも動く最小構成」、2回目以降は「新しいGlibcにリンクした完全版」です。
  • なぜchrootで隔離するのか — 隔離しないと、ビルド中のプログラムがホストの /usr/include や /usr/lib を拾ってしまい、「ホストのライブラリ混じりの、再現性のないシステム」ができてしまうから。

これらはすべて、次回以降で扱う「ツールチェーン(GCC・Glibc・Binutils)」の理解に直結します。逆に言えば、ツールチェーンを理解しないままLFSに入ると、序盤の数章が「意味の分からないコマンドの写経」になってしまいます。

完成するのはOSと、依存関係の地図

LFSとは、Linuxシステムの全部品をソースからビルドして組み上げるための手順書であり、その過程で「部品同士の依存関係の地図」を自分の頭の中に作る学習プロジェクトです。完成したOSは日常使いには向きませんが、地図は一生ものです。

Part 3の残りの回では、LFS序盤の主役であるツールチェーンを分解していきます。次回はまず「ツールチェーンとは何か」——ソースコードが実行ファイルになるまでに、どのプログラムがどの順で仕事をしているのかを、実際のコマンドで確認します。

LFSプロジェクトの準備

LFSの旅を始めるにあたり、まずは手順書と作業場所のイメージを掴みましょう。


# LFSのビルド先を指す環境変数。LFSブック全体がこの変数を前提に進む
export LFS=/mnt/lfs

# 本番ではLFS専用パーティションをここにマウントする(デバイス名は環境に合わせる)
# sudo mkdir -pv $LFS
# sudo mount /dev/sdb1 $LFS
# sudo mkdir -pv $LFS/sources

# まずは手元にLFSブック(1ファイル版)を取得して、全体の流れを眺めてみる
mkdir -p $HOME/lfs-book
cd $HOME/lfs-book
curl -LO https://www.linuxfromscratch.org/lfs/downloads/12.1/LFS-BOOK-12.1-NOCHUNKS.html

# 最新の安定版は https://www.linuxfromscratch.org/lfs/ で確認できる

ダウンロードしたHTMLをブラウザで開き、目次だけでも眺めてみてください。この記事で説明した4つのステージが、そのまま章立てになっていることが分かるはずです。

チェックポイント

  • LFSが、配布されるOSではなく「ソースからOSを組み上げるための手順書」であることを説明できる
  • クロスツールチェーンの構築順(Binutils → GCC → カーネルヘッダ → Glibc)と、GCCを複数回ビルドする理由を説明できる
  • chroot と env -i を使ってホスト環境から隔離する理由を説明できる
  • LFSブックを実際にダウンロードし、目次を眺めた

今回理解できたこと

  • LFSは、全部品をソースコードからビルドして自分だけのLinuxシステムを作る学習プロジェクトであること
  • GCCとGlibcの間には循環依存があり、それを解消するためにクロスツールチェーンと複数回のビルドが必要なこと
  • chroot による隔離は、ホストのファイルが新システムに混入するのを防ぐためであること
  • LFSの価値は完成品よりも、構築過程で得られる「依存関係の地図」にあること