Xが立ち上がらない

Debianのsidでの出来事です。

apt-get upgrade で保留されているパッケージが多かったので
apt-get dist-upgrade したらXが立ち上がらなくなりました。Oh headache.

xorg-video-abi-18がないと言われます。
でもそんなパッケージありません。

ググって調べてみると、xorg-video-abi-18は、xserver-xorg-coreの中にあるようです。
はて?

なにが起こっているのでしょう?
xorg-video-abiは-18と-19があって、x86版は-18でなければなりません。
しかし、なぜか-19の方しか出てきません。

けっ。xserver-xorg-coreが、-19になっていて、-18を必要とするx86のビデオドライバが全滅ということのようです。
xserver-xorg-coreを古いものに戻せば直るでしょうが…。
どうすんだよ、これ!?


前回、Xが立ち上がらなくなったときは、Debian snapshotからパッケージを拾ってきて dpkg -i しましたが、今回は、apt で直してみます。
というのも、何とか直らないかと、testingを入れてみたり、X関連パッケージを削除したりと、多くのパッケージがわけの分からない状態になってしまったからです(笑)。

では、順番に。

1. 混乱してしまったパッケージを削除する
   snapshotからaptで入れ直すので、まず、Xサーバ関連を削除します。なお、設定は残しておいたほうが良さそうなので、purgeはしません。
   　　# apt-get remove xserver-xorg xserver-xorg-core xserver-xorg-video-all fglrx
2. いつの時点まで戻ればよいかを探す
   upgradeした後でもちゃんと動いていたと記憶にある日の数日前くらいを考えます。
   正確には、snapshotのページの左ペインの「binary packages:」の一覧から、リンクをたどって個々のパッケージのページまでいけば、バージョン一覧が出てきますので、それをたどれば、アーキテクチャ、日付などが表示されます。
   今回は、5月1日でよさそうです。
3. レポジトリの切り替え
   /etc/apt/sources.list と /etc/apt/sources.list.d/ を横へ避けます。
   以下の内容の/etc/apt/sources.listを作成します。5月1日なので、20150501です。
   　　deb http://snapshot.debian.org/archive/debian/20150501/ unstable main contrib non-free
4. オプションをつけて update
   snapshotのページにあるように、オプションをつけてupdateします。
   　　# apt-get -o Acquire::Check-Valid-Until=false update
5. 削除したパッケージを入れる
   　　# apt-get install xserver-xorg xserver-xorg-core xserver-xorg-video-all
6. 再起動してチェック
   再起動してチェックします。
   　　# reboot
7. 問題なければ、レポジトリを戻す
   横へ避けた /etc/apt/sources.list と /etc/apt/sources.list.d/ を元に戻します。

以上で直りました。
ここまで3日かかりました…。はぁ。

RaspberryPiをBeagleBoneBlackに置き換える

BeagleBoneBlackはRev.A6のころに買っていて、あれこれと予定していたのですが、設置までは至りませんでした。
BeagleBonleBlackのCPUには、ハードウェアの暗号化エンジンが載っており、これがデフォルトで使えそうなので、試してみました。
以前、RaspberryPiで、無線LAN間をOpenVPNのサーバ・クライアントで結ぶものを作りました。残念ながら非力なRaspberryPiでは、10Mbps程度の速度しか出ませんでしたが、ハードウェアの暗号化エンジンを使ってどれだけ速くなるでしょうか?

…と思ったのですが，結論からいいますと、ハードウェアの暗号化エンジンを使っているのかどうかも分からないような結果となりました。これは、元々opensslのスピード測定部分にバグがあり、測定時間が3秒どころか0.0何秒になってしまい、測定結果が不正確すぎる値しかでてこない、と言う問題がありました(現在は直っています)。ネット上にある多くの測定結果は、そのときのバグありバージョンで測定されているものですから、元々の「本当の速度」が分からないのでした。


では、順番に。
まず、予備調査として、openssl speedコマンドでそれぞれ速度を測ってみました。

BeagleBoneBlackのwheezyのプレビルドのSDイメージ(stable; console版)を使いました。BegleBoardDebian(http://elinux.org/BeagleBoardDebian)からです。
カーネルは、Linux 3.8.13-bone67 #1 でした。
openssl speed aes-256-cbc は以下の値です。

$ openssl speed aes-256-cbc
Doing aes-256 cbc for 3s on 16 size blocks: 4933445 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 64 size blocks: 1425060 aes-256 cbc's in 2.99s
Doing aes-256 cbc for 3s on 256 size blocks: 373241 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 1024 size blocks: 94438 aes-256 cbc's in 2.99s
Doing aes-256 cbc for 3s on 8192 size blocks: 11855 aes-256 cbc's in 3.00s
OpenSSL 1.0.1e 11 Feb 2013
built on: Wed Oct 15 18:31:51 UTC 2014
options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr)
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DGHASH_ASM
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256 cbc      26311.71k    30502.96k    31849.90k    32342.65k    32372.05k

