富士通FMV-C8230でUbuntu

Windows XP終了で職場から大量放出された、職員用ノートPCを引き取ってきた。富士通の仕様のページに書かれているように、これは法人向けモデル。

さすがに7年前（2007年購入とラベルに書いてある）のマシンだけにやや不安だったけれども、無事パーツ入れ替え等でUbuntuが使える状態になったので報告。

まずメモリ、これは裏側の大きな蓋のなかにDIMMスロットがある。最大4GB。Core2Duoなんだからなんとかしてよーと思わないでもないけれども、マザーボードの設計がそうなんだそうで、やむなし。

「DDR2 PC2-5300」と書いてあるので、それに応じたメモリを買ってみた。製品だと、DDR2-667と書いてあるものに相当するようだ。2GB2枚セットで比較的割安だった、「UMAX Castor DCSoDDR2-4GB-667」で問題なし。

次がHDDなんだが、入っていたのは40GBの富士通製MHW2040BWとかいうドライブだったけれども7年毎日使ったものなので外して、SSDを入れることにした。予算がないので64GBにしたんだけれども、店頭では「ビッグドライブに対応していない可能性があるから120GBより大きいのは避けたほうがいい」とも言われて納得してたんだけれど、ネットをみると500GB認識したとか750GBでもとかいう話があって、「たいへん残念だ」。値段同じぐらいだから。1TBもいけるんではないか説も目にしたような気がするんだけれどもよく知らない。なお、SSDといっても所詮本体がSATA 1.5インタフェースなので速度はそう出ないから、最近のHDDでも十分限界まで引っ張れるのではないかと思う。

HDDはねじ1本で本体から外れる。そのあと、4本のねじでマウンタに固定されているので取り替える。もとは9mmだけれど、7mmの高さでも問題なし。固定されるから。というか、ネジ穴は面一というか底一で合う位置にあるので特に浮くという感じもない。

最後がCD-ROMのスリムDVDスーパーマルチドライブへの交換なんだけれど、これがネットのどこにも外し方が書いてないというぼやきを見たので、ここに書いておく。あ、ドライブのタイプはIDEなので、間違ってATAのドライブを買わないように（自分のことだが）。

んで、各種ネジをまとめて書いておいた。

FMV-C8230の裏面

この写真で見るように3つのネジだけで留まっているので、これを外してから、ゼムクリップを伸ばした針金でドライブトレイを開け、そのまま引き抜けばよい。と思ったら、左端は関係ないみたいね。たしかにドライブに取り付けられている金具に対応するネジは右の2本なので、これだけ外せばよいと思う。

参考

ベゼルは切り欠きがあるので、市販のドライブのベゼルとは違うから、うまくツメを精密ドライバなどで外してうまく引っ張れば外せる。新しいのも外して交換してやればよいわけだが、「DVDのロゴがない」という割と残念な結果になるので、同じ形になるよう切り取ったほうがいいような気がする。ミニ丸鋸盤かバンドソーあたりの機械があれば一発だと思う。もとのベゼルも結構周囲から浮いているので、あまり厳密な寸法で切らなくてもよいのではないか。

あと適当なドライブを挿してみて、BIOSで認識するかどうか、起動時にENTERを叩いてBIOSのメニュー項目を選んでみるわけだけれど、認識しなかったらマスターの設定になっているので、スレーブになるよう、「47番ピン」を倒し、それでだめなら「48番ピン」を倒して47番ピンとショートさせる、という作業がいるようだ。このページでは「千枚通しのような先端のとがったもの」と書いてあるけれど残念ながら当方には各種工具はあるものの文房具がいまひとつなので、カッターナイフの先端で端子を引っ掛けて内側に倒してみた。90度倒すために押しこむのは必要ないかもしれないけれど、精密ドライバあたりで押し込んでみたり。

今回はAmazonで2200円ぐらいだった東芝のドライブだったんだがこれに該当したので経緯を記すと、47番ピン（写真でいちばん奥から2番目）だけを倒した状態でBIOSセットアップでは認識したが、Ubuntuで認識せず、48番ピンも倒してショートさせたらBIOSセットアップから消えたけれどUbuntuで認識されるという不思議な結果だった。LinuxだからBIOS関係ないところがあるのかもしれないし、あまり深く考えていない。

