昨秋、オープンソースカンファレンス(OSC)2015 Tokyo/Fallに合わせてPlamo-6.0をリリースしたのに続き、2月下旬に開催されたOSC2016 Tokyo/Springに合わせてPlamo Linux 6.1をリリースしました。
3ヶ月ちょっと、というPlamoのリリースサイクルとしてはずいぶん早いペースでのリリースだったものの(苦笑)、6.0には間に合わなかったパッケージをはじめ、セキュリティ・フィックス等で更新したパッケージは200を超え、本連載で紹介してきたようなUEFI回りの処理なども追加して、6.0ではかなり荒削りだった部分をPlamo-6.1ではずいぶん洗練させることができました。
今回は、UEFI回りの処理をインストーラにどのように組み込んだかをはじめ、Plamo-6.1で追加した新機能について紹介してみます。
インストーラのUEFI対応
前回までに紹介してきたように、UEFIから起動するためにはマザーボードがUEFIに対応している上で、
- GPT形式で管理されるHDD
- FAT32形式でフォーマットされたEFIシステムパーティション(ESP)
- UEFIに対応したブートローダ
という条件が必要です。
Plamo-6.0ではGPT形式に対応したfdisk/cfdiskを用意することで1.に、UEFI版のgrubを用意することで3.に対応したものの、ESPをフォーマットする作業はユーザにゆだねていました。
一方、Plamo-6.1ではインストーラにSeTespjという新しいスクリプトを用意して、未フォーマットなESPが存在すれば自動的にフォーマットする処理を追加しました。
このスクリプトでは、87行目でblkidコマンドを利用してインストール先のHDDがGPT形式になっているかを調べ、GPT形式ならば92行目でfdiskを使ってパーティションのリスト(-lオプション)を調べて、ESPの有無をチェックします。
ESPが無ければその旨を表示し、ESPがあればVFAT形式でマウントできるかを確認して(124行目)、マウントできればESPの準備完了、マウントできなければ確認のうえフォーマットする(134行目)、という処理を行います。
当初、上記2.の条件を満たすため、「ESPが見つからなかった場合、HDDに空きがあれば自動的にESPを作成する」という処理も用意したものの、実際に試してみたところ、スクリプトでパーティションを切り直しても変更されたパーティションテーブルの情報がカーネルに伝わらず、想定外のパーティションをフォーマットしてしまうエラーが頻発したため、ESPはインストール先のHDDを設定する際に手動で作ってもらうことにしました。上記リストが87行目から始まっているのはそのためで、前半は無効にしたESP作成用スクリプトの残骸です。
UEFIから起動するための3条件全てをインストーラ的に対応することはできなかったものの、パーティションテーブルを切るあたりは人力に任せておく方がPlamoらしいかな、という気もしています。
get_pkginfoのfile://プロトコル対応
get_pkginfoはPlamo Linux用のパッケージ更新ツールで、この連載でも紹介したように、FTPサイト上に公開されているパッケージと手元にインストール済みのパッケージの違いをチェックするような設計になっています。この場合、常に最新版のパッケージをチェックできる利点はあるものの、FTPサイト上のPlamo-6.x/以下のディレクトリはPlamo-6.1のリリース後も日々パッケージが更新されているため、公式リリースの時点で更新されていたパッケージを調べる、という使い方はできません。
一方、get_pkginfoで指定できるURLは次第に拡張され、手元にあるPlamo Linuxのツリーと比較するためにURLの指定でfile://を使うことも可能になっていました。
この機能を使えば手元にマウントしたDVDイメージをget_pkginfoのチェック先に利用できるのでは、という指摘があって、「なるほどそれは面白そうだ」と、pickle化したファイルリストの持ち方を少し変更し、DVDイメージにファイルリストを収めて、DVDと手元のパッケージの違いをチェックできるようにしてみました。
この機能を使うには、Plamo-6.1のDVDイメージを/cdromにマウントしている場合、-uオプションにfile:///cdrom/と指定します。プロトコル名がfile://で、探しにゆく場所が/cdrom/なので、/(スラッシュ)が3つ並ぶことにご注意ください。ダウンロード(-d)やインストール(-i)等のオプションもネットワーク経由の場合と同様に利用できます。
なお、この機能はPlamo-6.1のget_pkginfo(get_pkginfo-git_20160217-noarch-P2.txz)で追加したため、Plamo-6.0環境で利用する場合、get_pkginfoは事前に更新しておく必要があります。
adduser時の文字コード指定機能
最近のデスクトップ環境やアプリケーションを使う場合、日本語の文字コード(locale)をUTF-8にしておく方が都合いいことが多いので、adduserを使って新規ユーザを登録する際にlocaleとしてja_JP.UTF-8を選択できるようにしました。
ここで選択した日本語localeは~/.xinitrcに設定され、Xを起動する際に利用されます。一方、コンソールではuniconを使って日本語を表示しているためEUC-JPでないと都合悪いので、ログインした時点の日本語localeは従来通りのja_JP.eucJPにしています。
Plamo Linuxではlocaleの切り替えにCライブラリの文字コードを指定するLANGとOUTPUT_CHARSET、lessの出力用文字コードを指定するJLESSCHARSETの3つの環境変数を使っており、これらをまとめて変更するための~/.set_lang_bshと~/.set_lang_cshというスクリプトも用意しました。前者はsh/bash/zsh用、後者はtcsh用のスクリプトです。引数にUTF-8かEUCを指定してこのスクリプトをsourceしてやれば環境変数がまとめて切り替わります。
~/.set_lang_[bc]sh はシェルスクリプトなものの、独立したシェルスクリプトとして実行するとサブシェル内で実行されてしまうため、元のシェルの環境変数を操作することはできません。そのためsourceコマンドで実行していることにご注意ください。
なお、たいていのソフトウェアはこれらの環境変数で利用する文字コードが切り替わるものの、FDcloneのように独自の設定ファイルを利用しているソフトウェアでは別途それらの設定ファイルも修正する必要があります。また、AfterStepやqvwmのようなUTF-8に対応していない古いウィンドウマネジャはUTF-8環境では利用できません。
EmacsやLibreOfficeを始め、最近の多くのソフトウェアは内部処理用にUTF-8を利用しているので、テキストファイルの中身の文字コードがEUC-JPからUTF-8に替わってもほとんど影響はありません。しかしながらファイルシステム上の文字コードはlocaleに依存するため、文字コードを変更すると以前に作っていた日本語ファイル名が正しく操作できなくなります。
手元ではこのような問題に対応するため、文字コード変換機能を持つSambaを利用しています。すなわち、ファイルサーバ上でSambaを動かし、ファイル名の文字コードを変換する必要がある場合は、NFSではなくSamba経由でファイルをやりとりするようにしています。
こうしておけば./raid-utf8/以下ではEUC-JPな日本語ファイル名はUTF-8に自動変換されるので、問題なく操作することができます。
もうひとつ、Plamo-6.1で特筆すべき話題には、メンテナの田向さんがPlamo-6.1をARMベースのCPUに移植して、Rasberry Pi2上で動作可能にしたことが挙げられます。ARM用にビルドされたパッケージは動作可能な最小規模なものの、OSC2016 Tokyo/Springに来訪された方はご覧になられたように、Rasberry Pi2のコンソール上で日本語表示も実現できているそうです。このあたりの話題は、改めて担当者自身から語ってもらう予定なのでお楽しみに。