Recently in Linux Category

Tiny Core Linuxもバージョン3.6がリリースされ、私も使ってみました。 それほどは変わっていませんが、細かいところが多数改良されているようです。

さて、VirtualBoxで使っている方も多いと思いますが、ホストOSとの共有フォルダを使う方法です。 Tiny Coreでは、tczパッケージでVirtualBox Guest Additionsが提供されているので、基本的にはそれをインストールするだけで使えます。

% tce-load -wi virtualbox-ose-adiitions

ただ、これをインストールすると依存関係でXorgを含めた多数のパッケージがインストールされてしまいます。 Xorgが不要な場合や、私のように カスタマイズしている場合はあまりうまくありません。 そのため、最小のモジュールで使えるようにしてみました。


まず、Guest Additionsのモジュールのみをインストールします。

% tce-load -wi virtualbox-ose-adiitions-modules-2.6.33.3-tinycore

virtualbox-ose-adiitions-modules-2.6.33.3-tinycore.tczであり、virtualbox-ose-modules-2.6.33.3-tinycore.tczではないので注意してください。 このtczは、3つのカーネルモジュールをインストールするだけです。

次に、virtualbox-ose-adiitions.tczから、mount.vboxsfを抽出し、/usr/local/sbinにコピーします。

% cd /tmp
% tce-fetch.sh virtualbox-ose-adiitions.tcz
% tce-load -i squashfs-tools-4.x (まだダウンロードしていなければオプションは-wil)
% unsquashfs virtualbox-ose-adiitions.tcz
% sudo cp squashfs-root/usr/local/sbin/mount.vboxsf /usr/local/sbin
% rm -rf squashfs-root

このファイルがリブート時に再現されるよう、/opt/.filetool.lstに追加し、バックアップします。

% echo usr/local/sbin/mount.vboxsf >> /opt/.filetool.lst
% filetool.sh -b

これで、以下のようにして共有フォルダをマウントできるようになります。

% sudo mount.vboxsf 共有フォルダ名 マウントポイント

これで、非常に軽量に共有フォルダを有効にすることができました。

なお、この情報は、フォーラムにあったものをもとにしています。


(Initially posted on 20 April 2011)

これまでの流れ

前回の方法に味をしめて(?)、microcoreでも同じ方法が使えるのではないかと思いました。

もともと、microcoreとtinycoreの差分はtczで提供されているので、microcoreで起動したら、次のようにすればmicrocoreをtinycore相当にすることができます。

% tce-load -i Xprogs
% tce-load -i Xlibs
% tce-load -i Xvesa
% tce-load -i flwm_topside

もちろん、Dynabook SS 3410ではXvesaの代わりにXorg-7.5でなければいけません。 しかし、この部分は既に前回最小のファイルセットを見つけました。

あとは、XprogsとXlibsに対して同じような作業をすればいいわけです。


で、また地道な作業で最小限のファイルセットを作成しました。 例により、自動的に新しいmicrocore.gzを作成するためのスクリプトと一緒に公開しておきます。

microcore-xorg.tar.gz   microcore-xorg-flwm.tar.gz

準備として、/mnt/hda1/boot/microcore.gzを用意してください。 また、以下のパッケージを/mnt/hda1/tce/optionalに(tce-load -wで)入れておいてください。

Xlibs.tcz
Xorg-7.5-lib.tcz
Xorg-7.5.tcz
Xprogs.tcz
feh-1.3.4.tcz
firmware.tcz
flwm.tcz
giblib.tcz
openssl-0.9.8.tcz
pixman.tcz

作成方法は、アーカイブを展開したあと、

% sudo sh mkmicrocore.sh

となります。 これで、/tmp/microcore.gzが作成されます。 なお、Virtual Boxで試す場合は、Xorg-7.5.tcz.vbox.minlistをXorg-7.5.tcz.minlistにリネームしてmkmicrocore.shを実行してください。


今回は2バージョンあり、microcore-xorg-flwmはatermおよびflwmが入っています。 そのため、このパッケージではX Window上でターミナルを開いて作業することが可能です。 なお、flwmは私の好みで、tinycore標準のもの(flwm_topside)ではなくてタイトルバーが横につくもの(flwm)を入れてあります。 標準のものにするには、flwm_topside.tczをtce-load -wでダウンロードし、flwm_topside.tcz.minlistを以下の内容で作成します。

usr/bin/flwm_topside

また、mkmicrocore.shを以下のように修正します。

(修正前) sh copyfromlist.sh flwm
(修正後) sh copyfromlist.sh flwm_topside
(修正前) echo flwm >> /tmp/microcore/etc/sysconfig/desktop
(修正後) echo flwm_topside >> /tmp/microcore/etc/sysconfig/desktop


microcore-xorgはこれらは入っておらず、Xが起動したら.xsessionの中身を実行することしかできません。

.xsessionには、以前書いたように、次の行を追加しておきます。

xset s off
xset -dpms (dynabookではこの行がないと一定時間後にスクリーンが消える)
feh -F -D 10 -r --hide-pointer /mnt/hda2/Photos/

microcore-xorgの場合、終了する場合はCtrl+Alt+BackspaceでX自体を終了させます。 デジタルフォトフレームを作るという本来の目的ではこれでも十分です。 コンソールでの作業はできますし、tce-loadで一時的に追加パッケージを入れてメンテナンスもできますから。


さて、ベンチマークです。 これまでの結果も合わせて表にしました。

パッケージ grubから画像表示まで 電源入から画像表示まで メモリ使用量 tinycore.gzのサイズ tczのサイズ 備考
Xorg + GQView 28s 40s 98MB 8.01MB 16.20MB  
Xorg + Feh 26s 38s 56MB 8.01MB 14.61MB  
Xorg最小化 23s 33s 45MB 11.03MB 0.00MB grubの待ち時間を3sから1sに変更
microcoreベース+最小Xorg (flwmあり) 21s 31s 35MB 8.79MB 0.00MB  
microcoreベース+最小Xorg (flwmなし) 18s 28s 34MB 8.45MB 0.00MB  


というわけで、最終的に起動時間が30秒を切りました。 tinycore.gz (実際にはmicrocore.gz)のサイズも、Xorgとfehを入れてオリジナルのtinycore.gzとそれほど変わらなくなりました。

BIOSスクリーンの時間はいかんともしがたいですが、実際grubからの起動時間を見ていると約18秒と、このスペック(Celeron 400MHz)にしては驚異的な速度で起動するのがわかります。 参考までに、環境作成に使用していたVirtualBox(ホストはCore i7-640M 2.8GHz、Windows 7 64bit、割り当てCPUは1個、メモリ192MB)での起動時間は5秒程度です。


ここで紹介している方法は、オリジナルのtinycore.gzやmicrocore.gzからファイルを削除するわけではないので、今後バージョンがあがっても修正が不要か、わずかな修正で動作することが期待できます。

PCとしてではなく、デジタルフォトフレームのようなアプライアンスを作るベースとしてTiny Core Linuxをカスタマイズしてきましたが、いかがでしょうか?


Tiny Core Linux (8) - Xorgの最小化

| No Comments | No TrackBacks

(Initially posted on 19 April 2011)

これまでの流れ

軽い画像ビューアであるFehをインストールして起動も結構早くなったのですが、Dynabook SS 3410は標準のXVesaが使えず、Xorgを入れる必要があるので、その分パッケージが大きくなるのが難点です。

注意深く見れば、Xorgのパッケージ(圧縮状態で14.28MB)のうち、不要なものを除く、というよりも必要なものだけを入れ、tinycore.gzに入れてしまえば軽くなるのではないでしょうか。