で、UbuntuはDVDメディア入れないとファイルシステムにマウントされなくて、ファイルブラウザーからも見えないのね。最初慌てたので為念。

と、実はUbuntuのインストールはSDカードで行ったので作成したDVDは、このチェックのとき初めて使った次第。

SDカードをUSBカードリーダーに挿して、何か適当な方法でISOイメージを書き込んで（Mac OS Xなのでddで書いた。Raspberry PiのSDカードイメージ作成の説明が該当するので調べてください）、BIOSセットアップの起動順序で「USB HDD」を先頭にもってくればSDカードから起動する。たぶんDVDを読むより速いのではないかと思う。わりとあっさりとインストール完了したので偉いもんだなと思った。

そういえば忘れてたけど、Core2Duoなので当然64bit版OSを入れるべし。メモリも4GB全部（といっても一部はVRAMとシェアするので3.3GBぐらいしか使えないけど）使うんだったらWindowsでも64bit版が必要。

使用感だけれど、単体で使う分には特に問題ない印象。x11vncでMacと画面共有しようとするとXサーバが2つ立つことになるのでメモリが足りない感じがする。やはりスワップがあるとちときつい。

それから、古いマシンなのであまり省エネではない。CPUとかの発熱があって、いまどきのマシンと較べるとかなり熱くなるし、それほど静音というわけでもない。キーボード等もへたっているし液晶も4:3で四角いのでなんというか、「ラップトップ（というにふさわしいと思う。いまでは）のままでは使いたくない」感じ。なので、そのへんに置いて画面共有で使いたい。とはいえ発熱が結構あって、この手のマシンはキーボードやパームレストあたりを放熱に設計されていたりするので、液晶パネルを閉じた状態で動かすのは怖い。したがって開いたまま放置することに。いいんだか悪いんだか。

そういえば、7年前のマシンだけれどEthernetは1000Base-Tに対応しているので有線なら通信が遅いということはないはず。以前、ミニWiFiルータ（ホテルに有線しかなかったときに無線にしたりするアレ。といってもいまどき有線しかないところはあまりないので出番がない）のおまけについてきたUSBドングル（150Mbps）があったので、配線面倒でそれを挿して使っている。

で、このマシンが何になるかというと、前のエントリに書いたFxOSビルド用のつもり... だったんだが残念な結果になったのでいまのところ用途がない。まぁ、オープンソースの世界だと「Ubuntuでビルド」がデフォルト的なところがあるので、例えばRaspberry Pi用バイナリのクロスコンパイルなど、ARMのバイナリ作成用になる予感がする。

（追記）そういえばRaspberry Pi用mozcのクロスビルドという重要な用件があったっけ。セルフでビルドすると半日以上かかる感じなのでクロスビルド重要。そのうちやってみる。

Raspberry PiでVNC（ローカルのコンソールを使用しない場合）の設定

技術評論社から出たJapan Raspberry Pi Users Groupの本にほとんど基本的なことは掲載されているので、Raspberry Piを使いはじめるにあたってはこの本を参照すればたいていのことは解決すると思うのですが、若干補足めいた話。

授業でRaspberry Piを使わせるときに問題になるのはディスプレイとキーボード・マウスということは以前書いたと思うのですが、結論はVNCということになるので、VNCサーバに何を選ぶのか、試してみた結果を書いておきます。

ちょっと検索すると、TightVNCを入れるという話がすぐに見つかります。おそらく、Raspbian wheezyデフォルトはこれということなのでしょう。TightVNCは、vncserverコマンドでコンソールを使用しないXvncサーバを立ち上げるので、HDMI等のディスプレイを接続しないPiでもログインせずに遠隔クライアントから接続できるので、なにかと都合がよさそうです。

クライアントはMac OS X版のバイナリはないようだったので、Java版を使いました。

PiはWi-Fi接続（PCIブランドのGW-USWExtremeは発熱もなく、非常に好調に通信できています）ですが、十分な速度で描画されました。普通に使ってストレスのないレベルです。

