第8回　Plamo Linux 4.72とP-Plamo

Plamoとしては珍しいほどのハイペースですが、3月3日付で4.7系の2度目のメンテナンスリリースになるPlamo-4.72をリリースしました。

当初、Plamo-4.72ではX Window SystemをR7.5に更新するつもりだったので、調整には多少時間がかかるかな、と思っていました。しかし、前回までに紹介したように、X11R7.5ではライブラリなどの互換性に関してやや難があることがわかり、メンテナンスリリースという位置付けには収まりにくそうなので、採用は新しい開発版にまで先送りすることにして、Plamo-4.72は問題の少なそうなパッケージをまとめた小規模な変更にとどめることにしました。その結果、4.71の公開から3ヵ月程度の間隔で、2度目のメンテナンスリリースが可能になりました。

「小規模な変更」と言っても、KDEが4.3.5に更新されたり、OpenOffice.orgが3.2に更新されたりしたためアップデート対象のパッケージは161個にのぼり、サイズ的には960Mバイト強に達しています。4.71からのアップデート用にパッケージを整理するのも一仕事で、今回も昨今のOSS開発の活発さや大規模化・複雑化を実感することになりました。

一方、メンテナンスリリースには互換性的に問題の少ないパッケージのみを選んでいるため、X11R7.5以外にも今回のリリースに漏れたパッケージが散在します。その1つがwebブラウザのfirefox-3.6で、当初は更新対象にする予定でしたが、動画処理用のプラグインが未対応だったり、add-onパッケージの追従が不十分だったりしたため、今回の更新ではcontribディレクトリに置いて必要な人が手動で更新するようにしました。

メンテナンスリリースでは互換性重視の観点から影響範囲の大きいパッケージは採用しづらいので、glib/gtkの変更を伴なうGNOME-2.28やサウンド回りの全面的な更新になるpulseaudioなどはPlamo-4.7系のリリースに入ることはないでしょう。

この種の、更新したいけどできないパッケージが溜ってくると、互換性についてあまり重視しない新しい開発版のツリーを作って次のバージョンに備えるのがPlamoの流儀です。そろそろPlamo-4.8のツリーを作り、開発の軸足を新バージョンに移すべき時期になってきたようです。

新バージョンについてはさておき、今回のリリースでは約1年ぶりにP-PlamoもPlamo-4.72の環境に追従して更新してみました。P-Plamoは以前の連載でも簡単に紹介したことがあるものの、あまり詳しくは触れなかったのでPlamo-4.72と合せて紹介してみましょう。

Plamo-4.72の新機能

上述のようにPlamo-4.72では、4.71から160ほどのパッケージを更新していますが、そのほとんどは各ソフトウェアのバージョンアップへの追従で、バイナリファイルを置き替える程度の変更です。しかしながら、カーネルやtarなど、いくつか新機能を追加したパッケージもありますので、それらについて簡単に紹介しましょう。

カーネル 2.6.32.9 とKMS

Plamo-4.72ではカーネルを2.6.32.9に更新し（4.71では2.6.31.6⁠）⁠、CONFIG_DRM_I915_KMSオプションを有効にしてみました。このオプションを指定すると、Intelの新しめのGPUを使っているマシンでは起動時からinteldrmfbというフレームバッファデバイスが有効になり、コンソール画面がより適切な解像度に設定されます。

KMS（Kernel Mode Setting）は、従来、Xサーバが担当していた画面解像度の制御機能をカーネルのDRM（Direct Rendering Manager）側に移して、コンソール画面とXの画面をよりシームレスに結びつける技術です。この技術にはカーネル側のドライバとX側のドライバの連携が必要で、残念ながら現時点ではIntelの新しめのビデオチップ以外では機能しないようです。

SquashFS-4.0のLZMA圧縮対応

カーネル本体に取り込まれたSquashFS-4.0にLZMA圧縮対応パッチを適用しました。

SquashFSはファイルシステムを効率よく圧縮する技術で、圧縮されたファイルシステムは書き込み不可になるものの、元のファイルシステムの半分から1/3程度に圧縮可能です。