RaspberryPiのときは、以下の値で、BBBは2倍速いです。

# openssl speed aes-256-cbc
Doing aes-256 cbc for 3s on 16 size blocks: 2262500 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 64 size blocks: 682967 aes-256 cbc's in 2.98s
Doing aes-256 cbc for 3s on 256 size blocks: 179207 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 1024 size blocks: 45360 aes-256 cbc's in 2.99s
Doing aes-256 cbc for 3s on 8192 size blocks: 5680 aes-256 cbc's in 2.98s
OpenSSL 1.0.1c 10 May 2012
built on: Thu Nov  8 03:42:28 UTC 2012
options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr)
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DGHASH_ASM
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256 cbc      12066.67k    14667.75k    15292.33k    15534.66k    15614.28k

さて、BBBの、この約30000kという値、ハードウェアの暗号化エンジンを使っているのでしょうか? ここで、opensslのスピード測定のバグの問題にぶつかってしまうのです。たとえば、次のページ
　　http://processors.wiki.ti.com/index.php/Sitara_Device_Crypto_Performance_Comparison
なら、ハードウェアの暗号化エンジンなしで約8000kですが、実はRaspberryPi(15000k)よりも遅いです。半分の速度しか出ていません。これはどうしたことでしょう? CPUのクロック差からして、これはgccやOSのバージョンによる差と考えなければなりません。となると、gccやOSのバージョンが上がると、2〜4倍程度は速くなる可能性がある、ということでしょうか? それも十分考えられます。
ハードウェアの暗号化エンジンを使った場合は、opensslのスピード測定のバグの問題のため、不正確な値しかでていません。なので、実際の速度がどれだけなのか、まったく分かりません。困ったものです。

しかしながら、現行のRaspberryPiの2倍の速度というのは、それなりに魅力的です。なので、ともかく一度BeagleBoneBlackで置き換えてしまいましょう。昨年大問題となったopensslのheartbleed脆弱性のこともありますし。(ただ、このopenvpnTLS-Authを使っていますので問題ありませんでした。攻撃者にTLS-Authキーが知られない限りheartbleedバグを利用することができませんので。)

基本的な方針はRaspberryPiのときと同じです。そして、発生した問題も同じでした(他にもありますが)。

rootfsをROM化するために、fsprotectをapt-getしましたが、相変わらずaufsが使えないため、fsprotectが動作しません。x86版ならサポートされているのに、armはダメです。でも、「必要性」から言えば，PCのx86よりも、小型組込み用のarmのほうが比べ物にならないくらい「必要」としているのですがね。
fsprotectを諦めて、やはり、unionfsを使うことになります。

それから、USB-Etherアダプタが"ethX"じゃなくて、"rename3"になっていました。これはASIXのチップを使ったものです。
"rename3"のまま使用しても構わなかったのですが、まぁ、ちょっと直しましょう。
/etc/udev/rules.d/70-...が悪いのは分かっていますが、どう書くのでしたっけか?
ググってみますと(rename3 ASIX)と同じ目にあわされている人が何人かいて、結局、MACアドレスでeth1にするように記述しました。

# USB device ASIX (AX88x72A)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="xx:yy:zz:uu:vv:ww", NAME="eth1"

その他、openvpnなどの設定は、RaspberryPiでの設定をコピーしてインストールします。これらは変更なしです。

さて、準備はできましたので、前回と同じくunionfsの起動スクリプトを入れて起動しました。…ハングアップしました。
調べると、bin〜をbindマウントして、古いのをunmountしたあたりです。

問題を順に対処していきましょう。

• ifconfig -aしても、ethが出てきません
  他に何かしたら、D-Busかなにかがないというエラーがでました。
  /sysや/procを「新たにmount」するのはもはやダメらしいです。以前mountしたfsと関係なく、その時点で新しいfsがマウントされてしまうようです。セキュリティのためではないかと思います。よって、以前のものをbindマウントする必要があります。
  　　mount -t proc proc /proc -> mount --bind 以前 /proc など
  
  
• シリアルコンソールからログアウトすると、シリアルがハングアップします(正確には，gettyが再実行されません)
  明らかに、rootfsを移動したことに問題があるわけですが、どこに問題があったのかわかりませんでした。
  でも、kill -1 1すればgettyが動くことがわかったのですが、…
  結局，直せませんでした。systemdの設定や構造は未だ理解不能です。(/etc/inittabはsystemdでも解釈されるのか?、とか)
  とりあえず、rootの.bash_logoutに
    ( sleep 3; kill -1 1 ) &
  を追加。…、嫌になるくらいひどすぎる回避策ですが、この場合は、動くことが大事であって、無理にでも動けばOKです。
  
  
• カーネル起動パラメータからquietを削除すると、コンソールがハングします
  これもひょっとするとkill -1 1で直るのかもしれません(試していません)が、いずれにしても原因が不明です。messagesの出力のためにconsoleがオープンされたままrootが移動するから?でしょうか。
  

