続・玩式草子 ―戯れせんとや生まれけん―

第59回Plamo Linuxのインストーラ

前回はPlamo-8.2の現状をパッケージ回りを中心に紹介しました。ご覧いただいたように、メンテナの方々のご尽力で各種ソフトウェアは随時更新され、ほぼ最新バージョンに追従できています。

一方、主に筆者が担当しているインストーラ回りも、パッケージ群ほどの華々しさはないものの、それなりに調整を進めています。今回は、このインストーラ回りの最近の取り組みを紹介しましょう。

インストーラと日本語表示

ご存知のように、Plamo Linuxは最古参のLinuxディストリビューションであるSlackware Linuxを日本語化することから始まったプロジェクトで、インストーラもSlackwareが開発したシェルスクリプトを改造して使っています。シェルスクリプトはテキストファイルなのでメッセージを翻訳する等の改造は容易なものの、画面への出力はカーネルのコンソールやターミナルエミュレータの機能に依存しており、日本語を表示するためにはそれらの環境を整える必要があります。

Xウィンドウシステムを使えば日本語をはじめさまざまな言語を簡単に表示できるものの、Slackware/Plamo Linuxのインストーラはカーネルのコンソール上で動作するのでXの恩恵にはあずかれません。そのため、どうやって日本語を画面に表示するかは当初からの問題で、最初期はkon(Kanji cONsole)というコンソールエミュレータを利用していたものの、konの開発が終了して新しいバージョンのカーネルで動作しなくなってからは、jfbtermやeuc-JPな文字コードを表示させるためのカーネルパッチ等々を試してきました。

カーネルのコンソール回りのコードがリファクタリングされて従来のパッチが使えなくなったり、システムの文字コードをUTF-8に切り替えた前後には、日本語が表示できなくても使えるようにとメッセージを英訳し直したこともあります。

その後、中華圏のGentoo Linux開発者から「コンソール回りのコードが新しくなったカーネルでUTF-8な文字列を表示できるようにするパッチcjktty-kernel⁠」が提案され、そのパッチと「日本語フォントデータをカーネルに埋め込むパッチcjktty-kernel-font⁠」を合わせ用いることで、再度カーネルレベルでの日本語表示が可能になり、Plamo-7.2くらいまではこの方式で使っていました。

図1 ビットマップフォントでの日本語表示
ビットマップフォントでの日本語表示