試しに、Xorg-7.5とそれに必要なパッケージ群を、以前説明したようにすべてtinycore.gzにパックしてみました。 結果はgrubのメニューから最初の画像が表示されるまで約30秒。 ...かえって遅くなってしまいました。 free -mのusedの値も77MBになってしまいます。

やはり、細かく見なければいけないようです。


Xorgはけっこう難敵なので、手始めにFehを調べてみると、fehの実行に必要なファイルは以下のみであることがわかりました。

/usr/local/bin/feh
/usr/local/share/feh/fonts/yudit.ttf
/usr/local/lib/libgiblib.so.1 -> libgiblib.so.1.0.6
/usr/local/lib/libgiblib.so.1.0.6

Fehに必要なパッケージは圧縮状態で336kBですが、上記の3ファイルの合計は非圧縮でも242kBです(参考まで、上記ファイルをgzip圧縮したものは114kB)。 そのため、これらを取り出してtinycore.gzに取り込んでしまえば、サイズがさらに小さくなってパッケージの読み込みも不要になります。


さてXorgについてです。 やり方は、まずXorg-7.5を入れずに(/mnt/hda1/tce/onboot.lstからエントリを削除)起動します。 そして、Xorgのパッケージ群をunsquashfsで別途展開しておきます。

% tce-load -i squashfs-tools-4.x (まだダウンロードしていなければオプションは-wi)
% cd /tmp
% unsquashfs -d expat2 /mnt/hda1/tce/optional/expat2.tcz
% unsquashfs -d fontconfig /mnt/hda1/tce/optional/fontconfig.tcz
% unsquashfs -d openssl /mnt/hda1/tce/optional/openssl-0.9.8.tcz
% unsquashfs -d pixman /mnt/hda1/tce/optional/pixman.tcz
% unsquashfs -d Xorg-bin /mnt/hda1/tce/optional/Xorg-7.5-bin.tcz
% unsquashfs -d Xorg-lib /mnt/hda1/tce/optional/Xorg-7.5-lib.tcz
% unsquashfs -d Xorg /mnt/hda1/tce/optional/Xorg-7.5.tcz
% unsquashfs -d Xorg-fonts /mnt/hda1/tce/optional/Xorg-fonts.tcz

次に、メインファイルであるXorgを移動します。

% sudo cp -p Xorg/usr/local/bin/Xorg /usr/local/bin

これでXorgを起動すれば、さまざまなエラーが出ると思います。 最初はライブラリが足りないですし、次にエラーログが/var/log/Xorg.0.logに出てきます。 これらを確認しつつ、ひとつづつ/tmpからファイルをコピーしていきます。 実際には、ファイルのリストを作りながら、tarでコピーしていきました。 地道な作業です。

その後、Xを起動しては/var/log/Xorg.0.logを確認し、エラーが出ているライブラリを追加する作業を繰り返します。

そのうちエラーが出なくなって画面が出るようになるのですが、ここで問題です。 その状態ではキーボードの入力を受け付けない(マウスは受け付ける)ことです。 これは、どのファイル不足しているのが原因か、ログファイルからはわかりませんので、何とかいろいろ試すしかありません。 少々苦労しましたが、それらのファイルを特定しました。

なお、私が扱っているDynabook SS 3410の場合、Tridentのチップなので、ドライバは、

/usr/local/X11/modules/drivers/trident_drv.so

となりましたが、他のチップの場合は同じディレクトリにある他のファイルを取り込めば動くかもしれません。 たとえば、VirtualBoxの場合、

/usr/local/lib/X11/modules/drivers/vesa_drv.so
/usr/local/lib/X11/modules/libshadow.so

を追加することで動作しました。


そんな感じでだいぶ苦労しましたが、「最小セット」のリストができました。 ついでに、自動でtinycore.gzを作成するスクリプトも作りました。

スクリプトのダウンロードはtinycore-xorg.tar.gzからどうぞ。

使い方は、まず必要なパッケージとして、squashfs-tools-4.xとadvcompを利用可能にしておきます。 また、Xorg-7.5.tczほか、必要なtczファイルを/mnt/hda1/tce/optionalにダウンロードしておきます。 その後以下のように実行するだけで、新しい/tmp/tinycore.gzが出来上がります。

% sudo sh mktinycore.sh

やっていることは以下のとおりです。

  1. 元となるtinycore.gzを/tmp/tinycoreに展開
  2. 必要なパッケージを展開
  3. リストの内容に従い、パッケージ内のファイルを/tmp/tinycoreにコピー
  4. 上記2.と3.をパッケージの数だけ繰り返す
  5. /tmp/tinycoreを再パックして、/tmp/tinycore.gzを作成する

なお、これはtridentのドライバしか組み込みません。 VirtualBoxで動かしてみたい場合は、ファイルの中にそれ用の設定ファイルも用意したので、次のように置換してからmktinycore.shを動かしてください。

% mv Xorg-7.5.tcz.vbox.minlist Xorg-7.5.tcz


tinycore.gzの展開と作成の詳細については、tinycore.gzの作り方も参照してください。

なお、この方法だと、以前組み込んだときとはd101m_ucode.binの位置が違う(以前: /lib/firmware/e100、今回: /usr/local/lib/firmware/e100)のですが、問題ありません。

これでできたtinycore.gzのサイズは、約11.03MB。 オリジナルのtinycore.gzが約8.01MBなので、おおよそ3MB増量ということになります。 tce-loadでXorg-7.5とFehをインストールすると、合計では、

8.01 (tinycore.gz) + 14.28 (Xorg-7.5) + 0.33 (Feh) = 22.62MB

ということで、およそ半分弱にまで容量が減ったことになります。


さて、期待(?)の起動時間です。 grubからは約23秒、電源を入れてからのトータル約35秒でした。 前回からさらに3秒ほど高速化しました。 grubの待ち時間を1秒にして、トータル約33秒になりました。 メモリ消費量は、free -mのused部分で45MBです。 前回(56MB)に比べて、11MBほど減らすことができました。


もっとやろうと思うと...もうtinycoreはあきらめて、microcoreベースで構築するしかないですね。


(Initially posted on 17 April 2011)

これまでの流れ

Dynabook SS 3410 (Celeron 400MHz/192MB) + CF SSD (8GB)+ Tiny Core Linuxによるデジタルフォトフレームは一応の完成を見たのですが、さらにサイズを小さく、高速に起動することを考えてみました。

前回の一応の完成では、スライドショーを行うイメージビューアにGQView1を使ったのですが、それよりもサイズが小さいFehというものを見つけました。 コマンドラインからフルスクリーンとスライドショーを指定できるので、条件を満たしています。

まずはインストールします。

% tce-load -wi feh-1.3.4

パッケージサイズを見てみましょう。

% tce-size feh-1.3.4
  feh-1.3.4.tcz                                303104,   0.29 MB
  giblib.tcz                                    40960,   0.04 MB

  Total size (bytes)                           344064,   0.33 MB
+ Indicates need to download                        0,   0.00 MB

tczパッケージのサイズ合計で、前回のEye of Gnomeは20.75MB、GQView1は1.92MB、そして今回のFehは0.33MBです。 えらい違いですね。

Fehでのスライドショーは、次のようにします。 Fehは自分ではスクリーンセーバをoffにしないので、xsetで切ってからにします(が、今のところxsetはうまくいっていません)。

% xset s off
% feh -F -D 10 -r --hide-pointer /mnt/hda2/Photos/

前回同様、画像ファイルが/mnt/hda2/Photos/に入っているとします。 Fehのオプションは、-F (フルスクリーン)、-D (スライドショーで一枚を表示する時間)、-r (ディレクトリを再帰的に検索)、--hide-pointer (フルスクリーンモードでマウスカーソルを消す)です。 また、-dをつけておくと、画像にオーバラップしてファイル名等の情報が表示されます。 .xsessionに入れるときも前回同様で、gqview1の代わりに上記の2つのコマンドを入れます。