ともあれ、これでなんとか動き始めました。が、さらに調整が必要でした。

• もし、sshサーバを動かしているなら、一度再起動したあと、元々のrootfsの /etc/ssh/ssh.regenerate を削除しましょう。
  でないと、毎回起動時にhostkeyが再生成されて、「前回と違うhostkeyだ」と言われてしまいます。
  　　/bin/rm -f etc/ssh/ssh.regenerate
  

SDが出来上がったので，PCにSDをもってきて、PCのgpartedでパーティションサイズを変更します。保存やコピーのサイズや時間の節約のためです。
rootfsは400MB未満というコンパクトさ。rootfsとして、1GBもあれば十分でしょう。

イメージファイルとして、バックアップをとっておきましょう。

dd if=/dev/sdX of=SD.img count=YYYYY

YYYYYは、fdiskなどを用いて、(使用しているパーティションの最後のセクタ番号+100)程度を指定します。

BeagleBoneBlackは、eMMCがついています。SDの内容をeMMCに書き込みます。rootfsをROM化してあるので、SD同様、心配無用です。
このバージョンのBBBのDebianでは、eMMCへの書き込みはuEnv.txtを1行修正するだけです。それで起動すると、書き込まれます。終了は、コンソールで確認するか、LED4つが全部点灯するかでわかります。SDを抜いて、電源を入れ直します。電源を入れ直さなければならない理由はCPUがそうなっているからです。BBBのCPUは、リセットではsysconfig(起動デバイス順序)を読み直しません。電源on時のみsysconfigを読み直すので、リセットすると、SDから起動しようとしてSDがないのでコンソールからの起動になり、eMMCを読みにいきません。

で、今まで設置していたRaspberryPiと入れ替えました(相手側はRaspberryPiのままです)。起動したら、そのまま問題なく動作しました。
あとは、同様にして無線ルータの相手側もBeagleBoneBlackに入れ替えます。

これで、当初の目的は達成できました。
実際に、openvpnと無線LANを通してファイル転送速度を調べると、

RaspberryPi        1.1MB/s (以前の結果)
BeagleBoneBlack    2.5MB/s

となり、約2.3倍の速度が出ていました。


さて、opensslのスピードの続きです。
　　http://datko.net/2014/03/21/bbb_upgrade_3_13/
の情報によると、kernel 3.13以降はHW暗号エンジンがデフォルトらしいです。…さっきインストールした3.8.18って何? 古すぎっ。
で、そこにあるようにkernel updateを、ついでに、RCじゃない最新版まで引き上げましょう。

wget https://rcn-ee.net/deb/wheezy-armhf/v3.18.2-bone1/install-me.sh
chmod +x install-me.sh
./install-me.sh

したら、

Error: this script is no longer supported for [repos.rcn-ee.net]
Please use:
cd /opt/script/tools/
git pull
sudo ./update_kernel.sh
or:
sudo ./update_kernel.sh --kernel v3.x.x-x

ですと。BeagleBoneBlackの情報はあまりにも早く、むしろ早すぎるくらいに、情報が古くなります。私がここに書いたものも、もう既に古くなっていることでしょう。
さて、正しいkernelのアップデートはどうするかというと、DebianなんだからDebian流にやればよいのです。

apt-cache search linux-image

ここに3.19のRCまでありました。でも、念のため、3.18.2を入れます。

apt-get install linux-image-3.18.2-bone1

再起動して、早速測定。

openssl speed aes-256-cbc
Doing aes-256 cbc for 3s on 16 size blocks: 4963187 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 64 size blocks: 1432710 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 256 size blocks: 375715 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 1024 size blocks: 95073 aes-256 cbc's in 2.99s
Doing aes-256 cbc for 3s on 8192 size blocks: 11910 aes-256 cbc's in 3.00s
OpenSSL 1.0.1e 11 Feb 2013
built on: Thu Jan  8 22:02:29 UTC 2015
options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr)
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa, --noexecstack -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DGHASH_ASM
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256 cbc      26470.33k    30564.48k    32061.01k    32560.12k    32522.24k

全然変わってません。
なので、結局、ハードウェアの暗号化エンジンを使っているのかどうかわかりませんでした。

タグ：RaspberryPi BeagleBone BeagleBoneBlack

FT231X USB UART

秋月にあるUSB-シリアル(3.3V)の変換モジュール(基板)に新しいものが加わりました。FIFOが増えて、値段も安くなっていました。 早速買って試してみました。

linux 3.x(sid)では問題なくttyUSB*になったのに、linux 2.6.x(squeeze; old stable)では/dev/ttyUSB*がでてきません。

接続すると、dmesgで以下のように、ドライバはちゃんと認識しているようです。

