SVX日記

2004|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|

2008-06-02(Mon) Fedora9、インストールチューン

  さて、先日から「Windows環境からの独立」を目的に、ジャンクのThinkPadX40を入手したり、そのHDD事情に絶望したり、SSD化したり、その遅さに驚愕したり、Fedora9を導入したり、その勝手の悪さに爆発したりしているのだが、ようやく「ほぼ独立に成功」することができた。

  ほぼ不満なく、日々の用途に使っている。その証拠に、ここ一週間Windowsを立ち上げていない。2年以上愛用しているノートPCで、初めての事態である。

  世にはアンチマイクロソフト野郎が溢れており、スラドに関連するトピックが上がる度に荒れているが、アンタらブツブツ言いながらも使ってんじゃあねぇの? 自分が脱出してしまってから見下ろすようでなんだけど、孫悟空ってぇ話、知ってるよね?

  なお、イザLinux環境に移行してみると、改めてWindowsのスゴさに気づくこともある。当然とはいえ、各種ハードウェアが素直に認識されるから何も考えずに済むし、アプリの品質も(高いものは)高い。

  だが、中の動作が何も見えず、押し付けられた機能の範囲でしか動くことしかできない環境が如何に不自由であるか気づいてしまうと、もう二度と戻りたくはないね。

  さて、インストールを始めることにしよう。

  今回のインストール先は、16GBのコンパクトフラッシュという特殊な環境だ。まぁ、決して広くはないが、狭すぎるというわけでもない。どちらかというと、問題はライトアクセスが遅いことだが、安いコンパクトフラッシュを使う以上は覚悟する必要がある。

  パーティショニングは以下とした。

Disk /dev/sda: 16.2 GB, 16240345088 bytes
255 heads, 63 sectors/track, 1974 cylinders
Units = シリンダ数 of 16065 * 512 = 8225280 bytes
Disk identifier: 0x000148b6
 
デバイス Boot      Start         End      Blocks   Id  System
/dev/sda1   *           3        1410    11309760   83  Linux
/dev/sda2            1411        1462      417690   82  Linux swap / Solaris
/dev/sda3            1463        1974     4112640   83  Linux

  ミソは、先頭パーティションを3シリンダ目からにしているトコロ。このページによれば、フラッシュメモリの破壊はブロックの先頭に出る傾向があるそうだ。一般に、デバイスの先頭にはマスターブートレコードがあり、ここが壊れると、デバイス全体がゴミになってしまう可能性がある。

  先頭がそんなに書き換わるか? というと、おそらくはかなりの頻度で書き換わる。というのも、先頭のすぐ後ろには、ext3ファイルシステムのスーパーブロックがあり、これは数十秒に一回程度の頻度で書き換わる性質があるからだ。半分は推測だが、フラッシュメモリは、数バイトを書き換えるだけの場合でも、ブロック全体を書き直す必要があるはず。そうなると、スーパーブロックが書き換わる時には、周辺数10キロバイトも書き直されると思われ、先頭のMBRもトバッチリを受ける可能性が高い。

  よって、余裕をみて先頭2シリンダを空けておくワケだ。で、もし3シリンダ目が壊れたら、今度は4シリンダ目からフォーマットしなおして使うのだ。この推測が正しいのか、ホントに効果があるのか、それはわからんが、まぁ、やっておいて損はないだろう。

  ちなみにこのような変則的なパーティショニングは、Fedora9のインストーラであるanacondaでは不可能だ。よって、事前に別のマシンか、レスキューモードを利用するなどして、fdiskを使って切っておき、anacondaからは領域の「用途変更とフォーマット」という形でインストールを進める必要がある。

  で、インストールだが、X40にはディスクドライブが付いていないので、PXEブートを利用して、ネットワークインストールを行う必要がある。これまた母艦を用意して、dhcpサーバ、tftpサーバ、httpサーバを立て、Fedora9のisoイメージをhttpアクセスできるようにしなければならないのでひと苦労だが、この方法はそこいらにあるので省略。

  インストーラが立ち上がったら、日本語環境、英語キーボードを選択して、最難関のホスト名決めだ。うーむ……(小一時間経過)……よし、色が黒いからカラスということにして「raven」としよう。赤い「suzaku」も一応は鳥なので組み合わせもいい。

  パッケージは、開発環境、ruby、ひととおりのサーバ機能を追加して、いざ、インストール開始ッ!!

  ちなみに、安物のコンパクトフラッシュはライトアクセスが劇遅なので、インストールには異様に時間がかかる。私が計測した限りでは、0:20開始、4:47終了だった。普通の人は、寝る前に開始して、翌朝まで放置しておくのがいいだろう。

  ……といいつつも、オイラは花金なのをいいことに、律儀に終了を待っていたりする。実は、インストール直後の起動後には、ライブラリの動的リンクを高速化するprelinkや、manページをデータベース化するmakewhatis、高速なファイル検索コマンドであるlocateを使うためのmlocateなど、大量のディスクアクセスを行う処理がcron起動されるからである。この処理には、コンパクトフラッシュ環境だと、かなりの時間を要し、その間はI/O帯域が食いつぶされるので、マトモにオペレーションができないからである。

  よって、インストール完了後に「起動させてから」寝るのであった。というわけで、おやすみ。