しかしながら、このパッチで表示できるフォントは16x16ドットのビットマップフォントに固定されるので、最近の大画面や老眼が進んだ筆者の目ではちょっと見づらく感じます(苦笑⁠⁠。

そのためしばらく前(Plamo-7.3くらい)から、kmsconというカーネルのビデオモード設定機能(KMS:Kernel Mode Set)を利用するコンソールエミュレータを採用しています。

図2 kmsconを使った日本語表示
kmsconを使った日本語表示

かつてのkonやjfbtermではカーネル・コンソール同様、サイズ固定のビットマップフォントしか扱えなかったのに対し、kmsconはpango/freetypeを経由してTrueTypeフォントを利用できるので、使いなれたフォント(MiguMix)を使えますし、ベクトル形式で記述されたTrueTypeフォントは任意のサイズに拡大/縮小が可能ですCtrl+/-でフォントサイズの増減可能⁠⁠。

図3 拡大した日本語フォント
拡大した日本語フォント

インストーラでは/etc/inittabでランレベル3をkmscon用に設定し、カーネルの初期化が終わればすぐにkmsconを立ちあげるようにしています。

$ cat -n etc/inittab
     1  # /etc/inittab derived from LFS 20170713
     2  # arranged for kmscon 20201106
     3  # Begin /etc/inittab
     4  
     5  id:3:initdefault:
     6  
     7  si::sysinit:/etc/rc.d/init.d/rc S
     8  
     9  l0:0:wait:/etc/rc.d/init.d/rc 0
    10  l1:S1:wait:/etc/rc.d/init.d/rc 1
    ...
    21  1:2:respawn:/sbin/agetty --noclear tty1 9600
    22  kms:3:once:/usr/bin/kmscon
    23  kmj:4:once:/usr/bin/kmscon --xkb-layout jp
    24  
    25  # End /etc/inittab

上記inittabの23行目、kmjというエントリーではkmsconを--xkb-layout jpというオプションで起動しています。従来、"JP106"といった日本語キーボードには、"loadkeys"コマンドでカーネルのキーマップ・データを変更して対応していたものの、kmsconはlibxkbcompを用いてキーボード入力を自前で処理するので、起動時に対応すべきキーボードの種類を指定する必要があります。そのため、ランレベルを切り替えてkmsconのオプションを指定するようにしてみました。

ランレベルの切り替えはブート時のカーネルパラメータで指定する必要があるので、grubのメニュー画面も更新し、テーマ機能を使って見栄えも少しよくしてみました(笑⁠⁠。

図4 更新したgrubメニュー
更新したgrubメニュー

メニュー画面に示したように、現在のインストーラは起動元としてDVDイメージかUSB2種(認識順でhd0かhd1)と日本語キーボードの有無を組み合わせて6通りの起動方法を用意しています。

遭遇したことはないものの、kmsconで日本語表示がうまく行かない場合、上記grub.cfgのメニュー画面でeキーを押して起動メニューの編集画面に移り、"linux .."行の最後に"S"(あるいは"1")を追加して起動F10キー)すれば、kmsconを起動しないシングルユーザーモードで起動します。

図5 bootメニューの手動修正
bootメニューの手動修正

インストーラとレスキューシステム

もうひとつ、最近試しているのが「インストーラ」「レスキューシステム」の切り分けです。というのも、以前のバージョンでは単独で起動できるインストーラをシステムトラブル時のレスキュー用にも使えるようにと、本来インストーラには必要ないネットワーク関連ツール類(sshd等)も組み込んでいたため、カーネルと共に読み込むinitramfsがずいぶん大きくなり、起動に時間がかかっていました。

さらに最近ではlinux-firmwareがずいぶん大きくなってきて、initramfsの肥大化が進みました。前回触れたように、firmwareは周辺機器を動かす際に必要な部品なものの、該当する機器を持っていない場合は無用の長物ですし、⁠isoイメージを使ってPlamo Linuxをインストールする」という用途に限れば、無線LANを含めたネットワーク回りやサウンドカード、各種USBガジェット用のfirmwareなどは不要でしょう。

そう考えて、⁠インストーラには不要」と思われるfirmwareやパッケージを削除することにしました。firmwareについて見ると、インストール時にかかわりそうなIntel/AMDのCPU用、NVIDIA/AMD RadeonといったGPU用、Adaptec/Advansys/QlogicといったSCSI HDD用、Mediatek/RealtekといったBluetooth用のみを残し、他は削除することにしました。

$ ls Installer/lib/firmware/
adaptec/    amdgpu/  intel/        qlogic/          rt2661.bin.zst   rt3071.bin.zst   rtl_bt/   rtw89/
advansys/   amdtee/  intel-ucode/  radeon/          rt2860.bin.zst   rt3090.bin.zst@  rtl_nic/
amd/        e100/    mediatek/     rt2561.bin.zst   rt2870.bin.zst   rt3290.bin.zst   rtlwifi/
amd-ucode/  i915/    nvidia/       rt2561s.bin.zst  rt3070.bin.zst@  rt73.bin.zst     rtw88/

こうして作ったインストーラ用のinitramfsは圧縮した状態で307MBくらいになり、起動速度もずいぶん速くなりました。

一方、iwlwifi等、切り捨てたfirmwareを必要とする周辺機器はインストーラでは利用できなくなります。そのためインストーラとは別に、linux-firmware一式と共にsshd等のネットワーク作業用ツールも組み込んだinitramfsを作り、そちらをレスキューシステムと呼ぶことにしました。

レスキューシステムにはemacsvimといったエディタ、wget/curl/rsync/opensshといったネットワーク用ツール、gawk/perl/pythonといったスクリプト言語も用意して、起動しなくなったシステムの復旧やデータ救出といった用途のみならず、日常的な作業もこなせるようにしてみました。その結果initramfsのサイズは719MB、インストーラの倍以上になっています。

Plamo Linuxのパッケージ群を収めたisoイメージからの起動を想定しているインストーラに対し、レスキューシステムはDVDメディアに拘る必要はありません。そこで、通常のUSBメモリ(FAT32フォーマット)からでも起動できるように、必要なファイルをEFI/boot/grub/の3ディレクトリに収め、これらディレクトリを置くことでUSBメモリから起動できるようにしてみました。

図6 レスキューシステムの起動画面
レスキューシステムの起動画面

最近のPCでは、旧来のBIOSに代ってUEFIがシステムの初期化や起動を担っています。PCの電源を入れるとまずマザーボード上のUEFIが起動され、CPU等の初期化と共にブート可能な周辺機器を探します。その際、HDDであればESP(EFI System Partition)上のEFI/BOOT/というディレクトリ、USBメモリであればそのルートパーティション上のEFI/BOOT/ディレクトリが調査対象で、そこにEFI用ファイル(通常はBOOTX64.EFI)があれば、それをブートローダであると認識します。

レスキューシステムでは、UEFIの処理に対応できるよう、GRUBから生成したブートローダをEFI/BOOT/BOOTX64.EFIに置き、このブートローダが読む設定ファイルをgrub/grub.cfgに、grub.cfgで指定するカーネルとinitramfs(rescue.zst)をboot/以下に置く、という構成にしています。

$ ls Rescue/USBboot/EFI/BOOT/
BOOTX64.EFI
$ ls Rescue/USBboot/grub/
fonts/  grub.cfg  grubenv  locale/  themes/  x86_64-efi/
$ ls Rescue/USBboot/boot/
rescue.zst  vmlinuz

isoイメージをベタ書きすると、8GBのUSBメモリに4GBのイメージを書き込んだ場合でも、パーティションテーブル等が破壊されてしまうため全体が書き込み不可となってしまいます。それに対し、レスキューシステムの場合、USBメモリのFAT32ファイルシステム上に必要なディレクトリとファイルを置くだけなので、残りの領域は自由に使うことができ、インストールしたいパッケージを置いたり、システム修復時のファイルの一時保存先として使用することも可能です。

また、firmwareを削減しているため、インストーラでは正常に動かない環境(たとえばBT経由のキーボードが使えない)でもレスキューシステムを使えば回避できるかも知れません。すなわち、レスキューシステムのUSBメモリから起動して、別途用意したisoイメージを書き込んだDVDからパッケージをインストールする、といった使い方も可能です(レスキューシステムにもインストール用スクリプトは設置しています⁠⁠。

レスキューシステムは現在も開発中で、起動報告もそう多くありません。また、USBメモリから起動できるかはマザーボード上のUEFIの実装に依存し、少し古めのPCでは対応していないことが多いようです。そのあたりを含め、興味ある人は試していただければ幸いです。


今回はPlamo Linuxのインストーラを取りあげてみました。インストーラはそのディストリビューションへの入口なので、初めて触れる人にもできるだけわかりやすくしようと心掛けてはいるものの、筆者のように長く関わってしまうと、メッセージ等には明示していないことでも、⁠ここは当然こうすべき」と無意識のうちに落とし穴を回避してしまいがちです。

インストーラでつまずいた人はそのディストリビューションに入ってきません。そのせいもあって、インストーラの不具合情報はなかなか集まらないので、初心者のみならず、ベテランユーザの方も、インストール時に気付いた問題点は積極的に報告いただくと助かります。

おすすめ記事

記事・ニュース一覧