[ 4259.562407] usb 3-6.3: new full speed USB device using ehci_hcd and address 7
[ 4259.669450] usb 3-6.3: New USB device found, idVendor=0403, idProduct=6015
[ 4259.669453] usb 3-6.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 4259.669456] usb 3-6.3: Product: FT231X USB UART
[ 4259.669458] usb 3-6.3: Manufacturer: FTDI
[ 4259.669460] usb 3-6.3: SerialNumber: xxxxxxxx
[ 4259.669541] usb 3-6.3: configuration #1 chosen from 1 choice

ググってみると、FTDI製のドライバを入れるのがよいのかと思われたのですが、はて? 認識はされていますよ?
となると、ドライバまでは動作していて、単に/devに出てこないだけでは?
なら、問題は/etc/udev/rules.d/でしょう。
beagleboneの中身を参考に以下を追加しました。

/etc/udev/rules.d/73-ft231x.rules
ACTION=="add", SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_interface", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6015",  DRIVER=="", RUN+="/sbin/modprobe -b ftdi_sio"
ACTION=="add", SUBSYSTEM=="drivers", ENV{DEVPATH}=="/bus/usb-serial/drivers/ftdi_sio", ATTR{new_id}="0403 6015"

で、接続し直すと、以下のとおり、認識されました。ただし、FT231X(FT-X)でなくFT232RLとしてですが(本来なら、FT-Xとして認識されます)。一応、通信もできました。
が、このことからすると、本当はドライバを入れ替えたほうがよいのかもしれません。

[ 4436.130491] usb 3-6.4: new full speed USB device using ehci_hcd and address 8
[ 4436.229414] usb 3-6.4: New USB device found, idVendor=0403, idProduct=6015
[ 4436.229417] usb 3-6.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 4436.229419] usb 3-6.4: Product: FT231X USB UART
[ 4436.229421] usb 3-6.4: Manufacturer: FTDI
[ 4436.229423] usb 3-6.4: SerialNumber: xxxxxxxx
[ 4436.229505] usb 3-6.4: configuration #1 chosen from 1 choice
[ 4436.287764] usbcore: registered new interface driver usbserial
[ 4436.287830] USB Serial support registered for generic
[ 4436.287864] usbcore: registered new interface driver usbserial_generic
[ 4436.287866] usbserial: USB Serial Driver core
[ 4436.291459] USB Serial support registered for FTDI USB Serial Device
[ 4436.291565] usbcore: registered new interface driver ftdi_sio
[ 4436.291567] ftdi_sio: v1.5.0:USB FTDI Serial Converters Driver
[ 4436.291763] ftdi_sio 3-6.4:1.0: FTDI USB Serial Device converter detected
[ 4436.291790] usb 3-6.4: Detected FT232RL
[ 4436.291793] usb 3-6.4: Number of endpoints 2
[ 4436.291795] usb 3-6.4: Endpoint 1 MaxPacketSize 64
[ 4436.291797] usb 3-6.4: Endpoint 2 MaxPacketSize 64
[ 4436.291798] usb 3-6.4: Setting MaxPacketSize 64
[ 4436.291991] usb 3-6.4: FTDI USB Serial Device converter now attached to ttyUSB0

正しく認識されるsidでは、以下のようにFT-Xとなっています。

[ 3389.570940] usb 6-1: Detected FT-X

cpコマンドの-Pと--parents

cpコマンドに、確か、ツリーでなく単一ファイルの場合でも

ソース同様のディレクトリを作ってコピーする

という機能があったはずだ、と思って探しました。

cp そのオプション a/b/c existing_dir

とすると、 existing_dir/a/b/c が作られるというオプションです。

で、man cpすると、以下のとおり。

$ man cp
       -P, --parents
              コピー先のファイル名の作り方を  「コピー先ディレクトリにスラッシュ (/) とコピー元ファイルの名前を加える」 とする。 cpの最後の引き数は既に存在するディレクトリでなければならない。 たとえば、
              cp --parents a/b/c existing_dir
              というコマンドは `a/b/c'というファイルを `existing_dir/a/b/c' に (途中のディレクトリがない場合はそれも作って) コピーする。

GNU fileutils 4.1           18 June 2002                       CP(1)

ところが、cp -P しても、この日本語のman cpにあるような動作をしてくれません。
そんなバカな!? cpコマンドのオプションに「こんなあからさまなバグ」があるという確率は1%以下でしょう。
となると、「日本語のman cpにバグがある」という確率が99%です。

$ LANG=C man cp
       -P, --no-dereference
              never follow symbolic links in SOURCE
       --parents
              use full source file name under DIRECTORY

GNU coreutils 8.5            April 2010                        CP(1)

なるほど。英語のman cpによると、-Pと--parentsは「まったく別物」ですね。
manの日付から推測すると、2002年当時は-Pと--parentが同一機能だったのですが、その後のある時点から、-Pと--parentが「別機能」になった、ということのようです。

その「英断」は、ちょっと疑問ですね。
lsの「混乱したオプション」や、topの「BSD形式、sysV形式オプション」などが、どうして今の今まで残っているのか、なぜ変えられなかったのかを考えれば、すぐわかることでしょう。