問題は、LXDE右下の赤い電源ボタン風アイコンですが、ここをクリックしても「ログアウト」しか出ないため、シャットダウンがマウス操作ではできないこと。これはまた検討することにして、別のVNCサーバを試すことにしました。

x11vncは、コンソールで起動しているXサーバのミラーリングをするVNCサーバです。ミラーリングなので、コンソール画面と完全に一致した操作ができ、つまり電源ボタンでシャットダウンができるということです。

同じTightVNCのJavaクライアントで接続しますが、描画が非常に遅く、とても同じWi-Fiの下にいるとは思えないほどのストレスがありました。ひとつには、XとXvncの2つのサーバが上がっているためのメモリ不足、もしくは（あるいはそれに重ねて）ミラーリングのためのメモリ消費もしくはCPUパワー不足があるのかもしれません。

ひとまず、x11vncは候補から外してTightVNCに戻ることにしました。

/etc/init.d/vncserverとして、起動・終了スクリプトを作成します。lightdmとntpを参考にしたので冗長かもしれないのですが、とりあえずこんな風にしてあります。

#! /bin/sh
### BEGIN INIT INFO
# Provides: vncserver
# Required-Start: $network $remote_fs $syslog
# Required-Stop: $network $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop:  0 1 6
# Short-Description: TightVNC server
# Description: Debian init script for the TightVNC server
### END INIT INFO
set -e
PATH=/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/usr/bin/vncserver
PIDFILE=/home/pi/.vnc/vncserver:0.pid
test -x $DAEMON || exit 0
if [ -r /etc/default/locale ]; then
  . /etc/default/locale
  export LANG LANGUAGE
fi
. /lib/lsb/init-functions
case "$1" in
  start)
           log_daemon_msg: "Starting TightVNC Server: "vncserver"
           /usr/bin/sudo -u pi /usr/bin/vncserver :0 -rfbauth /home/pi/.vnc/passwd
           log_end_msg $?
  ;;
  stop)
          log_daemon_msg "Stopping VNC Server" "vncserver"
          set +e
                  /usr/bin/sudo -u pi /usr/bin/vncserver -kill :0
          set -e
          log_end_msg $?
  ;;
  status)
          status_of_proc -p "$PIDFILE" "$DAEMON" vncserver && exit 0 || exit $?
  ;;
  restart)
          $0 stop
          sleep 1
          $0 start
  ;;
  *)
          echo "Usage: /etc/init.d/vncserver {start|stop|restart|status}"
          exit 1
  ;;
esac
exit 0

このとき、先にコンソールからpiでログインしておき、vncpasswdを実行して、パスワードファイルを生成しておきます。このスクリプトで起動するvncserverが、パスワードファイルを参照するからです。

また、スクリプトを見ていただくとわかるとおり、piユーザとしてvncserverをディスプレイ番号0で起動しています。したがって、VNCクライアントからは、5900番ポートで接続し、設定したパスワードを入れればpiユーザのデスクトップ画面が現れる、という次第です。

これを、/etc/rc?.d ディレクトリ以下にリンクを張ってもらいます。

$ sudo update-rc.d vncserver start 5 2 3 4 5 . stop 1 0 1 6 .

これで、run levelが2, 3, 4, 5のときはvncserverを起動し、0, 1, 6のときには落とすようになります。つまり、通常のマルチユーザではvncserverが起動し、シャットダウンやシングルユーザモード等では落とすということになります。

Exynos騒動に関連して一言

Exynos 4210と4412の設計ミスか？　と、ちょっとワクテカしたのだがいまひとつ残念だったというのが率直なところ。

とはいえ世の中に出ているAndroid機器の台数では相当なものだろうから、CPU依存コードの修正版が配布されるまでは利用者にしてみればドキドキもんだろう。

今回の騒動は要するに、Androidの下にいるLinuxのCPU依存コード（カーネルコードの共有ライブラリ）をミスってユーザランドからカーネルメモリも自由に読み書きできるようになってました、という間抜けな話。Linuxカーネルのなかみはよくわからないけれども、メモリセグメントのrwx権限をもつテーブルかなにかのフラグ管理を間違えたんだろう。この手のミスは、複数箇所でフラグをいじるようなコードを書くと生じやすいので、ぶっちゃけスキル不十分なプログラマを投入した上に、きちんとしたコードレビューができるチームでなかったというところではないだろうか。

