2006-02-23 .. 2010-01-05 2006-02-23 .. 2010-01-05
ここに掲載する内容は覚え書き程度です。情報の確度・精度についてはあまり期待しないでください。
「Debian (5.0 - lenny) に関するいくつかの覚え書き」「ネットワーク性能の最適化」「GeForce FX 5700 のファンの静音化」「Debian (5.0 - lenny) の X.Org 7.3 と Matrox G550」「X.Org 7.4 と Matrox G550」「Debian (3.2 - Etch) における X-Window と nvidia ドライバ」「NVClock による GPU ファンの静音化」「CUI 環境の画像モード化」「Planex ENW-9501-F のドライバ」「SB AWE64 のドライバ」「ファイルシステム」「Synaptic の設定」
Windows でも話題になるのが、MTU と RWIN を中心としたネットワークの設定値の最適化。Linux の場合は、TCP Tuning Guide という文書があるようなので、言われている通りにそのまま以下の記述を、/etc/sysctl.conf に追加した。
# cf. http://fasterdata.es.net/TCP-tuning//linux.html # increase TCP max buffer size setable using setsockopt() net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 # increase Linux autotuning TCP buffer limits # min, default, and max number of bytes to use # set max to at least 4MB, or higher if you use very high BDP paths net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216 # don't cache ssthresh from previous connection net.ipv4.tcp_no_metrics_save = 1 net.ipv4.tcp_moderate_rcvbuf = 1 # recommended to increase this for 1000 BT or higher net.core.netdev_max_backlog = 2500 # for 10 GigE, use this # net.core.netdev_max_backlog = 30000
あと、MTU だけは ipconfig で設定するので、起動スクリプト /etc/rc.local に
ifconfig eth0 mtu 1492
という記述を追加した。1492 という値は、KDDI（auone-net）用のもので、NTT（Flet's）用の値 1454 とは違っているので注意。
2 年前に testing 時代の Debian (3.2 - etch) を同じマシンにインストールした時、NVClock 0.8b にパッチを当てて、ファンを静音化することが可能だった。ところが、最新の Debian (5.03 - lenny) では、NVClock がセンサーチップを認識できず、ファンを制御することができない。これには困った。FX 5700 は最新の X.Org 7.x を動作させるにはまだ十分なパフォーマンスが出るのだが、ファンが爆音過ぎて不快きわまりない。
NVClock のソースを眺めてちょっと弄ってみたりしたけど、今回はどうにもならなかった。
仕方ないので、自分でゼロからプログラムを書くことにした。Perl には習熟しているとはいえ、C 言語でプログラムを組むのは今回が初めて。それも Linux という慣れないプラットフォームの i2c デバイスを制御するという、情報も豊富ではないドライバーレベルでのプログラミングだ。
まず、センサーチップは Fintek の F75373S というものなのだが、これについての情報は以前 NVClock にパッチを当てた時にネットで調べて手に入れたデータシートが手元に残っている。次に、lm_sensors という有名なツールがあるのだが、それを使ってまずは、F75373S が存在する i2c バスの番号と、サブチャンネルの番号を確認した。lm_sensors で認識されているということは、OS やドライバの問題ではないことから、何とかなりそうだ。i2c_dev というモジュールが有効になっていることが条件らしい。
次に i2c ドライバーの利用方法については、Linux カーネルの i2c ドライバーに関する公式の情報を利用した。そこで紹介されたプログラムを参考にしながら、初めての C プログラムをフルスクラッチで書いていった。要するに、必要なライブラリさえ include してしまえば、i2c デバイスは一般のファイルとして open / close / read / write が可能になる。データシートに従って、特定のレジスターアドレスに適切な数値を書き込むと、意図した通りに、ファンの回転数が下がった。
上記のプログラムを温度に応じて回転数を自動で制御するようなものにして、OS 起動時に /etc/rc.local でバックグラウンド起動（シェルコマンドで末尾に「&」付きで起動）するためのプログラムとしてブラッシュアップした。ATFintek と名付けて、Sourceforge.jp で公開中。
ちなみに前提条件として、nvidia ドライバーと i2c_dev モジュールが有効であることが必要である。
Debian (5.0 - lenny) のデフォルトのインストールで設定される X.Org 7.3 では Matrox G550 の DVI 出力が表示されない。また Matrox もドライバーのサポートを既に打ち切っている。そこでアナログ出力で Debian を立ち上げながら、情報収集と試行錯誤の末、クリアすることができた。
ひとえに以下の 2 つの情報源のお陰です：
まず最初に tuxx-home のドライバーを試してみたが、X.Org 7.0 までしか対応していないようで、上手く行かなかった。そこで Kei Kishiro さんの情報にたどり着いたが、Kishiro さんは FreeBSD なので Linux でも上手く行くのかどうかは不明。しかし恐らく上手く行くはずという Kishiro さんのコメントを信じて指示に従ってトライ。見事成功、感謝感激！
ただし、Debian はデフォルトのインストール状態では、ドライバーをコンパイルするツールも揃っていない状況で、相当色んなパッケージを Synaptic でインストールする必要があった。必要となる多くのパッケージは tuxx-home で見つけた HOWTO_mga_Xorg7 という説明が参考になるが、そこに掲載されていたもの以外にも make だとか gawk だとか g++ だとかも必要だった。
コンパイルさえ無事にできてしまえば、Kei さんの指示通りに、2 つのドライバーファイルを /usr/lib/xorg/modules/drivers/（この場所だけが FreeBSD と微妙に違っているようだ）に置けば完了。あとはケーブルをアナログから DVI につなぎ替えるだけ。
使えるかどうかわかりませんが、コンパイルできた 2 つのドライバーファイルを置いておきます。［mga_Xorg7.3.tar.gz］
上記のように、X.Org 7.3 では G550 は使えるようになったが、X.Org の最新の 7.4 では、色々とやってみたりしたが、Kishiro さんのパッチも通用せず、どうやってもドライバーがインストールできなかった。例えば Ubuntu の最新の 9.04 は X.Org 7.4 なのでドライバーのインストールが不可、その結果 DVI 出力で使用することができない。Debian の次期バージョン（squeeze）でも X.Org は 7.4 以降にバージョンアップされるだろうから、将来性に不安がつのる。Linux の代わりに FreeBSD という考えも頭をよぎるが、実は FreeBSD も最新の 7.2 では X.Org は 7.4 らしい。その後の Kishiro さんの情報によると、X.Org 7.4 から PCI Rework と呼ばれるドライバの更新があったようで、これまでのパッチで対応できる手のものではなくなったらしい。せっかく PC-UNIX のためだけに中古で入手した G550 だったけど、ここはあっさりと G550 を見限り、爆音ファンの GeForce FX 5700 に戻すことにした。
nVidia GeForceFX 5700 のドライバー（173.14.xx 系列）は既にレガシードライバーとして扱われており、基本的には開発終了の扱いとなっている。
ドライバーのインストールは、少々面倒で、root ユーザーとして行わなければならず、さらに X-Window が起動していない状態でなければ、インストーラーが作業を始めてくれない。X-Window を停止する方法がわからないので、仕方なく、シングルモードで起動して作業を行っている。
まずは、ドライバーのインストールに先立って、ドライバーのソースファイルを修正してカスタマイズをしておく。ソースファイルを展開するにはインストーラーを --extract-only オプションで実行する。
僕のハードウェア環境の場合、修正ポイントは 2 点。
VIA の Apollo Pro 133 系チップセットの M/B の場合、カタログスペック上は AGP の転送モードが 4X までとなっているのだが、これは不安定なので nvidia ドライバは既定ではわざと 2X に性能を落とす仕様になっている。これは敢えて 4X にしたい場合は、NVIDIA-Linux-x86-173.14.20-pkg1/usr/src/nv/nv-reg.h を以下のように修正する：
- NV_DEFINE_PARAMS_TABLE_ENTRY(__NV_ENABLE_VIA_4X), + NV_DEFINE_PARAMS_TABLE_ENTRY(__NV_ENABLE_VIA_4X, 1),
次に SBA (Side Band Addresssing) を有効化する設定。North Bridge の 82C694x では SBA 可能（一方、FW は不可らしい）なのだが、nvidia ドライバは既定ではこれらの機能を無効にしている。SBA や FW (Fast Write) を有効にするには、/etc/modprobe.d を使う方法でも可だが、前述の 4X モードの修正と一緒に os-registry.c の修正で済ませることにする：
- NV_DEFINE_PARAMS_TABLE_ENTRY(__NV_ENABLE_AGPSBA), + NV_DEFINE_PARAMS_TABLE_ENTRY(__NV_ENABLE_AGPSBA, 1),
ちなみに、FW 可のチップセットの M/B の場合は同様に (__NV_ENABLE_AGPFW, 1) にすればいい。
AGP ホストブリッジやビデオカードの性能を調べる方法：
ソースの修正が終わったら、シングルモードで再起動して、展開されたディレクトリの中にある nvidia-installer を -n オプションで実行する。
ただし、コンパイルに gcc と make が必要となるので、インストールされていない場合は、Synaptic で準備しておく必要がある。また、gcc のバージョンが違うという警告が出るが、無視しても問題はなかった。
Debian におけるディスプレイ関係の設定について、僕個人のハードウェア環境固有の問題を交えて記す。
現行の Debian の安定版（3.1 - Sarge）ではなく試行版（3.2 - Etch）を使った理由は、この前後で、xserver が大きく変更されているため。Sarge では従来の XFree86 4.3 が使われていたが、Etch では X.Org のものに変更されている（XFree86.org の“お家騒動”によって XFree86 版の功労者が脱退して X.Org 版を新規に立ち上げたらしく、世の趨勢は X.Org 版に傾いているようだ）。Unix マシンをクライアント用途で使う場合には、X-Window の良否は急所となる点なので、試行版の Etch を使うことのデメリットよりも優先させることにした。
また、僕が使っているビデオカードの nVidia GeForceFX 5700 という比較的新しい GPU の対応も Etch では済んでいる（Sarge では 800x600 の汎用 vesa としてしか認識しない）。まあ、この問題はあくまでもインストール時点での話で、Etch にしろ Sarge にしろ、Linux のインストール後に自分で最新の nvidia ドライバを入手してきちんとインストールする場合にはあまり重要ではない（だが、自分で思うようにドライバのインストール等ができない初心者にとっては安心できる）。
次に nvidia ドライバを改めてインストールしたいのだが、その前にカーネルを再構成する。その理由は、nvidia ドライバのインストールは Linux カーネルのソース（厳密にはソースの内のヘッダファイル）を必要とするからである。
──ということは、わざわざカーネルを再構成せずとも、現行のカーネルと同じバージョンのカーネルのソース（ヘッダだけでも可）を入手して用意すれば用が足りるということになる（Debian なので apt-get ツール等でカーネルソース（又はヘッダ）を入手できる）のではないか？ しかし、実は他にももう一つ問題があって、nvidia の AGP ホストブリッジ用ドライバを有効にするには、汎用の AGP ホストブリッジ用ドライバである agpart を無効にする必要があるのである。そのためには、カーネルの構成の選択を変更して、agpart を使わない選択でカーネルを再構成しなければならない。
ちなみに僕のハードウェア環境の場合、M/B のチップ構成が VIA Apollo Pro 133T で、AGP は North Bridge チップの VT82C694T が担当している。すなわちこれは nvidia ドライバの README（後述）の付録 F に掲載されている AGP 対応チップ（82C694x）に該当する。
つまり、どのみちカーネルの再構成は避けられないので、「カーネルソースの入手」と「agpart の無効化」を兼ねて、kernel.org から最新の Linux カーネルを入手し、カーネルの再構成を行う。
ちなみにカーネルの再構成のコツとしては、いきなり色んな選択を変更しないことである。ここで目的とする agpart の選択を No にする以外は、最初のうちは、CPU 種の選択（僕の場合 Pentium III 世代）程度で、残りは全て既定のままで一度構成して、カーネルを入れ換えて再起動後に各種デバイスドライバが正常に認識して組み込まれるのを確認した方がいい。
3.2 (Etch) のインストール後の既定状態でも、X-Window 環境を使った普通の作業には全く支障がない。ただ、GeForceFX 5700 の本来の性能を発揮させるには、最新の nvidia ドライバをインストールしてちゃんと調整する必要がある。
前項のカーネルの再構成作業で、既に /usr/src/linux にカーネルソースを保持しているので、nvidia ドライバのインストーラが動作する条件は整っている。ただし、他にもいくつか細かい条件があって、X-Window モードではなく CUI のコンソールモードで作業を行わなければならない（これは、single モード（メンテナンスモード）で起動すればいい）とか、もしかしたら ncurses ツール（これはカーネルの再構成の際に menuconfig を使っていればそのためにインストールするはず。apt-get で入手すれば ok）も必要だったかもしれない。
通常は、README（ドライバのダウンロードページから参照できる）に従って自動モードでインストールすればいいのだが、僕のハードウェア環境では多少設定を最適化するために手動モードでインストールする。この手動モードのインストール方法は README の付録 F に説明されているやり方であり、まずインストールパッケージを解凍し、パッケージ中のドライバのソースコードを修正してから、インストーラを -n オプション付きで動作させるやり方である。
僕のハードウェア環境の場合、修正ポイントは 2 点。
VIA の Apollo Pro 133 系チップセットの場合、カタログスペック上は AGP の転送モードが 4X までとなっているのだが、これは不安定なので nvidia ドライバは既定ではわざと 2X に性能を落とす仕様になっている。これは敢えて 4X にしたい場合は、NVIDIA-Linux-x86-1.0-8178-pkg1/usr/src/nv/os-registry.c を以下のように修正する：
-static int NVreg_EnableVia4x = 0; +static int NVreg_EnableVia4x = 1;
次に SBA (Side Band Addresssing) を有効化する設定。North Bridge の 82C694x では SBA 可能（一方、FW は不可らしい）なのだが、nvidia ドライバは既定ではこれらの機能を無効にしている。SBA や FW (Fast Write) を有効にするには、/etc/modprobe.d を使う方法でも可だが、前述の 4X モードの修正と一緒に os-registry.c の修正で済ませることにする：
-static int NVreg_EnableAGPSBA = 0; +static int NVreg_EnableAGPSBA = 1;
ちなみに、FW 可のハードウェア環境の人の場合は同様に NVreg_EnableAGPFW=1 にすればいい。
AGP ホストブリッジやビデオカードの性能を調べる方法：
後はインストーラを -n オプション付きでインストールする。以上の作業の結果、僕のハードウェア環境において、AGP 4X モード、SBA 有効で X-Window を利用できるようになった。
ところで、nvidia ドライバは、単にドライバとしての機能を提供するだけではなく、インストール時に Linux のカーネルを一部改変するみたいだ（おそらくそのためにカーネルソースを利用する）。nvidia ドライバをインストールすると、起動メッセージで nvidia が カーネルを侵して（taint）いると表示されるようになる。
そういう風なことになっているので、カーネルを再構成した場合には、その改変が取り消されてしまい、nvidia ドライバが立ち上がらなくなる。従って、nvidia ドライバを再インストールしなければならない事態になる。だから僕の場合、解凍した nvidia ドライバのインストールフォルダを Linux のソースフォルダと並べて /usr/src に保持しておいて、カーネルの再構成時には毎回 nvidia ドライバのインストーラも続けて利用できるようにしている。
例として、僕が使っているカーネル再構成用のシェルスクリプトは下のような感じ。カーネル再構成後、続けて nvidia インストーラが立ち上がるようにしている。
#!/bin/sh cd /usr/src/linux make clean make all make modules_install mkinitrd -o /boot/initrd-2.6.15.4.img 2.6.15.4 cp /usr/src/linux/arch/i386/boot/bzImage /boot/bzImage-2.6.15.4 cp /usr/src/linux/System.map /boot/System.map-2.6.15.4 /usr/src/NVIDIA-Linux-x86-1.0-8178-pkg1/nvidia-installer -n shutdown -r now
僕の PC のビデオカード（Asus V9570/TD）は、そのままでは GPU 冷却用ファンがフル回転して轟音を立てるので厄介だ。一応、Windows においては Asus から SmartDoctor というファン操作のできるユーティリティが提供されているので問題ないが、Linux 版は提供されていない。そこでネットを探してみたところ、Linux で（どうやら唯一）そのようなことを実現しているフリーウェアの NVClock というツールを見つけた（やはりこういうこともやってのけてしまう人がいるのだから、オープンソース／フリーウェアの世界のハッカーには頭が下がる）。
どうやらこの NVClock は、Debian のパッケージにも取り込まれているメジャーツールで、nVidia のチップにはほとんど対応しているらしい。──だが残念なことに、GeForceFX 5700 に関しては非対応だった。ちょうど僕が NVClock のことを知って NVClock のサイトのフォーラムを覗いてみたところ、去年（2005）の暮れあたりから GeForceFX 5700 の所有者と作者の thunderbird さんの間でやりとりがあったようだが、作者自身が現物を所有していないことが障害となって迷宮入り状態だったようだ。
僕は半ば諦めかけたのだが、逆にやけくそ半分でファンコントローラチップのデータシートを検索してみたりした。すると、チップメーカのサイトを見て Fintek F75373S と Fintek F75375S の 2 種類のファンコントローラチップが存在することがわかった。フォーラムのやりとりを見ていると、thunderbird さんは F75373S を F75375S と勘違いしているように思われた。そこでフォーラムにメッセージを投稿して反応を覗ってみたところ（yamato-boy が僕）、どうやらその通りらしい。そこで次の日にでも直してもらえるかと思ったが、我慢できなかった僕は、C/C++ 言語には素人も同然なのに思い切って NVClock のソースコードに目を通してみることにした。そして、データシートを見比べても F75373S と F75375S との違いはチップ ID の違いぐらいでしかなかったので、F75375S 用のモジュール（src/backend/f75375.c）が F75373S でも動くようにほんの少し修正してみて（下記参照）、NVClock をコンパイルしてみた。
if (MERGE_BYTE(nvh, nvl) == 0x0306) {
dev->chip_id = F75375;
dev->chip_name = (char*)strdup("Fintek F75375S");
return 1;
}
+ else if (MERGE_BYTE(nvh, nvl) == 0x0204) {
+ dev->chip_id = F75375;
+ dev->chip_name = (char*)strdup("Fintek F75373S");
+ return 1;
+ }
return 0;
すると上手くいった！ ちゃんとファンの回転数を落とせるようになった。まさしくオープンソースの勝利といったところである。早速、フォーラムにそのことを報告しておいた（修正は CVS に反映されるとのこと）。
これは前述のようなバグフィックスの話ではないが、回転数を 10%（2000rpm 程度）までしか落とせない NVClock の仕様（おそらく安全性のため）を 5% まで落とせるようにする修正についてである。僕のマシンでは 5%（1000rpm）ぐらいまでは安全に回転を落とすことができる。3% 以下ぐらいになってくると、多少不安定で、ファンが止ってしまったりする。ファンの回転数の下限を修正するには、src/nvclock.c を以下のように修正する：
- printf(" -F --fanspeed speed\t\tAdjust the fanspeed; speed is a value between 10 and 100.\n");
+ printf(" -F --fanspeed speed\t\tAdjust the fanspeed; speed is a value between 5 and 100.\n");
- if((fanspeed < 10) || (fanspeed > 100))
+ if((fanspeed < 5) || (fanspeed > 100))
- printf("Error: Incorrect fanspeed '%.1f', you need to choose a value between 10%% and 100%%\n", fanspeed);
+ printf("Error: Incorrect fanspeed '%.1f', you need to choose a value between 5%% and 100%%\n", fanspeed);
- nv_card.set_i2c_fanspeed_pwm(nv_card.sensor, fanspeed); /* speed is a value between 10% and 100% */
+ nv_card.set_i2c_fanspeed_pwm(nv_card.sensor, fanspeed); /* speed is a value between 5% and 100% */
NVClock をシステム起動時に自動で起動してファンの回転数を 5% に絞るようにしておく。要するに /etc/init.d を使った起動スクリプト（例えば /etc/init.d/silent.sh）を作る：
#!/bin/sh /usr/local/bin/nvclock -fF 5
これに実行レベルに応じたシンボリックリンクを作成するわけだが、僕の場合は、システム起動レベルの 69（/etc/rcS.d/S69silent.sh）を使っている（普通に rc1.d を使うと、シングルモード起動の場合に上手く実行されなかったので rcS.d を使うことにした）。
cd /etc/init.d ln -s ../init.d/silent.sh /etc/rcS.d/S69silent.sh
grub の起動メニュー（/boot/grub/menu.lst）を少しいじるだけで、簡単に Linux の CUI 環境を画像モード化できる。X-Window を大前提にしているユーザの場合は場合はあまり意味がないかもしれないが、時々シングルモードで起動して CUI 環境下でシステムをいじるような人にとってこれはかなり嬉しいし、さらに特に液晶モニタで DVI 接続していると余計に燃（萌）える（笑）。
一般的な情報は、vesafb.txt を参照して欲しい。僕の環境では以下のような感じの設定（menu.lst）（上は通常モード、下がシングルモード）：
kernel /boot/bzImage-2.6.15.4 root=/dev/hda6 ro vga=0x31B video=vesafb:ywrap,mtrr:3 kernel /boot/bzImage-2.6.15.4 root=/dev/hda6 ro vga=0x307 video=vesafb:ywrap,mtrr:3 single
実は、この設定でフレームバッファが mtrr を利用してライトコンバインモードで動作するようになるので、CUI 環境だけではなく、X-Window の GUI 環境にもその恩恵が波及するという効果も得られる。ライトコンバインは、VRAM への書込を通常とは違ってキャッシュして行うためにかなり高速化させることができる。X-Window 環境下で /proc/mtrr で確認すると、VRAM 用に割り当てられたメモリ番地が、ライトコンバインで読み書きする領域としてちゃんとマークされているのがわかる。
僕のマシンの NIC は Planex ENW-9501-F という 100Base-TX、FullDuplex のもの。いわゆる DEC 2114x チップを使っている（DEC 21140-AC）。Debian 3.2 (Etch) のインストール後のデフォルト状態では tulip ドライバが使われるが、やや不安定で、マシンを再起動した時に NIC がちゃんと再起動されていないらしく、ネットワークが不通になることがある（再び再起動するか、一度ちゃんと電源を切ってから起動する必要がある）。
tulip ドライバではなく同じ Tulip ファミリドライバの別のドライバである de4x5 の方を使うように、カーネルの再構成を行ってみた（カーネルの設定では「Tulip ファミリ」は選択する必要があるが、「tulip ドライバ」そのものは選択しないで「de4x5 ドライバ」だけを選択する）。そうして de4x5 ドライバが使われるようにしたら、tulip ドライバの時のような不具合が解消された。
実際に説明などを見ても、tulip ドライバは DEC 製の純粋な Tulip NIC 用のドライバであり、単に同じ 2114x チップを使った他社製の擬似 Tulip NIC の場合は、de4x5 ドライバの方を使うように指示されているので、これが正しいことになる。
いまだに ISA の SB AWE64 を使い続けている。ただ、カード自体が古いだけに、情報（Sound Blaster AWE 32/64 HOWTO）も多少古いまま放置されている気がする。Linux ではかつては OSS というサウンド関係のドライバがよく使われていたが、これはもう陳腐化して ALSA に置き換わる方向性にある。従って、カーネルの再構成時には、基本的に OSS はカテゴリごと省略してしまい、ALSA のカテゴリの中から選択する（ALSA のカテゴリの中の OSS との互換用の選択肢は選択してもいい）。
ファイルシステムはあまり複雑にしたくないので、原則 ext3 に絞っている。そんなわけでカーネル再構成の設定では、ext3 を除いては ext2 やほとんどの選択肢を無効にしている。ただし、FD や CD/DVD 等の外部メディア用の選択肢はモジュールとして選択している。
注意点としては（これは再構成時に説明が出る事項だが）、主となるファイルシステムはモジュールとしてではなく、静的にカーネルに組み込むべきだということ。つまり、ルートパーティションに用いるファイルシステムはモジュール化は避けるということである。実は、デフォルト設定では、すべてのファイルシステムがモジュール化されてしまう。なので、カーネル再構成時にはモジュールではなく静的なカーネル組込にするのを忘れないようにする。
それでも僕の場合、モジュール化していても特に問題は発生しなかったのだが、initrd を使って ramdisk で起動される形になっているからなのか、今の段階では僕の知識が足りないのでよくわからない。また、モジュールは一定時間使われないと自動的にアンロードされてしまうらしいが、ファイルシステムのモジュールもそうだとしたら、やはり、主ファイルシステムまでも特殊な事情がない限りわざわざモジュール化する事もないような気がする。
nfts-3g をインストールして使う。/etc/fstab に以下の行を追加して自動マウントするようにする：
/dev/hda4 /mnt/ntfs ntfs-3g locale=ja_JP.UTF-8,uid=1000 0 0
/mnt/ntfs はあらかじめ作成しておく。またこの例の場合は NTFS ドライブが /dev/hda4 の場合である。
以前は apt-get コマンドだったので /etc/apt/sources.list をいじったりする必要があったが、今では GUI の Synaptic があるので設定も楽になった。「設定＞リポジトリ」でミラーサイトの選択等を設定できる。
アプリケーションの追加のたびにディスクを挿入するのは面倒なので CD/DVD は Third-Party Software のタブで設定を無効化しておく。
《以上》