起動後毎回fsckが実行される

以前、「ext3のリカバリ後に常にfsckを要求される」ということでその対策をしました。

今度は先ほどの修正を入れていない別のマシンで「起動後にext4で常にfsckを要求される」ということが起こりました。

… もういいや、わかった、あんたの勝ちだ。RTCを、ロカールタイムじゃなくてUTCに変えてやるよ、この野郎。

というわけで、まず、念のため、GPartedLiveでfsckをかけて(もちろん、エラーはありません)、起動し直します。
その後、rootで

# hwclock -w -u

で、UTCで書き込みます。/etc/adjtimeの中の1行が、LOCALからUTCに書き換わったはずです。
起動し直して確認します。

不本意ですが、これで問題は消えたようです。

HDDが何度もremountされる

数ヶ月くらい前から、次のようなメッセージがでて、何度もrootfs (sda5)がremountされます。
ひどいときは、うまくリマウントできずに、rootfsがReadOnlyになってしまったこともあります。

[   44.800073] NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter.
[   47.657573] EXT4-fs (sda5): re-mounted. Opts: errors=remount-ro,data=ordered,commit=0
[  100.544381] EXT4-fs (sda5): re-mounted. Opts: errors=remount-ro,data=ordered,commit=600
[  109.273810] NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter.
[  109.520745] EXT4-fs (sda5): re-mounted. Opts: errors=remount-ro,data=ordered,commit=0
[  171.059881] EXT4-fs (sda5): re-mounted. Opts: errors=remount-ro,data=ordered,commit=600
[  179.703594] NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter.
[  179.951929] EXT4-fs (sda5): re-mounted. Opts: errors=remount-ro,data=ordered,commit=0
[  217.335418] EXT4-fs (sda5): re-mounted. Opts: errors=remount-ro,data=ordered,commit=600

HDDがおかしいのかと思って別のメーカーのものに交換したのですが、同じエラーが出つづけます。

EXT4-fs: re-mounted. Opts: errors=remount-ro,data=ordered,commit=0

でググってみても、意味のない情報ばかりでした。ひょっとして

NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter.

が関係あるかも?と思って調べましたが、それは単にそのメッセージを出さないように、NMI watchdogを停止するだけのものでした。
ふと、psでプロセスをみると、

/bin/sh /usr/sbin/laptop_mode auto

がたくさん走っています。なんじゃこりゃ。それらのプロセスをkillして

laptop_mode status

してみると、

Mounts:
   /dev/sda5 on / type ext3 (rw,relatime,errors=remount-ro,data=ordered)

と、先頭に表示されています。ははーん、なるほど。どうやら

NMI watchdog発生 -> laptop_mode再起動 -> なにかエラーで止まってる -> NMI watchdog発生 -> laptop_mode再起動 -> ...

のようです。

ほほぅ。となると、もともとも原因は、このノートPCが古くて、バッテリーがダメになっていることのようです。バッテリーを買おうにも、このメーカーはモデルチェンジが激しくてすぐにPCもサプライも廃品にしてしまいます。そのため、バッテリーを交換しなければならない時期には、すでにバッテリーの入手ができません。これで満足度がどうとか言われてもなー、という感じです…。仕方ないので互換バッテリーを買ったのですが、半年程度でダメになり、交換してもらってもやはり同じく、ダメになりました。結局、ノートPCは、AC必須になってしまいました。持ち出すにもACアダプタが必須です。PCの寿命って、このように本体よりも周辺で決められるのです。必要なタイプのRAMがもう売ってないとか、容量やインターフェースの問題でHDDがつながらないとか、…。

話が逸れましたが、対策としては、

• NMI watchdogを止める
  https://bbs.archlinux.org/viewtopic.php?id=159733
  に、何通りかの方法があります。が、私の所ではNMI watchdogを止めることができませんでした。
• laptop_modeを止める
  パッケージを削除するか、起動(/etc/init.d/laptop_mode)を止めるか、など、いくつかの方法が考えられます。私はこの方法をとりました。

が考えられますが、ほんとうは

• バッテリーを交換する

が正しいのです。ただ、その対策は今や不可能です。

仮想ディスクを圧縮して分割する

もらった仮想環境のディスクイメージ(debian)が、5GB強もありました。
まず、ファイルサイズが大きすぎて、DOSフォーマットされたUSBメモリに書き込めません。
それに、仮想環境内で作業ファイルを削除したところ、実際の使用量は1GB程度少なく、4GBを下回っているようです。

仮想ディスクを圧縮してみましょう。そして、仮想ディスクを「2GBごとに分割したタイプ」に変更しましょう。

まず圧縮ですが、
VMwareでは、VMware toolsをインストールすれば

vmware-toolbox-cmd disk shrink /

で圧縮できたはずです。が、うまくVMware toolsがインストールできませんでした。

