昨秋、オープンソースカンファレンス（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に対応している上で、

1. GPT形式で管理されるHDD
2. FAT32形式でフォーマットされたEFIシステムパーティション（ESP）
3. UEFIに対応したブートローダ

という条件が必要です。

Plamo-6.0ではGPT形式に対応したfdisk/cfdiskを用意することで1．に、UEFI版のgrubを用意することで3．に対応したものの、ESPをフォーマットする作業はユーザにゆだねていました。

一方、Plamo-6.1ではインストーラにSeTespjという新しいスクリプトを用意して、未フォーマットなESPが存在すれば自動的にフォーマットする処理を追加しました。

 87     is_gpt=`LANG=C ; /sbin/blkid $ROOT_DRIVE | grep -i gpt`
 88     echo "is_gpt:$is_gpt"
 89     if [ "$is_gpt.x" = ".x" ]; then   # NOT GPT HDD
 90         exit
 91     else
 92         root_drive_has_esp=`LANG=C ; fdisk -l $ROOT_DRIVE | grep  EFI`
 93         echo "root_drive_has_esp: $root_drive_has_esp"
 94     
 95         if [ "$root_drive_has_esp.x" = ".x" ]; then
 96             has_esp=`LANG=C ; fdisk -l | grep -i EFI`
 97             if [ "$has_esp.x" = ".x" ]; then
 98                 dialog --title "No ESP found" --menu \
...
119         else  # found ESP on this HDD
120             mkdir /mnt_chk
121             ESP=`echo $root_drive_has_esp | cut -f1 -d' '`
122             #echo "ESP:$ESP"
123             #sleep 10
124             mount -t vfat $ESP /mnt_chk
125             if [ $? -eq 0 ]; then    # OK We have formatted ESP.
126                 echo $ESP > /tmp/ESP_partition
127                 umount /mnt_chk
128                 rmdir /mnt_chk
129             else
130                 dialog --title "Format ESP?" --yesno \
131                        "EFIシステムパーティション($ESP)をマウントできませんでした．このパーティションを \
132     フォーマットしますか？EFIシステムパーティションはFAT32形式でフォーマットされます．" 11 72
133                 if [ $? -eq 0 ]; then
134                     format_esp $ESP
135                 else
...

このスクリプトでは、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）等のオプションもネットワーク経由の場合と同様に利用できます。

$ get_pkginfo -u file:///cdrom/
local package: btrfs_progs-3.19_rc2-x86_64-P1
new   package: btrfs_progs-4.3.1-x86_64-P1
URL: file:///cdrom/plamo/00_base/btrfs_progs-4.3.1-x86_64-P1.txz

local package: dhcp-4.2.7-x86_64-P1
new   package: dhcp-4.3.3_P1-x86_64-P1
URL: file:///cdrom/plamo/00_base/dhcp-4.3.3_P1-x86_64-P1.txz
...

なお、この機能はPlamo-6.1のget_pkginfo（get_pkginfo-git_20160217-noarch-P2.txz）で追加したため、Plamo-6.0環境で利用する場合、get_pkginfoは事前に更新しておく必要があります。

$ sudo updatepkg -f /cdrom/plamo/01_minimum/get_pkginfo-git_20160217-noarch-P2.txz

adduser時の文字コード指定機能

最近のデスクトップ環境やアプリケーションを使う場合、日本語の文字コード（locale）をUTF-8にしておく方が都合いいことが多いので、adduserを使って新規ユーザを登録する際にlocaleとしてja_JP.UTF-8を選択できるようにしました。

# adduser 
Can you read Japanese chars on this term? [Y/n]
y
Japanese mode

新しいユーザのログイン名を指定してください(8 文字以内)。 []: alice
alice のユーザ ID は？ [自動登録の場合は 1000 番台になります]: 
alice が属するグループは？ [users]: 
alice は他のグループにも属しますか？
  (デフォルト設定に追加する場合 --> add:,,...
   他のどのグループにも属さない場合 --> none)
  [audio,dialout,video,cdrom,kvm,pulse,pulse-access,mlocate,libvirt]: 
alice のホームディレクトリは？ [/home/alice]: 
alice が使うシェルは？ [/bin/bash]: 
日本語 locale の設定
1 : ja_JP.eucJP(従来通り)
2 : ja_JP.UTF-8(今風)
alice はどちらの locale を使いますか [1]: 2
 
ウィンドウマネージャ設定
1 : Twm(ごくシンプル)
2 : Xfce Desktop(お勧め)
3 : KDE Desktop(便利だけどやや重い)
4 : MATE Desktop(GNOME2 の進化版)
alice が使う WM は？ [2]:
...

ここで選択した日本語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してやれば環境変数がまとめて切り替わります。

$ env | grep -i -e "lang" -e "charset"
JLESSCHARSET=japanese-euc
LANG=ja_JP.eucJP
OUTPUT_CHARSET=EUC-JP

$ source ~/.set_lang_bsh UTF-8
$ env | grep -i -e "lang" -e "charset"
JLESSCHARSET=japanese-utf8
LANG=ja_JP.UTF-8
OUTPUT_CHARSET=UTF-8

~/.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経由でファイルをやりとりするようにしています。

$ sudo mount -t cifs //myfileserver/raid ./raid-utf8 -o username=kojima,iocharset=utf8,passwd=xxxxx

こうしておけば./raid-utf8/以下ではEUC-JPな日本語ファイル名はUTF-8に自動変換されるので、問題なく操作することができます。

もうひとつ、Plamo-6.1で特筆すべき話題には、メンテナの田向さんがPlamo-6.1をARMベースのCPUに移植して、Rasberry Pi2上で動作可能にしたことが挙げられます。ARM用にビルドされたパッケージは動作可能な最小規模なものの、OSC2016 Tokyo/Springに来訪された方はご覧になられたように、Rasberry Pi2のコンソール上で日本語表示も実現できているそうです。このあたりの話題は、改めて担当者自身から語ってもらう予定なのでお楽しみに。