Linux関係で調べたりしたメモ。調べた当時の情報なので、改善されたり変更されたりしている可能性あり。
GentooのPortageでは、同じパッケージをインストールしても設定ファイルなどユーザが手を加えたファイルを保護するようになっている。保護対象となるのは基本的に設定ファイルで、環境変数CONFIG_PROTECTで定義される。この変数に含まれている場所であれば、上書きされるかどうか判断される。
パッケージがインストールされる時、ファイルがCONFIG_PROTECTのパスに含まれていれば、/var/lib/portage/configにそのファイルのmd5sumが記録される。つまり、パッケージで提供される初期ファイルのハッシュが記録される。
次に、何らかの理由で同じパッケージを再度インストールする場合、既に/var/lib/portage/configにそのファイルのハッシュが記録されているので、インストールしようとするファイルのmd5sumと記録されているハッシュを比較する。この場合、基本的には初期ファイルは同じ内容なので、ハッシュが一致するため既存のファイルを残し、新たなファイルは破棄される（何もしない:._cfg0000ファイルを造らない）。基本的に、というのはインストール時にファイルに乱数や時刻を取り込むようなものは、毎回ハッシュ値が変わるのでその都度._cfg0000ファイルが作成されるため、設定ファイルを上書きするかどうか判断しなければならない（dispach-confなど）。パッケージのバージョンが変わる場合には、保護されているファイルの初期内容が変更されることが多いため、更新処理を行わなければならないが、ファイルに変更が無い場合はそのまま既存のファイルが利用される。
整理すると、再インストールにしてもアップデートにしても、CONFIG_PROTECTで保護されているファイルは、パッケージをインストールする際の生のファイルが以前と変化したファイルについてのみ、既存のファイルが存在すれば、新ファイルを._cfg0000ファイルに一時待避させてユーザに判断を促す。
KDEのグラフィカルログインマネージャのキーボードレイアウトは、KDEの設定と連動しない。コンソールの設置もxorg.confの設置もうまく反映されないので、あまりスマートではないがKDMの起動スクリプトで無理矢理設定する。
/usr/share/config/kdm/Xsetup
setxkbmap -rules evdev -model jp106 -layout jp
setxkbmapコマンドでjp106レイアウトに変える。Gentooの場合、/usr/share/config/kdmはアップデート時に上書きされるので、アップデートするたびに確認する必要がある。CONFIG_PROTECTなどで保護するとよい。
一般的にはブートローダの「root=/dev/sda2」などとして指定するが、カーネルそのものにコンパイル時にパラメータが埋め込まれている。
この値を確認するためのコマンドがrdev。
rdev
ただし、Gentooのamd64ではutil-linuxパッケージから削除されたみたい。
ext4ファイルシステムドライバでext2/ext3をマウントできるように設定し、ext2/ext3ファイルシステムドライバを組み込まないと、rootファイルシステムのマウント時にext4ファイルシステムがうまくext4として認識されない場合がある1)。
カーネルの起動オプションに「rootfstype=ext4」パラメータを指定するとうまくファイルシステムタイプを認識する。
kernel /kernel-2.6.37-gentoo-r4 root=/dev/sda2 rootfstype=ext4
baselayout2およびOpenRCにアップデートすると、ファイルシステムのマウント状況がおかしいように見える。表面的な問題らしい。
具体的には、「/」に二重にマウントされているように見える。
rootfs on / type rootfs (rw) /dev/root on / type ext4 (rw,commit=0)
rootファイルシステムは、起動時に仮にマウントされfstabを読み込んでもう一度マウントし直す。その際、/proc/mounts、/etc/mtabにはマウントされた情報が記録される。この処理にバグ?があるようで、mountコマンドなどでマウント状況を表示した際に2重にマウントされているように見えるようだ。
OpenRCでは高速にシャットダウンする場合などに必要なものらしい。
設定を書く際に「=」の前後にスペースなどを入れない。「コマンドが見つからない」とエラーになる。
config_eth0="192.168.0.1/24"
起動時に警告が出るので以下の設定をコメントアウトを外し、値は空にしておく。
sys_init=""
リンクが壊れたシンボリックリンクを検索、削除するツール
app-misc/symlinks
OpenRCでは各種起動スクリプトを並列実行できるようだ。
rc_parallel="YES"
を設定すると依存関係に問題ないサービスが並列起動する。起動がかなり高速になるが推奨はされないようだ。
alsaの音量設定は、デフォルトでミュート状態となる。起動時に一定の音量にする場合は、以下の設定をおこなう。
音量の設定
alsamixer
適当な音量に設定する。その後、設定を保存する。
alsactl store
保存すると、/etc/asound.stateに設定が書き込まれる。
起動時に設定を復元するように、alsasoundサービスが起動するようにする。
rc-update add alsasound default
カーネルモジュールにパラメータを渡す方法。
それぞれのモジュールは、module_param()関数でパラメータを受け取って内部動作を制御できるようになっている。 この関数にパラメータを渡したい場合、動的モジュールになっていればmodprobeでロードする際に、オプションをつけてやれば良い。起動時に設定するなら、/etc/modprobe.d/等で設定しておく。
カーネルに静的に組み込んでいる場合は、起動時にカーネルのコマンドラインオプションで渡してやる。
モジュールの情報は、
/sys/module/MODULE名/parameters/PARAM名
にあるので、ここでecho等で値を書き換えてもよいが、起動時にしか設定できないものもある。その場合は、ブートローダでカーネルにパラメータを渡せばよい。その場合は、/boot/grub/grub.confのkernel行に
MODULE名.PARAM名=VALUE
という形式でカーネルに引数を与えてやる。
GentooのUSE flagを管理するのに、これまでeuseを使っていた。ただし、これは/etc/portage/make.confのグローバルなUSE flagしか管理できない。パッケージごとの指定は、エディタでいちいち/etc/portage/package.useを書き換えていた。面倒だと思いつつ、それほど頻繁に行う作業でもないので放置していたが、便利なツールがあることをたまたま発見した。
インストール
emerge -av flaggie
使い方は、flaggieコマンドに続けて、パッケージ名、[+/-]フラグとする。「+」で追加、「-」で除去。パッケージを指定しなければ、グローバル（make.conf)に設定される。
flggie gcc +lto
GentooでApache用のPHP設定ファイルは、通常/etc/php/apache2-php<ver.>/php.iniにある。この設定ファイルの他に、
--with-config-file-scan-dir=/etc/php/apache2-php5.5/ext-active
がビルド時に設定されているので、php.iniファイルがあるディレクトリのext-activeディレクトリの.iniファイルも読み込まれる。
USE flagなどでエクステンションを追加すると、その設定ファイルはここに格納されるので、有効/無効にする際にはチェックする必要がある。また、モジュールの読み込みはこちらで、設定自体はphp.iniにあることもあるので、両方を確認する。
Intelの82574Lチップを積んだPCIeボードで頻繁にエラーが出る問題の対処方法。
チップの問題ではなく、e1000ドライバの問題かもしれない。
以下の様なエラーが頻出して、その都度ネットワークが再起動してしまう。
Mar 24 15:00:18 [kernel] e1000e 0000:00:19.0 eth1: Detected Hardware Unit Hang: Mar 24 15:00:18 [kernel] TDH <7e> Mar 24 15:00:18 [kernel] TDT <8e> Mar 24 15:00:18 [kernel] next_to_use <8e> Mar 24 15:00:18 [kernel] next_to_clean <7e> Mar 24 15:00:18 [kernel] buffer_info[next_to_clean]: Mar 24 15:00:18 [kernel] time_stamp <1001afbef> Mar 24 15:00:18 [kernel] next_to_watch <7e> Mar 24 15:00:18 [kernel] jiffies <1001b04d4> Mar 24 15:00:18 [kernel] next_to_watch.status <0> Mar 24 15:00:18 [kernel] MAC Status <40080083> Mar 24 15:00:18 [kernel] PHY Status <796d> Mar 24 15:00:18 [kernel] PHY 1000BASE-T Status <3800> Mar 24 15:00:18 [kernel] PHY Extended Status <3000> Mar 24 15:00:18 [kernel] PCI Status <10> Mar 24 15:00:20 [kernel] e1000e 0000:00:19.0 eth1: Detected Hardware Unit Hang: Mar 24 15:00:20 [kernel] TDH <7e> Mar 24 15:00:20 [kernel] TDT <8e> Mar 24 15:00:20 [kernel] next_to_use <8e> Mar 24 15:00:20 [kernel] next_to_clean <7e> Mar 24 15:00:20 [kernel] buffer_info[next_to_clean]: Mar 24 15:00:20 [kernel] time_stamp <1001afbef> Mar 24 15:00:20 [kernel] next_to_watch <7e> Mar 24 15:00:20 [kernel] jiffies <1001b0ca4> Mar 24 15:00:20 [kernel] next_to_watch.status <0> Mar 24 15:00:20 [kernel] MAC Status <40080083> Mar 24 15:00:20 [kernel] PHY Status <796d> Mar 24 15:00:20 [kernel] PHY 1000BASE-T Status <3800> Mar 24 15:00:20 [kernel] PHY Extended Status <3000> Mar 24 15:00:20 [kernel] PCI Status <10>
以下の対策をして「収まった」ように見えたが、再発したので追記。
以前の対策を元に戻して、今回はNICのTSOをオフにする。e1000ドライバでTSOが有効になっていると問題が生じることがあるらしい。TSOはパケットの一部の処理をCPUからNICに任せる機能で、高負荷時に問題がある場合があるという。
ethtool -K outside rx off tx off tso off
再起動で元に戻るので、起動時にコマンドを実行するようにしておく。
カーネルに以下のパラメータを渡すと、とりあえず収まった（それ以上追求していない）。
"e1000e.IntMode=1,1 e1000e.InterruptThrottleRate=10000,10000"
e1000eドライバに、何らかのパラメータを渡しているのだが、内容は未調査。 gentooでgrub2ならば、/etc/default/grubのGRUB_CMDLINE_LINUX_DEFAULTに追加し、grub.cfgを再構築する。
ドライバをIntelから持ってくる必要はない。カーネルに同梱されているものでOKだった。