ならば、VirtualBoxのツールでなんとかしましょう。しかも、VirtualBoxを起動することなしに、です。
VirtualBoxのツールであるvboxmanageは機能が豊富で、いろいろな仮想ディスクイメージの操作ができます。これを使います。

しかしながら、VirtualBoxのツールでは、直接仮想ディスクイメージを圧縮する方法は提供されていないようです。一度、未使用領域を0クリアする必要があり、少々手順が煩雑です。

ということで、以下は、その備忘録です。

流れとしては、

1. 仮想ディスクをRAWイメージに変換する
2. RAWイメージ内の各パーティションをマウントして、未使用領域を0クリアする
3. RAWイメージを2GBごとに分割したタイプに変換する(このときに圧縮される)

となります。


1. 仮想ディスクをRAWイメージに変換する

次のコマンドを使います。infileには、元の仮想ディスクイメージのファイルを指定します。

vboxmanage clonehd infile outfile.raw --format RAW

ただし、VirtualBoxを使っている場合には、もし、infileと同じUUIDの仮想システムを登録していたら、「同じUUIDがすでにある」と言われて実行できません。この場合には、

vboxmanage list hdds

で、登録している仮想システムのUUIDをチェックします。必要ならば、同一のUUIDを持つ仮想システムを削除するなどで対応します。

できたRAWイメージを確認します。

file outfile.raw

すると、まさにhddのrawイメージになっているのが確認できるでしょう。

次に、パーティションを確認します。

fdisk -lu outfile.raw

正しくパーティションが表示されていればOKです。


2. RAWイメージ内の各パーティションをマウントして、未使用領域を0クリアする

以下は、losetupを使う方法ですが、kpartxを使ったほうが簡単そうです(実際に試したわけではありません)。

直接mountする方法もあります。

mount outfile.raw /mnt -o loop,offset=オフセットバイト

しかし、ここでは安全のため、それを手動で行ないます。
まず、マウントしようとするパーティションをloopデバイスに割り当てます。

losetup /dev/loop0 outfile.raw -o オフセットバイト

ここで、loop0は未使用のループデバイスを指定します。
また、オフセットバイトは、マウントしようとしているパーティションが 2048(セクタ)からなら、2048*512=1048576です。

割り当てができれば、

file -s /dev/loop0

として、マウントしようとしている目的のファイルシステムであることを確認します。
そして、念のため、ファイルシステムをチェックしたほうがよいでしょう。

fsck -f /dev/loop0

異常がなければ、マウントします。

mount /dev/loop0 /mnt

マウントしたら、未使用領域をゼロクリアします。bsは指定しないほうがよいです。

dd if=/dev/zero of=/mnt/.zero.fill bs=4k

パーティションを埋め尽くしたらエラーで終了しますので、それまで待ちます。

ディスクへちゃんと書き込んだあと、ゼロクリアに使用したファイルを削除します。

sync; sync; sync
rm /mnt/.zero.fill

マウントを解除し、ループデバイスへの割り当てを解除します。

umount /mnt
losetup -d /dev/loop0

3. RAWイメージを2GBごとに分割したタイプに変換する(このときに圧縮される)

次のコマンドを使います。分割(2GBごとに)の指定もします。

vboxmanage convertfromraw outfile.raw outfile.vmdk --format VMDK --variant Split2G

.vmdkは圧縮されたファイルになります。

最後に、出来上がったファイルが問題ないか、VitrualBoxなどで新しい仮想マシンを作ってHDDとして指定して、確認します。

xfce上のKateのメニューフォントが異常

1週間ほど前のことです。
急にKate テキストエディタのメニューが筆記体の小さな文字に切り替わってしまいました。

 

あー、そういえば、apt-get upgradeしたっけ…　あーあ。


今は、xfceを使っています。GNOMEは「捨てました」。理由は簡単です。「立ち上がらなくなったから」。
何か変です、って言われても、とにかく立ち上がるだけはしてくれないと、何もできないんですがね。
以前も同じトラブルがあって、そのときは、ずーっと追っていったのですが、もうそんな「無駄」な時間はとれません。xfceに乗り換えるほうが早いのですから。

で、GNOME2時代にずーと使っていたgeditは? というと、実はこいつもはっきり言って使えねー奴で、だましだまし使っていたんですが、Kateというのを見つけてそっちに乗り換えたのです。geditの何が悪いって、文字のエンコーディングで誤りを見つけると絶対に開けない、ということです。viみたいにユーザの責任で「無理やり開く」のは、できて当然と思っていたのですが、そうではないようです。nkfを2回使って直すのも面倒ですし(必ず直るわけでもないですし)、他のテキストエディタ、Kateに乗り換えました。

GNOME3は言うに及ばず、初期のころから、geditやnautilusなどの「問題が多すぎるプログラム群」が気になって、いくつかは自分で「直していた」のですが、もういいでしょう。他のマネージャ、xfceに乗り換えました。