このFeh、feh --helpで見てみるとわかりますが、そのほかにも動作中にマウスやキーボードでさまざまなコントロールができるなど、軽いくせにかなり高機能です。

この状態で、grubのメニューから、最初の画像が表示されるまでは約26秒です。 電源を入れてからgrubの待ち時間(3秒)も入れた、トータルの起動時間は約38秒となりました。 2秒の高速化はパッケージの大きさの差のせいでしょう。 free -mによるメモリ使用量は56MBでした。 これならメモリ64MBのマシンでも何とか動作しそうです。


いや待てよ。 Xorgのサイズを見てみましょう。

% tce-size Xorg-7.5
  expat2.tcz                                    77824,   0.07 MB
  fontconfig.tcz                               135168,   0.13 MB
  openssl-0.9.8.tcz                           2093056,   2.00 MB
  pixman.tcz                                   237568,   0.23 MB
  Xorg-7.5-bin.tcz                             311296,   0.30 MB
  Xorg-7.5-lib.tcz                             221184,   0.21 MB
  Xorg-7.5.tcz                               10235904,   9.76 MB
  Xorg-fonts.tcz                              1662976,   1.59 MB

  Total size (bytes)                         14974976,  14.28 MB
+ Indicates need to download                        0,   0.00 MB

14.28MBもあります。 この中には、不要なファイルもあるはずです。 これを最低限必要なファイルのみにして、やはりtinycore.gzに取り込んでしまえば、オプションのパッケージの読み込みを一切不要にできるわけです。 そもそも、Tiny Core Linuxの標準のtinycore.gzには、XvesaをベースとしたXの環境が付属しているわけで、必ずしもXorg-7.5のすべてのファイルがなくても動作するのではないでしょうか。

問題は、Xのファイル群はかなり複雑なので、必要・不要なファイルの洗い出しが大変なことでしょう。

とりあえずはTry & Errorでやってみるしかありません。 それについては...続きます(ていうか、やるのか?)。


(Initially posted on 16 April 2011)

これまでの流れ

さて、HDD(SSD)へのインストールも終わりました。 いよいよ必要なパッケージをインストールして、デジタルフォトフレームとしてスライドショーができるようにします。


スライドショーをするためのソフトの条件ですが、以下のようになります。

  • フルスクリーンで表示できること
  • スライドショーの機能(複数のファイルを次々に表示する)があること
  • これらを自動起動するため、上記をコマンドラインで指定できること

Tiny Core Linuxのパッケージで、画像を表示するためのプログラムで最も軽いのはおそらくflpicseeです。 これはtczファイルの状態で16kBしかありません。 しかも、スライドショーができます。 しかし、コマンドラインでスライドショーの指定ができないので、デジタルフォトフレームとしての「電源を入れたら写真を表示」が実現できません。

そのため、いくつかのソフトを調べてみました。 まず思いつくのはeog (Eye of Gnome)です。 多くの(GNOMEベースの)ディストリビューションで標準の画像ビューアになっており、スライドショーもコマンドラインで指定できます。 Tiny Coreのパッケージにもあるのですが、Gnomeベースであることもあり、とても重いのがしょんぼりです。

せっかく軽いOSを入れているのですし、単に画像を表示するだけで余計な機能はいらないので、なるべく軽いアプリケーションがよいわけです。

そこで目をつけたのがGQViewというアプリケーションです。 GQViewについては、Tiny Coreにはバージョン1と2の2種類のパッケージが提供されていますが、バージョン1はgtk1ベースで軽そうです。

容量を調べてみました。

% tce-size eog
  atk.tcz                                       53248,   0.05 MB
  bzip2-lib.tcz                                 28672,   0.03 MB
  cairo.tcz                                    512000,   0.49 MB
  dbus-glib.tcz                                106496,   0.10 MB
  dbus.tcz                                     315392,   0.30 MB
  eog.tcz                                      503808,   0.48 MB
  expat2.tcz                                    77824,   0.07 MB
  fontconfig.tcz                               135168,   0.13 MB
  GConf.tcz                                    233472,   0.22 MB
  gdk-pixbuf2.tcz                              221184,   0.21 MB
  glib2.tcz                                   1273856,   1.21 MB
  graphics-libs-1.tcz                          790528,   0.75 MB
  gtk2.tcz                                    3088384,   2.95 MB
  hicolor-icon-theme.tcz                         8192,   0.01 MB
  libcroco.tcz                                 233472,   0.22 MB
  libexempi.tcz                                413696,   0.39 MB
  libexif.tcz                                  147456,   0.14 MB
  libgnome-desktop.tcz                          77824,   0.07 MB
  libgsf.tcz                                   126976,   0.12 MB
  libIDL.tcz                                   163840,   0.16 MB
  librsvg.tcz                                  139264,   0.13 MB
  libstartup-notification.tcz                   16384,   0.02 MB
  libxcb-util.tcz                               36864,   0.04 MB
  libxcb.tcz                                   110592,   0.11 MB
  libxft.tcz                                    45056,   0.04 MB
  libxml2.tcz                                  696320,   0.66 MB
  openssl-0.9.8.tcz                           2093056,   2.00 MB
  ORBit2.tcz                                   241664,   0.23 MB
  pango.tcz                                    405504,   0.39 MB
  pixman.tcz                                   237568,   0.23 MB
  python.tcz                                  5836800,   5.57 MB
  shared-mime-info.tcz                         434176,   0.41 MB
  sqlite3.tcz                                  319488,   0.30 MB
  tcl.tcz                                     1482752,   1.41 MB
  tk.tcz                                       925696,   0.88 MB
  Xorg-7.5-lib.tcz                             221184,   0.21 MB

  Total size (bytes)                         21753856,  20.75 MB
+ Indicates need to download                        0,   0.00 MB
% tce-size gqview1
  gdk-pixbuf.tcz                               155648,   0.15 MB
  glib1.tcz                                     81920,   0.08 MB
  gqview1.tcz                                  249856,   0.24 MB
  graphics-libs-1.tcz                          790528,   0.75 MB
  gtk1.tcz                                     733184,   0.70 MB

  Total size (bytes)                          2011136,   1.92 MB
+ Indicates need to download                        0,   0.00 MB

tczパッケージのサイズ合計で、Eye of Gnomeは20.75MB、GQView1は1.92MBです。 10倍も違います。


というわけで、GQView1をインストールします(上記のtce-sizeの表示は既にインストールされた状態でのものなので、ダウンロード必要量が0になっています)。

% tce-load -wi gqview1

また、自動起動するために、.xsessionの最後に以下を追加します。