仕事上、韓国のIT技術者や研究者と接する機会が多いのだけれども、こういうところの品質が担保できる人材は少ないんだろうなと思うことが多い。日本メーカーもソフトウェア開発は苦手だけれども、そしてそれが組織作りや運営の問題ということが多いのだけれども、韓国人は日本人より大陸的というか、現場で失敗しながらスキルを身に着けることをよしとする傾向が強いので、上司（儒教社会なので目上や上の立場の人は絶対）が無能だとろくでもないものがあっさりと世の中に出てしまう感じだったりする。

で、一部にはAppleのiOSデバイス用CPUもサムソンの設計だからと怖がっている人が一部にいるみたいだけれど、AppleのAシリーズ開発はカリフォルニアでがっちり管理しているし、あのうるさいジョブズがこういう基幹技術の流出をよしとしたはずがないので、関わるエンジニアは完全に隔離されているというAppleとサムソン両者の説明はあながち嘘ではないと思う。

とはいえ、A4にはLimera1n exploit、A5にはデュアルコアの間の一貫性管理のミスというCPUロジックの致命的欠陥が脱獄に利用されているので、AppleのCPUだから安心というのはあまりに楽観的にすぎるといえる。iOSデバイスの場合、脱獄への強い動機があるので妙にトガッたティーンエージャーやそれ上がりの大人が寝食惜しんで脆弱性探しをしていることで発見されやすいのだけれど、おそらくどのメーカーのCPUにもexploitにまで組み上げられる何らかの欠陥のひとつやふたつは抱えているのだろうと思う。

知人の論理検証専門家が自社のCPUを対象に自分の研究成果を適用したらぼろぼろエラーが見つかって、上司に報告したらその検証ツールはお蔵入りにされたという話もきいているから、納期やコストなどの都合で、仕様書通りの動きさえすれば品質管理部門はOKを出しているのが実際のところではないかと思う。

つまるところ、ITに限らず製品やサービスに絶対の安心はないということ。人がやることなので、想定外とか手抜かりを見逃すとかいうことは必ずあるということを前提に付き合わざるをえない。「面白いなー」「便利だなー」で無邪気にアプリ収集に邁進したり、どっかの紹介やランキング上位を真に受けて突進するのは危ういと心がけるべきだ。

特に、なにかの記事や本での紹介は実質広告に過ぎないケースは多いし、ランキングというのは噂を流したり人海戦術でダウンロードしたりすることで簡単に上位に上がってくるものだ。ランキング操作も広い意味では「ステマ」の一種といえるだろう。詐欺の片棒担いだ「ステマ」有名人をあげつらう前に、「それは本当に必要なのか」と自分に問う習慣をつけるほうが、人生のいろいろな場面で余計なトラブルを避ける上でも役に立つはずだと言っておきたい。

Kobo TouchはCoretex-A8開発ボードらしい

@h_kenkenさんのツイートを追って、単なるブックマーク。

まず、日経ITProがKobo Hackについてまとめた記事。Raspberry PIを前フリにしてさっさとKoboの分解に進む潔さが好ましい。Kobo Touchだが、昨夜ヤフオクを見たら、ついに1000円台で投げ売っている人もいた。多くは5000円を切っているので、いまの騒ぎが続けばKobo Touch（ただし開発ボードとして）複数持ちという人も増えるのではないかと思う。

もうひとつは、MITOUJTAGを使った、どう考えてもKobo Touchを念頭に置いたとしか考えられない、iMX508のバウンダリスキャン事例紹介。ここまで可視化して内部を追えるというのがすごいなぁと感心。意外だったのは、MITOUはIPAの「未踏プロジェクト」とは何の関係もなさそうなこと。よく見たら、正式名称は「未踏ソフトウェア創造事業」で、ハードウェアごりごりするのは少し違うみたい。FPGAのHDLだってソフトウェアじゃないかのとかいうのが筋違いなんだろう。