で、今日(1週間前)、立ち上げると、急にメニューが筆記体の小さな文字に切り替わってしまいました。Kateだけ。
あぁ、KateはKDEのアプリだから、KDEの何かがアップデートされて、フォントの設定を初期化しやがったんだな、aptさんよ、と思い、KDE System Settingの中で、フォント設定を探して(筆記体の小さな文字だから、読みにくくて読みにくくて、一瞬、KDEのフォントメニューから普段使う1つを除いて全部削除してやろうかと思ったくらいです)、VL Pゴシックに設定しました。
が、変わりません。Xを再起動しても変わりません。あれ?

どうしたものか…と思っていたとき目に止まったのが、Qt4設定です。あぁ、こっちですね。早速開いて、フォントの設定を変えます。あれれ、ApplyもOKボタンもないんだけど…。メニューの中のファイルの「保存」でした。なんじゃこりゃ。直感的じゃないですねー。ちゃんとヒューマンインターフェースガイドラインを読んで、再考をお願いしたいです。

Haswell i5マシン組立て

安く、かつ、適度な性能を、を目標にマシンを組み立てることにしました。マシンは、主にサーバ用途で、運用時にはディスプレイは接続しません。
CPU、マザーボード、メモリ、電源、ファンを新規購入し、ケースとHDDは再利用します。
また、今回は、通販で品揃えとし、さらに、送料と受け取りの関係で、可能なら1店だけで揃えます。

まず、どんなマシンにするかを考えます。OSはlinux (Debian)です。

• CPU 4コア〜
• メモリ 4GB〜
• 大きめのCPUクーラー (メンテナンスフリーとするため)

それから、

• マザー 特にこだわらず
• 電源 問題なさそうなもの

という感じです。メモリは、今回の用途では4GBでも十分です。価格次第というところでしょう。
CPUの種類を決めたら、他が自動的に決まってきそうです。

まず、CPUの選定です。
AMDは選択肢にはありません。私の用途ではFX-8300が大ハズレで、それ以外に使ったことのあるAMDもやはりどれも「私の用途では遅い」ためです。Intelとなると、XeonはゴツすぎでCeleronとi3は非力すぎです。i5かi7かの選択ですが、実際にi7を使った場合の性能はというと、私の用途では、実質4.3コア程度の性能しかありません。よって、i7とi5の性能差(0.3コア分)が、その価格差に見合うものか?という判断になります。つまり、1割未満の価格差ならば検討の余地があるわけですが…　現在の価格差は論外ですね。
ということで、CPUはi5(4コア)となりました。さて、IvyかHaswellか、ですが、消費電力も性能も価格差も目立った違いはありません。しかしながら、大問題が。i5は「入手可能」なものが限られているのでした。Ivyはかなり入手が難しくなっています。
ということで、「入手可能」なi5から選ぶこことにします。さて、クロックはというと、Intelではオーバークロックの必要性も低いので、オーバークロックなしでクロックの高いもの、となります。
ということで、i5-4670に(仮)決定です。

次にマザーボードです。
一番安いものからチェックします。...　気になったのは、RAMスロットが2つしかない、PCI-eが2つしかない、ですが、今回の用途では特に問題ありません。PCI-eは、せいぜいネットワークボードを追加する程度でしょうから。
ということで、MSI H81M-P33を選択し、この時点で、CPUが(仮)決定から、決定となりました。

次はメモリです。
CPUで速いものを選んだから、メモリも速いほうがいいかなと思ってチェックすると…　4GB(2GBx2)は売り切れでした。容量と価格差を考えると、8GB(4GBx2)のほうがビット単価が安かったのと、RAMスロットが2つなので、それらを勘案して、8GB(4GBx2)としました。
ということで、メーカー問わずの8GB(4GBx2)となりました。

次は電源です。
Haswellは、Haswell対応の電源が必要です(やや高い)。が、新設された省電力モードを使わないのであれば必要ありませんし、従来の電源でも問題なく動作するものも多いです。そもそも、CPUをスリープさせることがないサーバなので、Haswell対応の必要はありません。また、このマシンでは、グラフィックボードは接続しませんから、電源も大きくなくて大丈夫です。入手可能なものから、メーカーのサイトを調べて、Haswellでも「一応」動作可ということでしたので、それに決定しました。念のため500W品にしました。

次はCPUクーラーです。
適価で冷却性能が高いもの。ファンは12cm以上。メンテナンスフリーとするためです。
i7でリテールクーラーだと、常に70度という「冷えてない」状況です。さらに、そのi7よりもTDPがちょっとだけ大きいので、クーラーを買うことにしました。

以上は、もちろん、いくつかの通販ショップのWebページを見ながら決めていったわけですが、いくつかの要素を考慮した結果、最終的にTSUKUMOにしました(次点はAmazonでしした)。翌日出荷にならないと言われながらも結局翌日出荷でした。

組み立て自体は特に問題なくすんなりあっさりと動きました。