mount /mnt/hda2
gqview1 -f -s -t /mnt/hda2/Photos/*

mountを行っているのは、私の環境で画像ファイルをWindows領域(hda2)に入れているためです。 gqview1のオプションは、-f (フルスクリーン)、-s (スライドショー)、-t (ツールウィンドウを表示しない)となります。 編集したら、filetool.sh -bでバックアップを忘れずに。


これで起動時間を計測してみました。 grubのメニューから、最初の画像が表示されるまでは約28秒です。 電源を入れてからgrubの待ち時間(3秒)も入れた、トータルの起動時間は約40秒となりました。 もちろん、起動後はちゃんとスライドショーしています。

メモリ使用量ですが、高速化のためにパッケージをすべてメモリ展開する設定で、スライドショー実行中にfree -mで見た数値はused 98MB、free 87MBでした。 私のマシンはRAMを最大の192MB積んでいますが、これなら128MBの設定でもいけますね。

もっといえば、tinycore.gzや必要なパッケージをあらかじめ展開した状態でHDDにインストールする方法もあります。 こうすれば起動時の圧縮ファイルの読み込みと展開がなくなるので、さらに高速化することが期待できます。 ただ、そうなると細かいファイルがあちこちに散らばることになり、管理やアップデートが面倒になりますし、起動時にこれらのファイルをたくさん読み込むので、逆に遅くなる可能性もないとはいえません。 また、この方法はTiny Coreの配布元でも推奨されていません。 そのため、今のところは圧縮されたままにしてあります。


なお、最終的に私の環境における/mnt/hda2/tce/onboot.lstの内容は以下のとおりとなります。

Xorg-7.5.tcz
gqview1.tcz


Tiny CoreにはXorg-7.4もあるのですが、tce-sizeで見たところ、Xorg-7.5の14.28MBに対して、25.95MBもあるので意味がありません。 本当はXvesa等のTinyXが動けばもっと小さくなるのかもしれません。 TinyXにはTrident系グラフィックチップ用のXtridentというサーバもあるので試してみましたが、Dynabook SS 3410のCyber 9525には対応していないのか、うまくいきませんでした。 残念...。


ともあれ、これで「古いノート(Dynabook, メモリ192MB)にTiny Core Linuxを入れてデジタルフォトフレームにしよう」は一応完成です。 お疲れさま~。


と、思ったのですが、さらに軽量なイメージビューアであるFehを発見。 そして最適化への欲望が沸々と...続きます


Tiny Core Linux (5) - SSDへのインストール

| No Comments | No TrackBacks

(Initially posted on 15 April 2011)

ここまでで、ネットワークカードの認識ファームウェアのtinycore.gzへの取り込み、そしてXの起動までできました。 でもまだUSBから起動しています。 いい加減いちいち起動時にwaitusbを指定するのにも飽きてきたので、HDDにインストールします。

私の場合はCFベースのSSDを買ったので、ここに入れます。 ていうか、ちょうど買ったのが届いたので。 ちなみに買ったCFはTranscendの8GB、スピードは133x(20MB/s)なのでそれほど期待できませんが、HDD並みであれば文句はありません。 値段は2.5インチのHDDアダプタ含めて20ポンド(2,700円程度)ほどでした。 以前入れていた30GBのHDDのスピードが、実測でおおよそ20MB/sだったので、それよりは遅いでしょうが、ここでは静粛性のほうが大事です。


なお、ここでのインストール手順は、ほぼ公式ページの情報に準じていますが、私の環境の上での話のため、一部違うところもあるので注意してください。


まず、普通にUSBでTinyCoreを起動したあと、インストールのために必要なパッケージを入れておきます。

% tce-load -wi cfdisk
% tce-load -wi grub-0.97-splash

次に、インストールしたcfdiskを使って領域を設定します。

% sudo su
% cfdisk -z

-zオプションは、ゼロから領域設定するためのものです。 既に他のOSのために領域が設定されている場合はこのオプションはつけませんが、私の場合はオプションなしで起動しようとすると領域データがおかしくなって起動しなかったため、こうしました。 CFは8GBのものを買いましたが、領域は以下のようにしました。

  Name     Flags     Part Type   FS Type        [Label]    Size (MB)
-----------------------------------------------------------------------
  hda2     Boot      Primary     W95 FAT32(LBA)              5971.24
  hda1     Boot      Primary     Linux                       2047.87

次に、この領域をフォーマットして、必要なファイルをコピーします。

% mkfs.ext3 /dev/hda1
% rebuildfstab
% mount /mnt/hda1
% mkdir -p /mnt/hda1/boot/grub
% cp -p /mnt/sda1/boot/* /mnt/hda1/boot/
% cp -pr /mnt/sda1/tce /mnt/hda1/

そして、grubをインストールして起動可能にします。

% cp -p /usr/lib/grub/i386-pc/* /mnt/hda1/boot/grub/
% vi /mnt/hda1/boot/grub/menu.lst

grubで使うmenu.lstの中身は以下のようにしました。

default 0
timeout 3
title Tiny Core Linux
kernel /boot/bzImage quiet
initrd /boot/tinycore.gz
title Windows
root (hd0,1)
makeactive
chainloader +1

Windowsの領域にはまだ何も入っていませんが、あとで起動可能にするため、上記のようにエントリを追加しておきます。 hda2がhda1より前の領域に来ているのも、WindowsがCFをリムーバブルディスクとして認識可能にするためです。 Windowsはリムーバブルディスクの最初のエントリのみ認識するので。 Windowsが必要なければ、cfdiskですべての領域をLinuxにして、menu.lstのtitle Windows以下は不要です。

私は、いざというときにCFをPCMCIA経由で別のPCに挿入してファイルをコピーできるということで、上記のような設定にしています。 ちなみに、Windows領域は以下のようにしてフォーマット(FAT32)が可能です。

% tce-load -wi dosfstool-3.tcz (一般ユーザでやること)
% sudo mkfs.vfat -v -c -F 32 /dev/hda2

最後に、grubをインストールします。

% grub-install --root-directory=/mnt/hda1 /dev/hda

なぜか私の環境では、このコマンドは一度失敗し、2度目にうまくいきました。 もしgrub-installを使わないのであれば、grubコマンドを使った以下の方法もあります。

% grub
grub> root (hd0,0)
grub> setup (hd0)
grub> quit

以上でインストールは終了です。

% reboot

リブートして、うまく行ったか確認します。


なお、気になる性能ですが、hdparmで測定したところ、約20MB/sと出ました。 測定環境が違っていて直接比較はできないのですが、read性能については以前のHDDとほぼ同じ数値です。 速いわけではないですが、動作は全くの無音になり、HDDとさほど変わらないスピードを20ポンドほどで得られたので結構満足です。


引き続き、デジタルフォトフレームとしてスライドショーができるようにします。


Tiny Core Linux (4) - Xorgのインストール

| No Comments | No TrackBacks

(Initially posted on 14 April 2011)

前回ちょっと触れましたが、実はXがうまく起動していません。 テキストモードでない場合、起動中に応答がなくなり、Ctrl+Cで止めることになります。

調べたところ、.xsessionの最初のXvesaで止まっているようです。

ここで扱っているDynabook SS 3410のビデオチップはTrident Cyber 9525DVDというもの。 VRAMは2.5MBです。 ビデオチップとVRAMの組み合わせから可能な最大解像度は1024x768x16bitとなります。 Xvesaのデフォルトは1024x768x32bitなので、これは起動しないでしょう。

画面モードの問題かと思い、xsetupを実行してみると、今度はこれも動きません。 xsetup.shを見ると、中にあるXvesa -listmodesが何も応答しないのです。


調べてみても、XvesaとCyber 9525の組み合わせに関する情報は少なく、あまり得るものがありませんでした。 そこで、少々重くなりますが、ここではXvesaの代わりにXorgを使うことにします。

% tce-load -wi Xorg-7.5

これで、起動時にXorgが読み込まれれば、XvesaからXorgに入れ替わっています。 まだHDDにインストールしていないので、起動時に読み込まれるように、waitusbをつけます。

boot: tinycore waitusb=15

やってみると、うまくXが起動するようです。


ところが、デフォルトだと解像度が800x600となっており、液晶の解像度である1024x768になっていません。 これは、デフォルトの設定が1024x768x32bit colorとなっており、Cyber 9525ではVRAM(2.5MB)が足りなくなるせいのようです。 デジタルフォトフレームにはフルカラーが望ましいのですが、ハードウェアがサポートしていないものは仕方ありません。 解像度を取るか、色数を取るかのトレードオフとなります。 ここでは解像度を取ります。

これを修正するには、/etc/X11/xorg.confを作成、編集するのですが、元から入っているxorg.conf.vesaではうまく起動しません。 いろいろ試したところ、ここで見つけたものをベースにすると動作することがわかりました。 編集したものをおいておきます。

xorg.conf

/etc/X11/xorg.confを作成したら、リブート時にこのファイルが存在するように、バックアップの設定を変更します。 そのためには、/opt/.filetool.lstを修正します。 このファイルは、filetool.shを実行したときにどのファイルがバックアップされてmydata.tgzに格納されるかを表しています。 そのため、このファイルに以下のエントリを追加します。

/etc/X11/xorg.conf

修正したら、filetool.sh -bでバックアップしておきます。 なお、Xが起動しているので、GUIベースのfiletool (.shではない)やPanelのBackup/Restore、シャットダウン時のダイアログでもバックアップをすることが可能です。

続きます。


(Initially posted on 13 April 2011)

「古いノート(Dynabook, メモリ192MB)にTiny Core Linuxを入れてデジタルフォトフレームにしよう」(いつの間にかタイトルが...)ですが、ネットワークカードの認識まで来ました。


さて、必ずしもやらなくてもいいのですが、必要なファイルはd101m_ucode.binだけなので、あらかじめtinycore.gzに取り込んでおけば、ブート時にwaitusbをしなくて済み、起動時間が短縮できます。 また、この方法を知っておけば、起動時から有効な構成ファイルに変更を加えたいときなども役立ちます。

ここからは、Tiny Core Linuxの実環境上で作業します。 Dynabookからでもできますが、私は別マシンのVirtualBox上で作業しました。

後日触れる予定ですが、この段階では問題があってXが起動しません。 そのため、起動時にはテキストモードで作業します。 waitusbと、ついでにターミナルを複数使用可能にする(Alt-F1, Alt-F2等で切り替わります)ために、次のようにタイプして起動します。

boot: tinycore waitusb=15 text multivt


まず、あらかじめ次の3つのパッケージをインストールしておきます。

% tce-load -wi squashfs-tools-4.x.tcz
% tce-load -wi advcomp.tcz
% tce-load -wi firmware.tcz (前回入れたはずだが、もしまだない場合)

流れとしては、/tmpでtinycore.gzを展開し、必要なファイルを入れた上で再パック、というものです。 この手順は、Tiny Core LinuxのWikiを参考にしています。

まず、元となるtinycore.gzを展開します。

% sudo su
% cd /tmp
% mkdir tinycore
% cd tinycore
% zcat /mnt/sda1/boot/tinycore.gz | sudo cpio -i -H newc -d

次に、firmware.tczの中から必要なファイル(d101m_ucode.bin)を取り出して、適切なディレクトリ(/lib/firmware/e100)に入れます。

% mkdir lib/firmware
% mkdir lib/firmware/e100
% cd lib/firmware/e100
% unsquashfs /mnt/hda1/tce/optional/firmware.tcz 
% cp squashfs-root/usr/local/lib/firmware/e100/d101m_ucode.bin .
% rm -rf squashfs-root

これでファイルをコピーしましたので、再パックします。

% depmod -b /tmp/tinycore 2.6.33.3-tinycore
% cd /tmp/tinycore
% find | cpio -o -H newc | gzip -2 > ../tinycore.gz
% cd ..
% advdef -z4 tinycore.gz (動作しないときあり)
% exit

advdefはときどき"Killed"と出て処理が止まってしまうことがあります。 ただ、tinycore.gzをさらに小さくするためだけのものですので必須ではありません。


完成したtinycore.gzをブート領域にコピーします。 元のファイルも一応残して起きましょうか。

% cd /mnt/sda1/boot
% sudo mv tinycore.gz tinycore.gz.bak
% sudo cp /tmp/tinycore.gz .

うまく起動したら、firmware.tczをアンインストールしておきます。 USBメモリ上の/tce/options/firmware.tczを削除し、/tce/onboot.lstからfirmware.tczのエントリを削除します。 このエントリしかなければファイル自体を削除してもかまいません。


Xの設定へ続きます。


(Initially posted on 12 April 2011)

前に触れたとおり、Tiny Core Linuxを古いDynabook(Celeron 400MHz)にインストールします。 なお、バージョンはTiny Core Linux 3.5.1です。

このLinuxのディストリビューションは基本的に2つの圧縮ファイル(bzImage, tinycore.gz)でできており、起動するとRAM上に展開してそのまま動作します。 そのため、カスタマイズするにはこのディストリビューションファイルを変更する必要があります。 そのためのツールも用意されており(ezremaster)、もとのisoファイルから必要なアプリケーションやファイルを入れた新しいisoを作ることができます。


さて、Dynabook SS 3410はUSBから起動しませんが、PLoPを入れればUSBメモリ(USB CDはだめ)から起動させることができます。 USBメモリをdiskpartでパーティションをつくり、Tiny Core Live CDの内容を全部コピーします。 また、syslinuxを実行して起動可能にします。

% cd e:\boot (Windowsを利用していて、usbメモリのドライブレターがe:と仮定)
% mv isolinux syslinux
% cd syslinux
% mv isolinux.bin syslinux.bin
% mv isolinux.cfg syslinux.cfg
% syslinux -mi -d /boot/syslinux (ブートファイルが/boot/syslinuxにあるため)

最後のコマンドは、64ビットシステムで実行する場合はsyslinux64にします。


このメモリで起動すると、

e100: eth0: e100_request_firmware: Failed to load firmware "e100/d101m_ucode.bin": -2

というエラーが出て起動が途中で止まってしまいます。 調べたところ、これはネットワークカード用のファームウェアファイルがtinycore.gzに含まれていないせいであることがわかりました。

Tiny Coreには本体とは別にファームウェアの含まれたファイルがあり、これをUSBの/tce/optionalディレクトリに入れておくことで読み込ませることができます。 また、tceディレクトリには、onboot.lstというファイルを用意し、起動時に読みこませるファイルを指定します。

firmware.tczのダウンロードですが、通常はAppbrowserを使うこととなっています。 しかし、この場合ネットワークがつながっていないのでAppbrowserではダウンロードできません。 そこで、ミラーされているファイルを使います。

% cd e:\ (Windowsを利用していて、usbメモリのドライブレターがe:と仮定)
% mkdir tce
% mkdir tce/optional
% (ここにfirmware.tczをダウンロードする)
% cd ..
% echo firmware.tcz > onboot.lst

起動時は、USBの認識を待つために、必ずwaitusbを指定する必要があります。

boot: tinycore waitusb=10

これでネットワークカードが認識できました。


続きます。


Tiny Core Linux (1) - 序章

| No Comments | No TrackBacks

(Initially posted on 11 April 2011)

先日ちょっと触れましたが、小型軽量のLinuxディストリビューションに、Tiny Core Linuxというのがあります。 Live CDの容量が約10MBと、とにかく軽量なのが特徴で、コアシステムには余計なものは一切入れていません。 必要なアプリケーションはtczというパッケージに収められてネットワーク上にあり、オンデマンドにダウンロードして使ったり、インストールしてカスタマイズしたりします。 起動時間も早く、PCのスペックにもよりますが10~20秒で起動します。

作者はもともとDamn Small Linuxの開発者の一人であったRobert Shingledecker氏です。

なお、日本語化についてはSourceforge上のプロジェクトで議論されています。 私は特に日本語版に興味はないので、これはスキップします。 要求スペックも上がりますし。

ルータとして使うための小さなLinuxディストリビューションはいろいろありますが、Xが使えるのが大きなポイントです。

何に使いたいかというと、先日のデジタルフォトフレームです。 電源を入れたら決まったフォルダや外部ストレージに格納された写真をスライドショーしたいわけです。 パソコンとしてではなく、単なるフォトフレームとして使いたいので、短時間で起動することは大事ですし、余計な機能は入れなければ一切入らないTiny Coreは、この手のものを実現するにはベストに思えます。

これからこのTiny CoreをDynabook SS 3410にインストールして、高速起動するフォトフレーム「アプライアンス」(PCではない)を作ってみようと思います。


続きます。


(Initially posted on 3:12 PM, 9 April 2011)

私のところには、昔買った東芝のDynabook SS 3410があります。 Celeron 400MHzをベースとした軽量ラップトップで、2000年初頭に発売されたものを2003年に中古で40,000円程度で買いました。 拡張としては、メモリを最大の192MB(64MB+128MB)にしています。 このメモリが当時としては高く、10,000円程度したと思います。 よって、このマシンにかけたお金は50,000円程度と。

それから2年ほどWindows 2000マシンとして使っていたのですが、しばらくして使わなくなり、そのまま放置してありました。 いつの間にか当時のHDDもどこかに転用されてしまっていました。

こいつをもう一度使ってみようかと思い立ち、再度昔のWindows 2000をクリーンインストールしてみました。 このマシン、CD-ROMドライブはついておらず、必要なら専用品を買えという代物。 USBからのブートもできず、何とかフロッピーディスクドライブ(USB接続)が付属していたので、これが実質的に唯一最初にブートアップできるメディアです。 まぁ、ネットワークブートという手もあるにはありますが。

技術が進んでPLoP boot managerを使ってみたりHP USB Disk Storage Format Toolを使ってUSB Stickをブート可能にしたりして、余計なことをしたせいで回り道をしましたが、実際のところ手順は以下のとおり簡単でした。 なお、内蔵させたHDDは30GBのものです。


  1. フロッピードライブにWindows 98のブートディスクを入れて、ハードディスクをFAT32でフォーマット。
  2. sysコマンドでHDDを起動可能にする(sysコマンドなんて懐かしいですね)。
  3. HDDを外付けUSBケースに入れて母艦に接続し、Windows 2000のCD-ROMの内容(i386ディレクトリ)をコピー。
  4. HDDを戻し、起動してi386/winnt.exeを起動。


あえてWindows 2000を入れたのは、192MBというRAM容量を考えてのことです。 別にLinuxでもいいのですが、ディストリビューションを考えるのが面倒だったので。 さすがにUbuntuは苦しいので。

このマシン、起動すらできない状態が長く続いたので、とにかくなんかOSが走る状態になっていれば、あとはどうにでもなると思います。


で、わざわざマシンを復活させた理由です。 もちろん古いマシンで遊ぶというのもあるのですが、一番の目的はデジタルフォトフレームにすることなのです。 その意味では、軽量かつ高速に起動するTiny Core Linuxあたりを入れて起動と同時にスライドショーすればいいのですが、まぁこれはそのうちやりましょうかね。

(15 Apr 2011 追記) CFベースのSSDを導入して、Dynabook SS 3410にTiny Core Linuxのインストールを行いました。 こちらからどうぞ。

ついでに、つい8GBのCFカードと2.5 inch IDEのアダプタをAmazonでぽちっとしてしまいました。 HDDが結構うるさいので...。 古いマシンの再生にお金をかけるのは趣味ではないのですが、まぁ20ポンドほどだったのでいいでしょう。


Ubuntu 10.04 Lucid Lynx

| No Comments | No TrackBacks

先日リリースされたUbuntu 10.04を早速使っています。 アップグレードインストールも簡単にできるのですが、ハードディスクの入れ替え作業と重なったので、クリーンインストールしました。

まず最初に気づくのが、Xのマルチスクリーン(いわゆるextended desktop)とAMDのドライバでcompizが有効になることです。 これは今までできなかったのですが、複数のモニタを使っている人には朗報でしょう。

また、VirtualBox環境へのアップグレードインストールもしてみましたが、Update Managerにおける"Upgrade"ボタンに対する反応が非常に悪いです。 ボタンを押しても、しばらく動作しません。 アップデートが開始するまで数分~10分程度待つ必要があるようです。 ただ、いったん始まるとスムーズにインストールが進みます。

Core 2 Duo 1.4GHz上のVirtualBox環境において、ダウンロードは1時間、インストールにもう1時間くらいかかりました。

ただ問題として、VirtualBox上でのXのドライバがうまく動きません。 使っていたバージョンが3.1.4で、3.1.8にアップグレードした後、Guest Additionsを入れようとすると、画面がおかしくなって操作できなくなってしまいます。 これについてはまだ解決してはおらず、現状ではデフォルトドライバでの使用となってしまっています。


HGST HCS721010CLA332とdmraid

| No Comments | No TrackBacks

日立製ハードディスクが届いたので早速インストールしました。 2台買ったのは、RAID 0(ストライピング)するためです。 1台で1TBという容量は、現時点でそれほどハイエンドではないですが、現行モデルのため、それなりに速度は期待できます。 それを2台のストライピングで使おうというわけです。

ちなみに価格は1台あたり44.99ポンド。VAT込みでは約53ポンドとなります。 本日のおおよそのレート、1ポンド142円で計算すると約6,390円。 VAT抜きで現時点での秋葉原最安値(6,450円)に近いですね。

マシンがCore i7ベースであり、チップセットのICH10RがRAIDをサポートしているので、これで組みます。 ところで、世間ではこれを"Fake RAID"というらしいですね。 厳密には何がFakeなのか、未だによくわかってませんが、ソフトウェアの介在が必要だということでしょうか。 フルでソフトウェアで実現されているものもRAIDなんですけどね。 Fake(偽造)とまでいう理由がわかりません。

ついでにというか、Windows 7のライセンスも買ってしまいました。 これまではEnterpriseの試行版を少し使った程度だったのですが、ソフト屋として一応知っておいたほうがいいと思うのと、唯一あまっているWindows XPのライセンスが32ビット版で現在のPCに合わないためです。

買ったのは64ビット版のHome Premium。OEM版で価格は66.99ポンドでした。 1ポンド142円で約9,500円、VAT込みで約11,180円となります。 ちなみにXPも7も英語版です。 7については、Ultimateを買えば日本語版にもなるようですが、Windows 2000以降は英語版でも日本語がほぼ問題なく扱えるのであまり気にする必要はありません。

実際には、Ubuntu 10.04を入れていますし、そちらのほうが便利と思えることも多々あるんですけどね。 特に、ソフトのインストールに関しては、Ubuntu Software Centreの簡便さは一社で提供するWindowsには敵わないのではないかと思います。

まぁともかく、Windows 7をRAID 0パーティションに入れて、それをUbuntuから参照する形態にしました。 ファイルを溜め込むディスクはNTFSにしています。 理由は、WindowsからもLinuxからもアクセスできるためです。

まず、Windowsをインストールしたあと、Ubuntuから参照しようとすると、できません。 これはUbuntuがRAIDを認識していないためです。 最初からRAIDにしたディスクにインストールする場合はそれほど問題がないのかも知れませんが、今回は「既に存在する(NTFSの)RAIDパーティションをLinuxから認識する」必要があります。で、これには、

$ sudo apt-get install dmraid

でdmraidをインストールする必要があります。 LinuxでのRAID管理はmdadmもありますが、こちらは主にハードウェアが介在しないソフトウェアRAIDの管理がメインで、ICH10Rのような"Fake RAID"にはdmraidを使います。

基本的にdmraidはインストールするだけで認識するようになるみたいですが、心配なら、

(ICH10Rに管理されているRAID領域を表示)
$ dmraid -s
(ICH10Rに管理されているRAID領域をアクティベート)
$ dmraid -ay

を実行しておくとよいでしょう。

さて、その次に問題は起動です。 私はRAID領域にはWindows/NTFSしか置いていません。 すなわち、MBRにgrubは入れません。 Ubuntuは物理的に別のディスクから起動するようにしています。 これは、基本的に問題の切り分けを容易にするためなのですが、いろいろ試してもgrub-installではRAIDパーティションをうまく認識しませんでした。 grub-mkconfigではRAIDパーティションを認識しますが、その結果をgrub.cfgにして起動しようとすると失敗します。

今のところこれはまだ解決していません。 起動後は認識するので、BIOSのブートディスク選択でRAID (Windows 7)か非RAID(Windows XPまたはUbuntu)かを選択するようにしています。


grubのリカバリ

| No Comments | No TrackBacks

いろいろいじっていたら、grubが起動しなくなってしまいました。

GRUB loading stage 1.5
GRUB loading, please wait...

Error 17 : Cannot mount selected partition

という感じです。

どうも、bootパーティションがext4になってしまったのが原因のようです。 grubはext4からの起動ができないのですが、いじっていたらいつの間にか変換してしまったようです。

とりあえず、パーティションタイプを0x8e(Linux LVM)から0x83(Linux native)にしてみましたが状態は改善せず。 このマシンはCDからのブートもできないのでgrubが起動しないのはかなり致命的です。

仕方ないので、フロッピーにgrubを焼き、Windowsを起動します。 grubのイメージはalpha.gnu.orgにあるので、ここからgrub-0.97-i386-pc.extfsあたりを拾ってきて、rawriteで焼きます。 WindowsはHDDの最初のパーティションにあるので、フロッピーからgrubが起動したら"c"をタイプし、以下のコマンドを打ち込みます。

grub> rootnoverify (hd0,0)
grub> makeactive
grub> chainloader +1
grub> boot 

とりあえずWindowsが起動します。 ここから、UNetbootinをインストールし、NTLDRからXubuntuを起動します。

さらに、grubを修復するため、以下のようにしてgrubをインストールしなおします。

% grub-install --root-directory=/mnt /dev/sda

ここでインストールされるgrubはバージョン1.97~beta4で、以前の0.97と異なることに注意が必要です。 まず、/boot/grub/menu.lstを使いません。 また、HDDのパーティション番号は0ではなく1から始まるようになっています。 そのため、たとえばsda1はgrub 0.97では(hd0,0)ですが、grub 1.97~beta4では(hd0,1)となります。

grubインストール後の最初の起動では、UNetbootinからの起動オプションが有効になっているため、これを編集して(hd0,3)から起動できるようにします。 具体的には、grubのエディタモードに入り、

root=(hd0,3)
linux	/boot/vmlinuz-2.6.31-14-generic root=/dev/sda3
initrd	/boot/initrd.img-2.6.31-14-generic

のようにして起動します。

無事起動できたら、grubのメニューを本来の状態に戻します。 これはmenu.lstを編集するのではなく、ツールを使います。

% sudo grub-mkconfig > grub.cfg

これを/boot/grub/にコピーして終了です。 ふひぃ。


高機能になるのはありがたいのですが、いろいろ複雑になって覚えたテクニックが使えなくなってしまったりするのが大変ですね。


おまけ

以下を試してみましょう。

% aptitude moo
% aptitude -v moo
% aptitude -vv moo
% aptitude -vvv moo
...
  


Xubuntuの軽量化

| No Comments | No TrackBacks

Xubuntuで古いマシンを再生してみたのですが、やはり少々遅いです。

最近のLinuxはデスクトップ環境がよくできているので、そこそこコンピュータリテラシがある人であればすぐに使い始められるのですが、その代償として常駐ソフトが多いのです。 Xfceでは、標準状態で100MB程度のメモリを喰います。

Xfceのカスタマイズ

まずはこれをカスタマイズしてみます。

たとえばセッション起動・終了の設定では、スタートアップするアプリケーションをすべて解除します。 しかし、GUIツールによる設定だけでは十分に解除できません。

より深いGUI関連の設定は、/etc/xdg/xfce4や/etc/xdg/autostart/に入っています。 たとえば、/etc/xdg/autostart/に入っている*.desktopファイルの最後に、

Hidden=true

という一行を入れることにより、不要なサービスの起動を抑制できます。 なお、これはグローバルな設定であることに注意してください。 ユーザごとの設定はホームディレクトリ下にあります。

また、gnome-screensaverは/etc/xdg/xfce4/xinitrcに直書きしてあるので、これはコメントアウトしました。

今回はディスクスペースには余裕があるので、積極的にアンインストールはせず、サービスの停止などで対応しています。 ただ、それでも使わないmodem-managerやppp-confなどは常駐を避けるために削除しました。

192MBでどこまでイケる?

さて、LVPMで移行する際、swap領域を作り忘れてしまいました。 そのため、なんとしても192MB以内で処理をするということになります。 まぁ、あとでGPartedでどうにでもなるのですが。

そこで、Xfceよりも軽いといわれているLXDEを入れてみました。 インストールは簡単で、

% aptitude install lxde

で終わりです。 ログアウトし、セッションをXfceからLXDEに切り替えてログインすれば環境が切り替わります。

ログイン直後のメモリ使用量は60MB程度。 ついでに重いFirefoxの代わりにWebKitベースのMidori(緑)を入れます。 すると、ブラウザを起動してもメモリ使用量は100MBを下回ります。

私の環境(Celeron 400MHz/Memory 192MB)では、明らかに軽くなったのが感じられます。 特に、敢えてスワップなしで動かしているせいか、Xfceだとすぐ占有メモリがいっぱいになってきます。 そのときに、しばらくGUI操作が止まってしまうのですが、その頻度はかなり少なくなりました。

なお、LXDEの見た目はWindowsによく似ています。 Windowsキーこそ(デフォルトでは)使えませんが、Windows同様、Ctrl+ESCで"スタート"メニューを出すことができます。 もっとWindowsそっくりにすることも(意味があるかどうかは別にして :-p)可能でしょう。


Xubuntuで古いマシンを再生

| No Comments | No TrackBacks

うちには、昔使っていたラップトップがあります。 Toshiba Dynabook SS 3410で、以下のようなスペックです。

  • Mobile Celeron 400MHz
  • RAM 192MB
  • 内蔵グラフィック: Trident Cyber9525DVD

もともと内蔵されていた6GBのハードディスクは死んだので、余っていた60GBを使います。 これには、WindowsとFedoraが入っていますが、Fedoraは重いので多少軽いと評判(?)のUbuntuの派生のXubuntuをインストールしてみることにしました。

問題は、このマシンはCD-ROM起動をサポートしていないことです。 USB接続のフロッピーディスクドライブはあるのですが、最近のディストリビューションは(Ubuntu系も)フロッピーの起動をサポートしていないのも多いので、何とかすることにしました。

Lubi

まずはLinux上でUbuntuをインストールするLubiを試してみました。

Lubiをインストールすると、grubが更新され、起動メニューにUbuntuが登場します。 ところが、ブートデバイスが(hd0,-1)となっており、起動に失敗します。

もともとセカンドパーティションを使っているせいなのでしょうか。 本来のFedoraパーティションは(hd0,1)です。 Fedoraパーティションを見てみると、/wubiというディレクトリがあり、(hd0,-1)がここを指していると思われます。 これがブート不可なので、試しに/wubi以下を/bootにコピーします。 Ubuntuのgrubエントリの方も(hd0,1)に修正します。 すると、カーネルはロードするのですが、2度目のgrubでファイルが足りずにやはりブートが失敗します。

Wubi

なんだか面倒になっちゃったので、結局WindowsパーティションにWubiをインストールし、その後lvpmで移行しました。

WubiはWindowsパーティションに5GB程度の空きがあれば問題なくインストールが終了します。 再起動時には、grubで"Windows"を選んで、NTLDRにおいて"Ubuntu"を選ぶことによりUbuntuが起動します。 ついgrubのUbuntuエントリを選んでしまいそうになるのですが、これは上記のLubiでインストールに失敗したものなので、選んではいけません。

こちらは問題なく起動します。

パーティション移行

もともとディスクにはLinux(Fedora)用のパーティションがあったのですが、ext3の"/boot"とext4の"/"の2つに分かれていたので、gpartedをインストールし、ひとつに統合します。

% sudo aptitude install gparted
% sudo gparted

lvpmはgrubに含まれているので、grubをインストールします。

% sudo aptitude install grub
% lvpm

ここで私の場合、sda1がWindowsパーティション、sda2が上記で作成(統合)したubuntu用のパーティションなので、transferを選び、sda2に移動させます。 この移動ですが、マシンが非力なせいもあり、かなり時間がかかります(1時間以上)。

ちなみに、標準状態で自動取得していると思われるLCDの解像度は800x600まで、スピードも激重です。

終了してリブートしたのですが、grubでubuntuになるべき部分が"Unknown"になってしまっており、ブートできません。 そこで、/boot/grub/menu.lstを書き換えます。

title Xubuntu
kernel /boot/vmlinuz-2.6.31-14-generic root=/dev/sda2
initrd /boot/initrd.img-2.6.31-14-generic
boot

もちろんカーネルのバージョンはインストールされているものにあわせてください。 これで起動できるようになります。

Xorgの設定

あと、Xorgの解像度は、まず

% Xorg -config
  

でデフォルトのxorg.conf.newを作り、いくつか変更します。 以下に変更点のみ挙げます。

# Ctrl+Alt+Backspaceを有効にする
Section "ServerFlags"
	Option "DontZap" "off"
EndSection

# モニタモードを変更
Section "Monitor"
	Identifier	"Monitor0"
	Option		"DPMS"	"true"
	HoriSync	30.0-60.0
	VertRefresh	50.0-70.0
EndSection

# 全体設定
Section "Screen"
	Identifier	"Screen0"
	Device		"Card0"
	Monitor		"Monitor0"
	DefaultDepth	16
	SubSection	"Display"
		Depth	16
		Modes	"1024x768" "800x600" "640x480"
	EndSubSection
EndSection		

これで無事に1024x768で表示できるようになりました。 また、このレベルのマシンだと、NTFSを使うのに比べてかなりスピードが上がります。 とは言っても遅いのですが。

ひとまず環境ができたので、最適化はこれからです。


サーバの再構築

| No Comments | No TrackBacks

先日はサーバの再構築をしていました。 ちなみに、少し前にサーバにコネクトできていなかったのは単にルータがダウンしていたせいです。

サーバマシンを入れ替え、いままでのFedora 9からFedora 11に入れなおしました。 また、いろいろ考慮した結果、今回はVMで動かすことにしました。 アップグレードインストールは信用していないので、基本的にすべて入れなおしです。 手順は次のような感じです。

  1. VMをインストール
  2. Live CDからOSをインストール
  3. ファイアウォールの設定
  4. postfix, rpm-buildをインストール
  5. courier-authlibおよびcourier-imapをダウンロード
  6. rpmbuildでcourier-authlibおよびcourier-imapのrpmを作成
  7. courier-authlib, courier-authlib-devel, courier-imapをインストール
  8. courier-imapでpop3dをdisable(うちは全てimap)
  9. /etc/postfix/main.cfを設定(コピー)
  10. /etc/httpd/conf/httpd.confを設定(コピー)
  11. awstatsをインストールおよび設定(コピー)
  12. opensslの証明書を作成
  13. mod_sslをインストール
  14. serviceconfでhttpd, postfix, sshd, saslauthd, courier-imap, courier-authlib等を起動設定
  15. iptablesを設定(コピー)
  16. 旧マシンから/home, /var/log, /var/www, /var/spool/postfix等をコピー
  17. mysql-server, cpanをインストール
  18. CPANでDBI, DBD::mysql, Image::Magickをインストール
  19. 旧マシンでバックアップしたMovable Typeのデータを復旧

Movable Typeのデータの復活にてこずって、しばらくおかしな状況になってましたが、何とか直ったようです。

VMにしたのは、Windows系のファイルサーバを兼ねるためです。 バックアップ用のディスクが満杯になってしまったので、1.5TBのUSB接続ディスクを買ってきました。 USB接続ケース入りで99ポンドなので、まぁ高くはないかと。 せっかくサーバがあるので、NASを兼ねてしまえということです。

ただこのディスク、しばらくアクセスしていないと自動的にスタンバイになるのはいいのですが、ネットワーク経由で使っているときに「コトッ、コトッ」といいながらしばらくフリーズ状態になることがあります。 なんだろ?

で、旧サーバマシンはどうなったかというと、テレビに接続してメディアプレイヤーとなりました。 ものは無駄にしません。:-)


Captchaが表示されない件

| No Comments | No TrackBacks

なんか匿名コメントでCaptchaが表示されない不具合があったみたいです。 コメントの不具合は見た人がコメントで知らせることができない(ユーザ登録すればできますが)ので、気づきませんでした。

結局Captchaのイメージ用のディレクトリのアクセス権の問題でした。 今は(多分)解決していると思います。

あと、あまり関係はないのですがうちの食器洗浄器の不具合でブレーカが頻繁に落ちていた関係で、アクセスできないときがかなりあったみたいです。 昨日エンジニアに来て、直してもらいました。

サーバ移行はいろいろと細かい不具合が出るので面倒なのですが、自分でサーバを運営する以上仕方ないですね。 ときどきこういうことをすることで頭をリフレッシュできるので、まぁ良し悪しといったところです。


これの対処のためにいろいろやってたら、いつの間にかデザインが昔のものに戻って、しかも最近のコメントが数件消えてしまったようです...なんで??


アーカイブの設定

| No Comments | No TrackBacks
このブログのアーカイブが今ひとつ見にくいので、設定を変更したら、今度は個別ページに飛びにくくなってしまいました。ので、元に戻しました。

カテゴリごとのアーカイブを辿りやすくしたいのですが、今ひとつ設定方法がわかってません。

妹属性の人のための認証モジュール?

| No Comments | No TrackBacks
つい昨日、このブログのCAPTCHA認証がちゃんとセットアップされていないことが明らかになり、直したばかりなのですが。

なんと、「妹認証」なるものがあるそうです。なんでも、妹の質問に答えることで認証されるそうです。動作デモも公開されています。ネタではなく、れっきとしたCAPTCHA認証モジュールです。

技術的には、
  • 日本語のTrueType Fontに対応している
  • 質問と答えをセットで設定できる
というところが興味深いですね。

プログラム本体はPHPです。配布パッケージ内に、画像がpngファイルおよびpsdファイルで格納されている(ただし、psdは私の持っているPhotoshop 6.0では開きませんでした。CS3も持っていますが試してません)ので、妹が嫌な人は画像を変えていろいろできそうですね。

ある意味、パスワードリマインダー的な使い方もできます(質問・答えを動的設定すればよい)し、anonymousかつ会員制サイトみたいなものも作れます。実のところ、意外に隙を突いたアイデアだと思います。