Squashfs-4.0ではファイルシステムの圧縮にGZIP形式を採用していますが、より圧縮効率の高いLZMA形式を使えば、さらに1-2割の圧縮が可能になります。後述するP-Plamoのように、限られた領域にできるだけ多くのデータを詰め込みたい場合、この数割の圧縮率の違いが大きな差になります。

tar-1.22と新しい圧縮ツール

上述のSquashFSのLZMA圧縮の例にも見られるように、以前から使われているGZIP、BZIP2といった圧縮形式に加えて、最近では、さらに高圧縮率を目指したLZMA形式やそれをもとにしたXZ形式、圧縮率は高くないものの圧縮/展開がきわめて高速なLZO形式など、さまざまな圧縮形式が使われるようになりました。

GNU tarの新版ではこれら新しい圧縮形式もオプションで選択可能になったので、Plamo-4.72では各形式に必要なコマンドとともに、GNU tar を1.22に更新しました。tar-1.22では以下のような圧縮オプションが使用可能です。

$ tar --help
使用法: tar [オプション...] [ファイル]...
GNU `tar' は多くのファイルを一つのテープやディスクのアーカイブにまとめ, 更に
そこから個々のファイルを取り出すことができます.
...
 圧縮オプション:

  -a, --auto-compress
                             圧縮プログラムを決めるのにアーカイブ接尾辞を使用する
  -I, --use-compress-program=PROG
                             PROG 経由でフィルタ (-d を受け付ける必要あり)
  -j, --bzip2                bzip2 経由でアーカイブをフィルタ
      --lzma                 lzma 経由でアーカイブをフィルタ
      --no-auto-compress     do not use archive suffix to determine the
                             compression program
  -z, --gzip, --gunzip, --ungzip   gzip 経由でアーカイブをフィルタ
  -Z, --compress, --uncompress   compress 経由でアーカイブをフィルタ
  -J, --xz                   filter the archive through xz
      --lzop                 lzop 経由でアーカイブをフィルタ
...

少し余談になりますが、各圧縮形式で圧縮率と処理時間の違いを調べたデータを紹介しましょう。

下のグラフはlinux-2.6.32のソースコードを各形式を指定してtarで固めた際に、それぞれの形式ごとの圧縮後のサイズと圧縮に要する時間を図示したものです。一番左の "nocomp" が無圧縮の場合で、以下順に、LZO形式、GZIP形式、BZIP2形式、LZMA形式、XZ形式のそれぞれついて、圧縮後のサイズ（紺）と圧縮処理にかかった秒数（赤）を棒グラフにしてみました。図の縦軸はファイルサイズの場合はMバイト単位、処理時間の場合は秒単位になっています。

図2を見ると、非圧縮の場合は365Mバイトほどのサイズだった書庫ファイルが、LZOならば約120Mバイト（1／3⁠）⁠、GZIPならば80Mバイト（1／4.5⁠）⁠、BZIP2ならば60Mバイト（1／6⁠）⁠、LZMA/XZならば50Mバイト程度（1／7）にまで圧縮できているのに対し、処理にかかる時間はLZOがほぼ等速（1.1倍⁠）⁠、GZIPが5倍、BZIP2が27倍、LZMA/XZが88倍に達するという、スピードと圧縮率が見事にトレードオフの関係になっていることがわかります。

この結果を見ると、処理時間をかけたくない日ごとのバックアップはLZOでやや大きめのメディアに短期保存し、処理時間をかけていい週末や月末にはXZで小さく固めて長期保存していく、といったバックアップ作業の使い分けができそうです。

従来は、速度重視のGZIPか圧縮率重視のBZIP2かの選択肢しか無かった圧縮オプションが、より速度を重視したLZOから、より圧縮率を重視したLZMA/XZにまで広がることで、用途に応じた設定の調整幅がさらに広がったと言えるでしょう。

Plamo-4.72アップデータ

今回もメンテナンスリリースなので、前のバージョン（4.71）から更新されたパッケージのみを集めたアップデート集を用意しました。

上述のように、互換性を重視するメンテナンスリリースでは、「⁠そのまま」置き替えることができるパッケージのみを採用するのが基本方針ですが、必要に応じてシステムの設定変更を伴うようなパッケージが含まれこともあります。今回の更新では、ネットワーク用基本ツールとしてひとまとめになっていたtcpipパッケージから、telnet等のユーザ向けコマンド群がnetkit_comboパッケージとして分離されたので、そのための処理を別途用意することにしました。

この場合もバイナリファイルの置き替えだけならば、古いバージョンの tcpip パッケージを削除して、新しい tcpipとnetkit_comboパッケージをインストールすれば済むものの、この操作だけでは古いtcpipパッケージが作成した /etc/HOSTNAME 等の設定ファイルが".old" という拡張子のついたバックアップファイルになってしまいます。そのため、アップデート集を整理するついでにupdate.shという簡単なスクリプトで設定ファイルなどを元に戻すようにしてみました。

リスト1　00_base/update.sh

 1  #!/bin/sh
 2 
 3  # rc.inet1 が tradnet ならば保存しておかないと削除される
 4 
 5  inet_chk=`ls -l /etc/rc.d/rc.inet1 | grep tradnet`
 6  if [ "$inet_chk" != ".x" ]; then
 7    echo "ネットワーク設定を保存中"
 8    mkdir backup
 9    cp -a /etc/rc.d/rc.inet1.tradnet /etc/rc.d/rc.inet2 backup
10  fi
11  inet_link=`ls -l /etc/rc.d/rc.inet1 | gawk '{print $NF}' | sed 's/\*//' `
12  echo "inet_link:$inet_link"
13 
14  # tcpip パッケージは先に削除しておかないと、netkit_combo のパッケージと
15  # バッティングする
16 
17  removepkg tcpip
18 
19  for i in *.tgz ; do
20      updatepkg -f $i
21  done
22 
23  # tcpip-4.5-i386-P8 に更新すると、旧の設定ファイルは /etc/*.old
24  # に保存されるので、それらを元に戻す処理
25 
26  for i in exports hosts.equiv nntpserver rpc inetd.conf HOSTNAME bootptab \
      gateways services resolv.conf NETWORKING protocols host.conf hosts \
      snooptab networks ftpusers ; do
27      if [ -f /etc/$i.old ]; then
28          echo "/etc/$i を復旧中"
29          mv /etc/$i.old /etc/$i
30      fi
31  done
32 
33  # /etc/rc.d/rc.inet* を元に戻す
34 
35  if [ -d backup ]; then
36    echo "ネットワーク設定を復旧中"
37    mv ./backup/*  /etc/rc.d/
38    rmdir ./backup
39    echo "ln -sf $inet_link rc.inet1"
40    ( cd /etc/rc.d ; ln -sf $inet_link rc.inet1 )
41  fi

スクリプトで行っているアップデート処理の中心は19行目から21行目の部分で、このディレクトリにあるそれぞれのパッケージごとに、updatepkg -fコマンドでパッケージを更新しています。

5行目から10行目はremovepkgすると削除される設定を保存しておく処理、11行目はrc.inet1のリンク先を記録しておく操作で、これらの設定は26行目からの処理で復旧させています。

RPMやDEBといったバイナリパッケージ用に設計された格納形式では、インストールの前後やアンインストールの前後に指定したコマンドを実行する機能が用意されているので、このスクリプトが行なっているような処理はパッケージ自身に組み込むことができます。一方、Plamoの採用しているTGZ形式では、インストール後に実行する処理しか指定できないので、アンインストール時の処理などはこのスクリプトのようにパッケージの外部で指定してやる必要があります。

アンインストール前後の処理をあらかじめスクリプトとして用意しておき、removepkgの際にそれらのスクリプトを実行するような機能をTGZ形式に追加することを考えたこともありますが、専用のコマンドが無くてもパッケージを操作できるTGZ形式の魅力が薄れるし、どのような処理が行なわれるのかが見えにくくなるのもあまり好ましくない気がしたので、最近では設定ファイル等の保存が必要なアップデート作業にはこの種のラッパースクリプトを使うようにしています。

P-Plamo returned

P-Plamoは、HDDにインストールしなくてもDVDメディアから起動してPlamo環境を利用できる、Plamo版のLiveDVDです。DVD一枚でどこでもPlamo環境を起動できて結構便利なツールだったのですが、昨年3月にPlamo-4.6ベースのP-Plamoを公開以後、長く更新が止っていたのを、Plamo-4.72のリリースに合わせて久しぶりに復活させました。

なぜ1年ほどもブランクが空いてしまったのかと言うと、2.6.29以降のカーネルに採用されたSquashFS-4.0ではLZMA圧縮機能が使えなかったためです。

Plamo-4.6ベースのP-Plamoでは、www.squashfs-lzma.orgで公開されていたSquashFS-3.6用のLZMAパッチを使っていましたが、このパッチはカーネル2.6.27用で、2.6.29以降のカーネルに採用されたSquashFS-4.0では適用できませんでした。

LZMA圧縮ではなく、SquashFSに元々組み込まれているGZIP圧縮ならば使えましたが、どうせなら少しでも圧縮率が高い方がいいなぁ…、と思っているうちに月日が流れてしまいました。

昨年の10月下旬になって、SquashFSの作者Phillip Lougherさん自身によるSquashFS-4.0をLZMA対応にするパッチが公開されたので、さっそくこのパッチを使ってP-Plamoを久しぶりに復活させた次第です。

P-Plamo内部の仕組み等はまた別の機会に解説することにして、今回はSquashFSがどれくらいファイルシステムを圧縮できるかを、実例を使って紹介してみましょう。

P-Plamoでは、Plamo-4.72をXfce＋KDE＋TeX＋OpenOffice.orgでインストールした環境を元にしており、元の環境では約5.3Gバイトほどのディスク領域を使用しています。

# du -h 
64K     ./etc/X11/nicolatter
88K     ./etc/X11
8.0K    ./etc/logrotate.d
28K     ./etc/rc.d/inet.d
4.0K    ./etc/rc.d/rc5.d
...

4.0K    ./tmp
8.0K    ./root
5.3G    .

この環境をmksqaushfsコマンドでLZMA圧縮のSquashFSに変換すると約1.6Gバイトのファイルになります。

# mksquashfs -b 1024KB -comp lzma * ../rootimg.squash
Parallel mksquashfs: Using 2 processors
Creating 4.0 filesystem on ../rootimg.squash3, block size 1048576.
...

# ls -lh rootimg.squash
rwx------ 1 root root 1.6G  3月  8日  13:42 rootimg.squash*

このSquashFSイメージをloopback形式でマウントすると、1.6Gバイトのファイルシステムに見えます。

# mount -t squashfs rootimg.squash /loop -o loop
# df -h
Filesystem          サイズ  使用  残り 使用% マウント位置
... 
/dev/loop0            1.6G  1.6G     0 100% /loop

ところが、この1.6Gバイトのファイルシステムの中には4.8Gバイトの内容が詰まっています。

# du -h /loop
4.0M    /loop/bin
0       /loop/cdrom
0       /loop/dev
0       /loop/etc/ConsoleKit/run-session.d
512     /loop/etc/ConsoleKit/seats.d
...
0       /loop/var/tmp
18M     /loop/var
4.8G    /loop

この例のように、SquashFS+LZMAを使えばファイルシステムを1／3以下のサイズにまで圧縮できるので、DVDやUSBメモリといった限られた記憶メディア上に多くのデータを詰め込みたい場合には最適のツールになります。

この例では元のファイルシステムでは5.3GバイトだったのがSquashFSから取り出すと4.8Gバイトになっていますが、この差はファイルシステムごとのi-nodeやブロックサイズの扱いの違いによる現象で、cp -aやtar等でext3 FS上に取り出すと元の5.3Gバイトくらいになるはずです。

ちなみに、同じファイルシステムをLZMA形式ではなくGZIP形式で圧縮した場合は約2Gバイトになり、率にして25％、サイズにして400Mバイトほど大きくなりました。4.7Gバイトの容量を持つDVDメディアならばこの程度の差は問題にならないでしょうが、2GバイトのUSBメモリにインストールしようとするとこの差は致命的です。SquashFSのLZMA対応が出るまでP-Plamoの更新を見送ってきた意味はそれなりにあったようです。