• CPUクーラーは、少し背が高すぎでした。ほぼケースの幅いっぱいです。側面パネルを外したまま使う予定だったから問題はなかったのですが、注意が必要です。
• 電源が上下逆さまになりました。ケースの電源取り付け穴がそうなっていたためです。今はケースの天板を取り外していますが、ケースを加工して、普通につけられるようにする予定です(GWの予定)。

さて、マザーボードの起動を確認しましたので、2TBのWDのHDDを接続してlinuxをインストールしようとしたら、インストール途中でエラーが出ます。だめじゃん。WDのGreenのトラブルです。何台目だよ!? 外しておいても生じるエラーは本当に困ります。バックアップの役もできない。WDのツールで再生(remap)するとしても、信頼性が低くなるので、このまま使うのは考えものです。
しかたないので、追加で別メーカーの3TB、買ってきました。そのため予算をはるかにオーバーしてしまいました。とほほ。


今回のマシンのまとめ：

• マシンの構成は「入手可能性」により、制限されてしまいます。今回ではCPUとメモリでした。型落ちがすぐに入手できなくなるようです。
• 予定していた性能は出ています。
• CPU温度は50度でした。i7の70度と比べてかなり低いのは、CPUクーラーの性能差かもしれませんし、CPUの省電力性能が上がったのかもしれません。
• 4コアのため、負荷が4を越えると、思った以上に処理速度が低下するような感じがあります。これは、CPUが悪いのでもなく、linuxが悪いのでもないでしょう。基本的にキャッシュの効きが処理速度に影響しますので、プロセスがCPUから追い出されるとキャッシュからも追い出されてしまうからでしょう。CPUがi7の8スレッドであれば、プロセスが追い出されないため、キャッシュ上に残りますから、そのままキャッシュの効きが維持される、ということと思われます。

そしてeth0がいなくなった

はい、例によってdebianのsidでdist-upgradeしたらトラブル発生です。
そして、いつものように再起動するまで問題が発覚しませんので、「あれっ!?」です。

ネットワークがつながりません。
ネットワークの物理的な接続は問題なしでしたので、OS側の問題です。

# ifconfig -a

あれれ、eth0がありません。
じゃぁ、Ethernetのチップは見えているのかというと

# lspci

この中に

Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 02)

があるので、ふむ、そこまではよしと。
なら、ドライバは?

# lsmod |grep 8

? なにも出てきません。どゆこと? こいつは、8168のドライバだったんじゃなかったっけ? 8169だっけ?
ドライバはどこ?

# ls -F /lib/modules/3.13-1-686-pae/kernel/drivers/net/ethernet/realtek/
8139cp.ko 8139too.ko r8169.ko

!!! 8138のドライバがないじゃん。でも、前はr8169のドライバだったような気がする…

# cat /etc/modprobe.d/r8168-dkms.conf
# blacklisted by r8168-dkms
blacklist r8169

なんか知りませんが、blacklist入りしてます。
記憶が確かならr8169で代用がきいたはず。えーい。

# modprobe r8169
# ifup eth0

とりあえずは、これでネットにつながるので、やっと検索ができるようになりました。
ググると、8168はバグがあるからデフォルトでインストールを止めたみたいです。
でも、必要な人がいるから(当たり前だ、ばかたれ)、ソースで供給してたらしいです。
で、debianはというと、それを自動化してaptパッケージで出したようです。

# apt-get install r8168-dkms

あれ、エラーしますね。ひょっとして、kernel headerがない?

# apt-get install linux-headers-3.13-1-686-pae

はい、そのとおり。じゃ、も一度。

# apt-get install --reinstall r8168-dkms

いろんなメッセージを出してきますね。
ともあれ、

/lib/modules/3.13-1-686-pae/updates/dkms/r8168.ko

がビルドされました。
一度rebootしてみます。さっきのメッセージに、

ブートに失敗したら、initrd.img-3.13-1-686-pae.old-dkmsを使ってね

って書いたありましたが…
おお、問題なく立ち上がりますよ。

# lsmod | grep 81
r8168 246337 0

ちゃんとr8168のドライバが入ってます。

さて、今回の問題は何だったのかなー。

• 8168をr8169のドライバで代用するのを止めるようになった
• dist-upgradeでkernelのアップデートのときに、kernel headerがインストールされなかった(なぜかいつもインストールされないので、手動でインストールしてます=面倒)
• r8168ドライバ(ソースからコンパイルする)のモジュールはアップデートで自動的に選択されてインストールされた(しようとした)
• しかし、r8168ドライバ(ソースからコンパイルする)はインストールに際してkernel headerを必要とする

ということで、dist-upgradeしたら、kernel headerがないので、r8168ドライバをビルドできなかった、ということみたいです。r8168ドライバのモジュールがkernel headerに依存しているのに、kernel headerをインストールするように設定されないのが問題だったのでしょう。そしてeth0がいなくなった、と。

タグ：Debian