Linux From Scratch(LFS)は、既存のディストリビューションを入れるのではなく、コンパイラやシェル、カーネルまでをソースコードから1つずつビルドして自分のLinuxを組み立てるための手順書プロジェクトです。2026年10月時点の最新安定版は、2026年9月1日に公開されたLFS 13.1(systemd版)です。この記事では公式の書籍(The LFS Book)の記述をもとに、必要な環境、構築の流れ、GCCを2回作る理由、13.1で本編に入ったUEFI起動、ビルド時間の見積もり方、日本語版の入手先、LFSが向く用途と向かない用途を整理します。
まとめ:Linux From Scratchの要点(13.1時点)
- LFSはディストリビューションではなく手順書。既存のLinux(ホスト)上でクロスツールチェーンを作り、chrootで参照するルートを切り替えて新しいシステムを組み立てる。
- 最新安定版はLFS 13.1-systemd(2026-09-01)。binutils 2.47・GCC 16.2.0・glibc 2.44・Linux 7.1.8。System V版は12.4で更新が止まっている。
- 13.1からUEFIで起動する手順が本編に入った。13.0まではBLFSのページを見る必要があった。Secure Bootには対応しないので無効にする。
- 推奨環境は4コア以上・メモリ8GB以上。パーティションは最小で約10GB、使い続けるなら30GBが目安。ホストのGCCが16.2.0より新しいとビルドが壊れやすい。
- 日本語訳はlfsbookjaで、13.1と13.1-systemdの訳が2026-09-15に公開済み。開発版の訳も追随している。
- LFSにパッケージマネージャーは無く、セキュリティ更新の追跡も自分の責任になる。学習用・検証用に向き、業務サーバーの本番には向かない。
Linux From Scratchの仕組みと目的
LFSは、Gerard Beekmans氏が自分好みのLinuxをソースから作った経験を書籍にしたものです。同氏は書籍の序文で、1998年にLinuxを学び始め、どのディストリビューションにも決めきれずに、バイナリパッケージを使わずすべてをソースからコンパイルすると決めたと書いています。書籍の著作権表記は1999年から始まり、現在の編集総括はBruce Dubbs氏です。
公式が挙げるLFSの目的は、Linuxシステムが内部でどう動き、部品同士がどう依存しているかを理解することです。そのうえで、不要なプログラムを入れない小さなシステムを作れること、すべてのソースを自分で監査してセキュリティパッチを当てられることを利点に挙げています。用途の例として、ブータブルCD、USBメモリ、組み込みシステムが書籍に挙がっています。
LFS・BLFS・ALFSなどサブプロジェクトの役割
Linux From Scratchは1冊の本ではなく、複数のサブプロジェクトの集まりです。最初に読むのは本体のLFSで、他はLFSの完成後に必要に応じて使います。
| 名称 | 正式名 | 役割 |
|---|---|---|
| LFS | Linux From Scratch | 本体の書籍。全プロジェクトの土台 |
| BLFS | Beyond Linux From Scratch | LFS完成後にデスクトップやサーバー機能を足す |
| ALFS | Automated Linux From Scratch | LFS・BLFSのビルドを自動化(実装はjhalfs) |
| MLFS | Multilib Linux From Scratch | 32ビットのバイナリも実行できる構成 |
| GLFS | Gaming Linux From Scratch | SteamやWineなどゲーム関連を導入 |
| SLFS | Supplemental Linux From Scratch | BLFSのさらに外側の補足 |
Beyond Linux From Scratch(BLFS)は、LFS完成後のシステムを拡張するための手順書です。BLFSのニュースによると、BLFS 13.1は2026年9月3日に公開され、LFSの上に1,000以上のパッケージを導入する手順と、前版からの212件のセキュリティ更新を収録しています。GNOME、KDE Plasma、Xfce、LXQtの各デスクトップ環境も含まれるため、LFSで作った最小構成をデスクトップとして使えるところまで育てられます。
ALFSについて公式は、人手不足から書籍の自動化へ方向を変え、主に編集者が手順の品質を確かめるために使っていると説明しています。手順を書籍のXMLソースから直接取り出して実行するBashスクリプト(jhalfs)なので、初回から使うと何を作っているのかが見えなくなります。ALFSのページも、LFSとBLFSを2〜3回通したあとに自動化のありがたみが分かると書いています。1回目は手で打ち、2回目以降の再構築にALFSを使う順番が妥当です。
対応アーキテクチャとライセンス
書籍が主な対象とするのは、AMD・Intelのx86(32ビット)とx86_64(64ビット)です。対象アーキテクチャの節は、PowerPCとARMでも修正を加えれば動くことが知られている、という書き方にとどめています。RISC-VやARM64向けの構築記録も個人のブログなどにありますが、手順の修正は自分で行うことになり、書籍の編集者のサポート対象ではありません。初回はx86_64のPCか仮想マシンで進めてください。
64ビットの既定構成は64ビットの実行ファイルだけを動かす「純粋な」64ビットシステムで、32ビットのバイナリも動かすマルチライブラリ構成は本編では扱いません(MLFSが扱います)。書籍本体のライセンスはCreative Commons 表示-非営利-継承 2.0で、書籍から取り出したコマンドなどの手順はMITライセンスで使えます。
LFS 13.1の版構成とSystem V版の更新停止
LFSは原則として毎年3月と9月に新しい版が出ます。直近3版の変化は次のとおりです。
| 版 | 公開日 | 主なツールチェーン | カーネル | 初期化方式 |
|---|---|---|---|---|
| 12.4 | 2025-09-01 | binutils 2.45・GCC 15.2.0・glibc 2.42 | 6.16.1 | System V版とsystemd版 |
| 13.0 | 2026-03-05 | binutils 2.46・glibc 2.43 | 6.18.10 | systemd版のみ |
| 13.1 | 2026-09-01 | binutils 2.47・GCC 16.2.0・glibc 2.44 | 7.1.8 | systemd版のみ |
LFSのニュースでは、13.1-rc2の告知に「System V版のLFSは直接更新していない。System V版の最新は12.4のまま」と書かれています。古い解説記事やブログの多くはSystem V版(SysVinit)を前提にしているため、13.1でブートスクリプトやサービス設定の章を読むときは、systemd版の記述と食い違っていないか確かめてください。
13.1の告知によると、前版から46パッケージが更新・追加され、attr、acl、expat、glibc、カーネル、Python、systemd、util-linux、vim、zlibにセキュリティ更新が入っています。13.1-rc2の告知では、直近半年でLFSとBLFSのパッケージに195件のセキュリティ更新があったとされています。これから始めるならsystemd版の13.1を選んでください。12.4のSystem V版を選ぶと、これらの脆弱性への対処を自分で追いかけることになります。
13.1で手順そのものが大きく変わったのは起動の章です。13.1の変更履歴には2026-04-04付で「Provide UEFI boot support」とあり、UEFIでGRUBを入れる手順が本編に入りました。13.0の書籍は「UEFIで起動するならこのページを飛ばし、BLFSのページの手順で設定する」と案内していました。12.4以前を前提にした解説で「UEFIはBLFSを見る」と書かれているのはこのためです。
安定版のほかに開発版(版番号がr13.1-の後に通し番号が付く)が随時更新されています。2026年10月24日付のr13.1-29では、Linux 7.3、OpenSSL 4.1.0、systemd 262.1、GRUB 2.16などへの更新が入っています。開発版は次の安定版(例年どおりなら2027年3月)に向けた作業中の書籍なので、通常は安定版を使い、後述するホストのGCCが新しすぎる場合などに限って開発版を選びます。
日本語版(lfsbookja)の入手先と原典との対応
Linux From Scratchの日本語訳は、LFSbook in Japanese(lfsbookja)で公開されています。2026年10月時点の配布状況は次のとおりです。
- LFS 13.1/LFS 13.1-systemdの日本語訳:2026-09-15公開(HTML・PDF・wget-list・md5sums)
- 開発版の日本語訳:随時更新(2026-10-25時点でr13.1-29)
- 13.0、12.4などの旧版の日本語訳も「Older Versions」から取得可能
日本語訳サイトには13.1のSystem V版の訳もありますが、本家が安定版として案内しているのはsystemd版だけです。迷ったら「13.1-systemd」を選び、エラーが出たときは同じ版の英語原典と見比べてください。メーリングリストやフォーラムで質問するときも、英語原典の節番号で書くと話が通じやすくなります。
構築前に揃えるホスト環境と必要スペック
LFSは何もないところから始めるのではなく、DebianやFedoraなどの既存ディストリビューション(ホスト)にあるコンパイラやシェルを使って新しいシステムを作ります。書籍は、ホストのインストール時に「開発ツール」を含めておくよう勧めています。
推奨ハードウェアとパーティション容量
13.1のホストシステム要件が推奨するのは、4コア以上のCPUと8GB以上のメモリです。これを満たさない古いマシンでも構築はできますが、書籍に載っている時間より大幅に長くかかります。
ディスクは、最小構成で約10GBのパーティションがあればソースのアーカイブを置いてビルドできます。構築後にソフトウェアを追加して普段使いのLinuxにするなら30GBが目安です。第3章でダウンロードするパッケージは86個、合計で約628MBです。ソースのアーカイブより、ビルド中に展開・生成されるファイルのほうが容量を使います。
ホストのソフトウェア要件とversion-check.sh
ホストには、Bash 3.2以上、Binutils 2.13.1以上、GCC 5.4以上(C++コンパイラのg++を含む)、Python 3.4以上、Linuxカーネル5.10以上などが必要です。/bin/shがbashを、/usr/bin/awkがgawkを、/usr/bin/yaccがbisonを指している必要もあります。dashやmawkを指していても動く場合はありますが、公式の検証・サポート対象外です。
新しすぎるホストにも注意が必要です。13.1はGCC 16.2.0とBinutils 2.47までしか検証しておらず、書籍には「新しいGCCはこのリリースのビルドを壊す可能性が高い」と警告があります。ホストのGCCがそれより新しい場合に書籍が挙げる選択肢は、新しい版のLFSがあればそれを使う、古いホストを使う、ホストがGCCのダウングレードに対応していれば戻す、最新の開発版を使う、の4つです。開発版には、パッケージの新版が出てから通常2〜4週間で反映されます。
要件は、書籍の2.2節に載っている version-check.sh を保存して実行すれば一括で確認できます。スクリプトはcoreutils、bash、gccなどの版、/bin/shなどの参照先、g++でのコンパイル可否、nprocが返す論理コア数を順に検査し、足りない項目を「ERROR」と表示します。
# 2.2節のスクリプトを version-check.sh として保存してから実行
bash version-check.sh
# 出力の例(抜粋)
OK: Coreutils 9.4 >= 8.1
ERROR: Linux Kernel (5.4.0) is TOO OLD (5.10 or later required)
ERRORが出た項目は、ホストのパッケージを入れ直すか、ホストのディストリビューション自体を替えてから先に進みます。ヘッダーが -dev や -devel という別パッケージに分かれているディストリビューションでは、そちらも入れておく必要があります。
仮想マシンで構築するときの準備
VirtualBoxやKVMの仮想マシン上でもLFSは構築できます。構築前に確認したい事項は次の3つです。
- ホスト用の仮想ディスクとは別に、LFS用の仮想ディスクを1本追加しておくと作業対象を分けられる。第2章でフォーマットする前に、lsblk などで対象のデバイス名がLFS用のディスクであることを必ず確かめる。
- LFSにはSecure Bootに必要なパッケージが含まれない。UEFIの仮想マシンで起動させるなら、ファームウェア設定でSecure Bootを無効にしておく(書籍10.4.2節)。
- 第10章のカーネル設定で、仮想ディスクのドライバ(KVMのvirtioディスクならvirtio_blk)をモジュール[M]ではなく組み込み[*]にする。
3つ目は、起動の最後でルートファイルシステムが見つからずに止まる典型的な原因です。LFSの手順はinitramfs(起動時にルートを見つけるための一時的なファイルシステム)を作りません。BLFSのinitramfsの解説も、LFSでinitramfsが要るのはネットワーク上のルート、LVM、暗号化したルート、LABELやUUIDでの指定という主な4つの場合で、「それ以外はたいていカーネルの設定が正しくないことを意味する」としています。ルートのディスクドライバをモジュールにすると、そのモジュールを読み込む前にルートをマウントしようとして失敗します。仮想マシンでのディスクの見え方はKVMの記事「KVMとは?カーネル仮想化の仕組みとvirt-installでのVM構築を実装目線で解説」が参考になります。
仮想マシンの最大の利点はスナップショットです。第7章の終わりで一時ツールのバックアップを取る手順がありますが、仮想マシンなら章の切れ目ごとにスナップショットを取っておくことで、失敗したときに章の頭から簡単にやり直せます。
構築手順の全体像(第2章から第11章)
LFS 13.1の構築は、書籍の章立てに沿って次の順に進みます。以下のコードは各節の要所を抜き出したもので、ディレクトリ作成や所有者変更などの工程を省いています。実際に作業するときは、使用する版の正誤表(Errata)とセキュリティ勧告を確認したうえで、同じ版の書籍を最初から順に追ってください。
| 章 | 作業 | 実行するユーザー・環境 |
|---|---|---|
| 第2章 | ホスト確認・パーティション作成・マウント | ホストのroot |
| 第3章 | パッケージとパッチのダウンロード | ホストのroot |
| 第4章 | ディレクトリ作成・lfsユーザー・環境設定 | ホストのroot → lfs |
| 第5章 | クロスツールチェーン(binutils・GCC・glibc) | lfsユーザー |
| 第6章 | 一時ツールのクロスコンパイル | lfsユーザー |
| 第7章 | 仮想ファイルシステムの準備・chroot・残りの一時ツール | ホストのroot → chroot内のroot |
| 第8章 | 本番のシステムソフトウェアを構築 | chroot内のroot |
| 第9章 | ネットワーク・systemdなどの設定 | chroot内のroot |
| 第10章 | fstab作成・カーネル構築・GRUB起動設定 | chroot内のroot |
| 第11章 | 再起動して新システムで起動 | — |
LFS用パーティションの作成と環境変数LFSの設定
第2章では、cfdiskやfdiskでLinux用のパーティションを作り、ext4でフォーマットしてマウントします。書籍全体を通して、マウント先は環境変数 LFS で参照します。例として使われるのは /mnt/lfs です。
# 2.5節:ファイルシステムの作成(<xxx>は作成したパーティション)
mkfs -v -t ext4 /dev/<xxx>
# 2.6節:LFS変数とumaskの設定
export LFS=/mnt/lfs
umask 022
# 2.7節:マウント
mkdir -pv $LFS
mount -v -t ext4 /dev/<xxx> $LFS
この LFS 変数の設定漏れが、最初につまずきやすい点です。変数が空のまま後の手順を実行すると、$LFS/tools が /tools に化けてホストのルートに書き込みます。端末を開き直したら、まず echo $LFS で値を確かめる習慣をつけてください。
lfsユーザーとクリーンな環境の作成
第5章と第6章は、rootではなく専用の一般ユーザー lfs で作業します。rootのまま打ち間違えるとホストを壊すおそれがあるためです。第4章でユーザーを作ります。
groupadd lfs
useradd -s /bin/bash -g lfs -m -k /dev/null lfs
このあと書籍4.3節に従い、$LFS 配下の作業ディレクトリの所有者をlfsに変更してから、su - lfs でlfsユーザーに切り替えます。以降の設定ファイルは、lfsユーザーのホームに作るものです。
lfsユーザーで、まず .bash_profile を作ります。exec env -i でホストの環境変数をすべて捨て、HOME・TERM・PS1だけを残したシェルに置き換えるためのファイルです。
cat > ~/.bash_profile << "EOF"
exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash
EOF
続いて .bashrc で、必要な変数だけを設定し直します。
cat > ~/.bashrc << "EOF"
set +h
umask 022
LFS=/mnt/lfs
LC_ALL=POSIX
LFS_TGT=$(uname -m)-lfs-linux-gnu
PATH=/usr/bin
if [ ! -L /bin ]; then PATH=/bin:$PATH; fi
PATH=$LFS/tools/bin:$PATH
CONFIG_SITE=$LFS/usr/share/config.site
export LFS LC_ALL LFS_TGT PATH CONFIG_SITE
EOF
書籍4.4節では、このあと MAKEFLAGS の追記と source ~/.bash_profile による読み込みまでを行います。PATH の先頭に $LFS/tools/bin を置くのは、第5章で作ったクロスツールをホストのコンパイラより先に使わせるためです。set +h はbashのコマンド位置の記憶を無効にし、新しく入ったツールがすぐ使われるようにします。
クロスツールチェーンとGCCを2回作る理由
第5章では、binutils、GCC、Linux APIヘッダー、glibc、libstdc++の順にクロスツールチェーンを作ります。ビルドするマシンと動かすマシンが同じx86_64なのにクロスコンパイルを使う理由を、書籍のツールチェーンの技術的な説明は「クロスコンパイルしたものはホスト環境に依存できない」点に置いています。.bashrc の LFS_TGT が x86_64-lfs-linux-gnu のようにホスト(例:x86_64-pc-linux-gnu)と違う名前になっているのは、同じアーキテクチャをあえて別のマシンとして扱うためです。
ここで分かりにくいのが、GCCを第5章と第6章で2回、さらに第8章でもう1回ビルドする点です。1回目は、まだglibcが無い状態でコンパイラを作るので、glibcに依存する部分を切り落とします。13.1のGCC 1回目の節にある主なオプションの役割は次のとおりです。
| オプション | 役割 |
|---|---|
| –with-newlib | libgccからCライブラリが必要なコードを外す |
| –without-headers | ターゲットの標準ヘッダーを探さない |
| –disable-shared | 内部ライブラリを静的リンクする |
| –disable-threads | スレッド対応を外す |
| –disable-libstdcxx | C++標準ライブラリを作らない |
こうして作った機能を絞ったコンパイラでglibcをビルドし、libstdc++は後から単独でビルドします。glibcがそろったあとの第6章の2回目では、共有ライブラリやスレッドに対応したLFS用のネイティブGCCを作ります。ただし、一部のライブラリは省いた一時構成です。この時点で、ツールチェーンはホストのライブラリに頼らずに動くようになります。第8章でまた作り直すのは、一時構成で無効になっていた機能を含めてLFS自身のネイティブコンパイラで再構築し、完成後に再インストールしても同じ構成を得られるようにするためです。各パッケージのテストスイートを実行する目的もあります。
第6章で一時ツールをそろえたら、第7章でchrootに入ります。chrootはパスの起点(ルート)を $LFS に切り替えるだけで、ホストから隔離する仕組みではありません。入る前にホストの /dev をバインドマウントし、proc・sysfsなどの仮想ファイルシステムもマウントするため、chroot内の操作がホストのデバイスに届くことは覚えておいてください。
chroot "$LFS" /usr/bin/env -i \
HOME=/root \
TERM="$TERM" \
PS1='(lfs chroot) \u:\w\$ ' \
PATH=/usr/bin:/usr/sbin \
MAKEFLAGS="-j$(nproc)" \
TESTSUITEFLAGS="-j$(nproc)" \
/bin/bash --login
プロンプトが (lfs chroot) で始まっていれば、chrootの中にいます。第8章では、この中でglibc、GCC、systemdなどの本番パッケージを順に作ります。
カーネルのビルド
書籍は、初めてのカーネルビルドを「LFSで最も難しい作業の1つ」としています。設定項目は約12,000あり、多くのマシンで必要なのはその3分の1程度です。最初の目標は最適化ではなく、再起動後にコマンドラインからログインできることです。
make mrproper
make menuconfig
make
make menuconfig では、書籍10.3節が列挙する項目を有効にします。LFSのパーティションがNVMe SSD上にある(デバイス名が /dev/nvme* になる)場合は「NVM Express block device」を組み込みにしておかないと起動しない、と書籍は注意しています。UEFIで起動する場合は「EFI runtime service support」「EFI stub support」「EFI GUID Partition support」と、EFIシステムパーティション用のVFAT(FAT32)も有効にします。
GRUBでの起動設定(BIOSとUEFI)
ブートローダーはGRUBです。13.1の10.4節は、BIOSとUEFIの両方の手順を載せています。2つの方法は共存でき、同じ grub.cfg を共有できます。
# BIOSで起動する場合(MBRのブートローダーを上書きする)
grub-install /dev/sda --target=i386-pc
# 64ビットUEFIで起動する場合(EFIシステムパーティションを /boot/efi にマウントしてから)
# 32ビットUEFIでは --target=i386-efi に変更
grub-install --target=x86_64-efi --removable
UEFIの --removable は、GRUBを EFI/BOOT/BOOTX64.EFI という標準の場所に置くオプションです。標準外の場所に置くとファームウェアの変数に場所を記録する必要があり、そのためのefibootmgrはLFSに含まれずBLFSのパッケージになります。ファームウェアが標準の場所を読まない古い機種では、efibootmgrで起動エントリを作ります。ホストのパッケージマネージャーで入れたefibootmgrをホスト側で使ってもよい、と書籍は書いています。このコマンドは既存の BOOTX64.EFI を上書きするので、ホストのディストリビューションと同じディスクで使っている場合は先に退避してください。
UEFIとSecure Bootの関係は「UEFIとは?BIOSとの違いからSecure Boot・GPT・サーバー運用まで実装者向けに解説」で解説しています。書籍の grub.cfg の例は次のとおりです(ルートが /dev/sda2 の場合)。
set default=0
set timeout=5
insmod part_gpt
insmod ext2
set root=(hd0,2)
set gfxpayload=1024x768x32
menuentry "GNU/Linux, Linux 7.1.8-lfs-13.1-systemd" {
linux /boot/vmlinuz-7.1.8-lfs-13.1-systemd root=/dev/sda2 ro
}
/boot を別パーティションにした場合は、linux 行のパスから /boot を外し、set root もそのパーティションに合わせます。GRUBから見たパスはパーティション内の相対パスになるためです。設定を誤るとマシンが起動しなくなるので、初回はホスト側のGRUBにLFSのエントリを足すだけにする方法もあり、書籍もそれでよいと明記しています。
ビルド時間の見積もり:SBUとmakeの並列数
LFSのビルドにかかる時間はマシンによって何十倍も違うため、書籍は分単位の時間ではなくSBU(Standard Build Unit)という単位で各パッケージの所要時間を示します。1 SBUは、第5章の最初に作るbinutils(1回目)を1コアでビルドしてインストールするまでの時間です。
# 5.2節:binutils 1回めの所要時間を1コアで測る(configure の引数は書籍どおりに入れる)
# .bashrc の MAKEFLAGS を -j1 で上書きして並列化を止める
time { ../configure ... && make -j1 && make -j1 install; }
たとえばbinutilsに4分かかったマシンなら、4.5 SBUのパッケージは約18分です。ただし基準のbinutils 1回目だけが1コアでの値で、他のパッケージのSBUは4コア(-j4)でのビルドを前提にしています。第8章の値には、特に断りがない限りテストスイートの実行時間も含まれます。書籍のSBUの節は、マザーボードがクロックを制御する新しいマシンでは、ホストで powerprofilesctl などを使って最大性能の電源プロファイルにしてから測るよう勧めています。省電力のまま測ると、SBUの値がずれます。
全体の目安としては、書籍の対象アーキテクチャの節に、LFS 9.1をCore i7-4790の4コアで構築した実測が載っており、64ビットで233.2分でした。旧版を特定のCPUで測った値なので、13.1の見積もりには使えません。自分のマシンでbinutils 1回目を測り、書籍の各パッケージのSBUを足し上げて待ち時間を出し、そこに書籍を読みながら打ち込む時間を別に見込んでください。
並列数は make の -j で指定し、第4章で .bashrc に export MAKEFLAGS=-j$(nproc) を追記して論理コア数ぶん並列にします。書籍が「Important」欄で警告しているのが、-j を数字なしで渡さないことです。数字がないとmakeはジョブを無制限に生成し、システムが不安定になります。
途中で中断・再開するときに必要な作業
LFSは1回の起動で通しで作る前提の手順書です。数日かけて少しずつ進めることはできますが、再起動したあとは章によって決まった作業をやり直す必要があります。書籍2.3節の内容をまとめると次のとおりです。
| 再開する章 | 再起動後に必要な作業 |
|---|---|
| 第1〜4章 | rootの環境でLFS変数を設定し直す |
| 第5〜6章 | /mnt/lfsをマウントし、su – lfs で入る |
| 第7〜10章 | マウント、仮想ファイルシステムのマウント、chrootに入り直す |
一番危ないのは第5〜6章です。su - lfs を忘れてrootのまま作業すると、パッケージがホストに入り、ホストが動かなくなるおそれがあると書籍は警告しています。パッケージが正しく入ったか自信がないときは、展開したソースディレクトリを消してアーカイブから展開し直し、その節を最初からやり直してください。
第7章の最後(7.15節)には、一時ツールが完成した時点で $LFS 全体をtar.xzに固めるバックアップ手順があります。書籍では、不要な文書などの削除後のシステムを約3GBとし、さらに不要になった /tools(約1GB)を削除します。圧縮に10分以上かかりますが、第8章で失敗したときに第5章からやり直さずに済むので、ここは飛ばさないことを勧めます。
パッケージマネージャーがない前提での更新と保守
完成したLFSにはaptやdnfのようなパッケージマネージャーがありません。書籍8.2節は、パッケージ管理を入れない理由を「本書の目的であるLinuxの構築方法の理解から焦点がずれる」「解決策が複数あり、全員に合う1つを選べない」と説明しています。RPMやDEBを入れる方法、パッケージごとに専用ユーザーで入れて所有者で管理する方法など、手法の紹介にとどめています。
手作業で更新するときに押さえておきたいのは、書籍が挙げる次の2つの差です。
- カーネルの更新は他を作り直す必要がない。カーネルとユーザー空間の境界がはっきりしているため、新しいカーネルを入れて再起動するだけでよい。
- glibcの更新は手順を誤るとシステムが壊れる。共有ライブラリの名前が変わるパッケージも、それにリンクしている全パッケージの再コンパイルが必要になる。
セキュリティ情報の追跡も自分で行います。公式は版ごとの勧告ページを廃止し、LFSのセキュリティ勧告の検索ページに移しました。版(13.1など)、パッケージ名、深刻度で絞り込めるので、自分が入れた版で検索して対処が要るものを拾います。
LFSが向く目的と向かない用途
LFSで身につくのは、ツールチェーン、glibc、カーネル、ブートローダーを自分の手で順に組み、どこで何が依存しているかを確かめる経験です。一方で、手早く使えるLinux環境がほしいだけなら選ぶべきではありません。判断の目安は次のとおりです。
- 向く:ツールチェーン、glibc、カーネル、ブートローダーの関係を手を動かして理解したい。組み込みや小さな専用機のために、何が最低限必要かを知りたい。ディストリビューションの開発や保守に関わる準備をしたい。
- 向かない:業務サーバーの本番環境。パッケージマネージャーがなく、入れたパッケージごとに脆弱性情報を追い、ソースから再ビルドして入れ替える体制を自分たちで持ち続ける必要がある。その体制を用意できないなら選ばない。
- 向かない:普段使いのデスクトップを早く用意したい。BLFSでGNOMEやKDE Plasmaまでたどり着けるが、選んだデスクトップ環境とその依存パッケージを1つずつソースからビルドし、更新のたびに同じ作業を繰り返すことになる。
自分の手でLinuxを組みたいという同じ動機でも、目的によって選ぶものが変わります。
| 選択肢 | パッケージ管理 | ソースからのビルド | 合う目的 |
|---|---|---|---|
| LFS | なし | すべて手作業 | 仕組みの理解 |
| Gentoo | Portage | 自動(バイナリも可) | 最適化した普段使い |
| Arch Linux | pacman | 原則バイナリ | 手で組む普段使い |
Gentooはソースからのビルドを前提にしたディストリビューションですが、2023年12月から配布バイナリパッケージも提供しています(amd64とarm64ではKDE PlasmaやLibreOfficeまで含む)。普段使いのLinuxを手で組みながら仕組みも学びたいなら、パッケージマネージャーがあり手順の大半を自分で打つArch Linuxが現実的な中間点です。インストールの流れは「Arch LinuxのISOをUSBに書き込む手順|dd・Rufus・Ventoyの使い分けとインストールまで」で解説しています。ペネトレーションテスト用のKali Linuxの公式ドキュメントも、Linuxの仕組みを根本から学びたい人にはLFSを勧めています。
組み込み機器向けに最小構成のLinuxを作る目的なら、LFSで得た知識はそのまま役に立ちます。製品向けに構成管理や継続的な再ビルドが必要なら、BuildrootやYocto Projectなどのビルドシステムを検討してください。組み込みOSの選び方は「組み込みOSとは?3分類の境界とITRON系の位置づけ・選定判断を実装者向けに解説」で整理しています。製品に載せるLinuxやIoT機器の構成から相談したい場合は、AI/IoTソリューションで設計から支援しています。
Linux From Scratchのよくある質問
LFSとは何の略ですか?
Linux From Scratch(リナックス・フロム・スクラッチ)の略です。「scratch」は「ゼロから」という意味で、ソースコードから自分のLinuxシステムを作る手順書と、その周辺のプロジェクト群を指します。Git LFS(Large File Storage)など、同じ略語の別技術とは関係ありません。
Linux From Scratchは日本語で読めますか?
読めます。lfsbookjaが最新のLFS 13.1と13.1-systemdの日本語訳を、HTMLとPDFで公開しています(2026-09-15公開)。開発版の訳も随時更新されています。
LFSの構築にはどれくらい時間がかかりますか?
マシン性能で大きく変わるため、書籍はSBUという相対単位を使います。公式の実測ではLFS 9.1をCore i7-4790の4コアで約233分でした。実際には、自分のマシンで測ったSBUから出した待ち時間に、書籍を読みながら打ち込む時間が加わります。何日かに分けて進める場合は、再開する章ごとにマウントやchrootをやり直す必要があります。
Linux From Scratchにパッケージマネージャーはありますか?
ありません。書籍は特定のパッケージマネージャーを推奨せず、8.2節で管理手法の種類(タイムスタンプ方式、インストールの追跡、パッケージごとのユーザーで管理する方式など)を紹介するにとどめています。必要ならHintsプロジェクトの文書を参考に、自分で導入します。
VirtualBoxなどの仮想マシンでLFSを構築できますか?
できます。ホストとなるディストリビューションを仮想マシンに入れ、LFS用の仮想ディスクを追加して作業すると安全です。カーネルでは仮想ディスクのドライバを組み込みにしてください。UEFI起動の仮想マシンでは13.1の書籍のUEFI手順に従い、LFSがSecure Bootに対応していないため仮想マシン側でSecure Bootを無効にします。