相方が携帯紛失

X Windowを殺すのにctrl+alt+backspaceを使うのは有名な話だが、それが効かなくなってる。
どうも最近のxorgの流れらしい。
誤爆防止のためのようだが、初心者のうちはともかく使いなれてると逆に迷惑な話だ。

で、どうにか復活させられないか調べた。
まずでてきたのは/etc/X11/xorg.confに以下を記述するというもの。

Section "ServerFlags"
Option "DontZap"  "No"
EndSection

で、次に、dpkg-reconfigure console-setupを叩くというもの。
どうかんがえてもこっちの方が楽そうなのでこっちをやってみた。

これでいいだろたぶん。

すると、ctrl+alt+bsでXは死ぬようになった。
が。
再起動する。orz
いやいや、普通に死んでそのまま生き返らないでほしい。

と、そこでふともう一回、今度はGnomeが立ち上がっていないうち、つまりログイン画面でctrl+alt+bsたたいてみた。
殺せた。
ctrl+alt+f1とかで切り替えも平和に。
startxやるとまた上がる。
いい感じだ。

今日の記述量が異常ですね、はい。

でまあ、X WindowいれてからなんかXenのネットワークまわりが変になったって話をしましたが、やっぱり気のせいだったっていうことになりましたが、やっぱり間違ってなかったです。

network-manager

こいつが邪魔してた。
ということで、

# mv /etc/init.d/network-manager /etc/init.d/network-manager.bak
# update-rc.d network-manager remove

ということで。

before

# ping google.com
PING google.com (74.125.45.100) 56(84) bytes of data.
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=3 ttl=49 time=162 ms
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=8 ttl=49 time=162 ms
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=13 ttl=49 time=160 ms
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=18 ttl=49 time=160 ms
^C
— google.com ping statistics —
18 packets transmitted, 4 received, 77% packet loss, time 17023ms
rtt min/avg/max/mdev = 160.291/161.358/162.100/0.825 ms

after

# ping google.com
PING google.com (209.85.171.100) 56(84) bytes of data.
64 bytes from cg-in-f100.google.com (209.85.171.100): icmp_seq=1 ttl=241 time=96.5 ms
64 bytes from cg-in-f100.google.com (209.85.171.100): icmp_seq=2 ttl=241 time=95.3 ms
64 bytes from cg-in-f100.google.com (209.85.171.100): icmp_seq=3 ttl=241 time=95.8 ms
64 bytes from cg-in-f100.google.com (209.85.171.100): icmp_seq=4 ttl=241 time=95.2 ms
64 bytes from cg-in-f100.google.com (209.85.171.100): icmp_seq=5 ttl=241 time=96.1 ms
64 bytes from cg-in-f100.google.com (209.85.171.100): icmp_seq=6 ttl=241 time=95.5 ms
^C
— google.com ping statistics —
6 packets transmitted, 6 received, 0% packet loss, time 5029ms

network-managerとかデスクトップ環境として普通に使ってても邪魔よね。
/etc/resolv.conf勝手に書き換えたりするし、/etc/network/interfacesの設定変えても反映させてくれないし。

DHCPでDNSもゲートウェイな人だと問題ないのかなぁ。
うちだと固定IPでDNSもサーバ自身みてるからなー。

X Windowを起動したら動かなくなるのかと思ったら、どうやらそうではない模様。
システム起動直後は動くのだが、しばらくするとネットワークがしぬ。
ゲートウェイまでたどり着くのに、そこから外へ出られないっていう。

ifconfig -a してみたら見知らぬpan0とかいうのが生まれていた。
なんだこいつ？
brctl showでみてみるとどうやらブリッジらしい。
起動時のmessagesを眺めてみると、どうやらbluetooth関連らしい。
起動しないようにしてみる。

# mv bluetooth bluetooth.bak
# mv avahi-daemon avahi-daemon.bak
# update-rc.d avahi-daemon remove
# update-rc.d bluetooth remove

avahiも使わないからついでにけした。
でまあそれでも解決しないわけで、関係しそうなところのログを眺める。

[   16.353018] ADDRCONF(NETDEV_UP): eth0: link is not ready
[   16.378871] e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
[   16.379252] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   27.049312] eth0: no IPv6 routers present
[   55.719604] Bridge firewalling registered
[   55.721531] tmpbridge: Dropping NETIF_F_UFO since no NETIF_F_HW_CSUM feature.
[   56.149371] ADDRCONF(NETDEV_UP): peth0: link is not ready
[   59.789671] e1000: peth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
[   59.810070] ADDRCONF(NETDEV_CHANGE): peth0: link becomes ready
[   60.225660] device peth0 entered promiscuous mode
[   62.767713] eth0: port 1(peth0) entering learning state
[   62.771833] eth0: topology change detected, propagating
[   62.771894] eth0: port 1(peth0) entering forwarding state

tmpbridge: Dropping NETIF_F_UFO since no NETIF_F_HW_CSUM feature.
この辺が怪しい。

調べてみると、NETIF_F_HW_CSUMってのはハードウェアチェックサムのことらしい。
でまあ、さらにそれらしい回答が漸く見つかった。

"This means that for some reason the UFO flag has been enabled
on the bridge device without also enabling TX checksum offload.
This is an illegal configuration which is why the kernel warns
about it.  As to why the UFO flag is set at all more investigation
is needed on the actual machine.

However, this is harmless as UFO isn't supported by Xen anyway."

とりあえず、要するに気にするなってことなんだが、人によってはそのままでも動くって人もいるし、人によってはネットワークにつながらないという。
とりあえず、ネットワークをリスタートしたら動くって人もいたのでやってみた。
動いた。
死ぬほどパケロスしてるんですけど。

# ping google.com
PING google.com (74.125.45.100) 56(84) bytes of data.
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=3 ttl=49 time=162 ms
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=8 ttl=49 time=162 ms
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=13 ttl=49 time=160 ms
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=18 ttl=49 time=160 ms
^C
— google.com ping statistics —
18 packets transmitted, 4 received, 77% packet loss, time 17023ms
rtt min/avg/max/mdev = 160.291/161.358/162.100/0.825 ms

どうもこれはxenが元々抱えている問題なようだ。
Xとは関係なさそう。
たまたまXインストールしたタイミングと問題発生したのがかぶっただけのようだ。
bugzillaには登録されているようなので直してくれるのを待とう。

Xの設定でビデオカードのドライバをvesaに変更したらいけた。

# vi /etc/X11/xorg.conf

Section “Device”
Identifier    “Configured Video Device”
Driver    “vesa”
EndSection

これでとりあえずxenカーネルでもXは起動したんだけども、やはりXを起動するとネットワークがばぐって動かなくなる。
調査引き続き継続。

グラフィカルログインがデフォルトになっていると、ログアウトしてもXのログイン画面に戻って来てしまう。
Xのプロセスをkillしてもやっぱりそう。
で、なんかないかと探したら、あった。

# /etc/init.d/gdm stop

これでXが停止した。
GNOMEだからこれなんだろうけど他のウィンドウマネージャ使ってると違うんだろうな。
起動はご存知の通りstartx。

でまあ、普段は使う予定がないので、デフォルトではXを起動しないようにする。

# mv /etc/init.d/gdm /etc/init.d/gdm.bak
# update-rc.d gdm remove

これでOK。

xenの設定がどうにもうまくいかないので、あったまきたのでX入れてGUIでやってやろうと思った。
そこで

# aptitude install gnome

もりもりたくさんパッケージが追加。
で。

お決まりのネットワーク不具合。

インターフェイスはあるように見えるがなんかうまく動かない。
ゲートウェイまでたどり着けるけどそこから先にいけない。
/etc/resolv.confがかきかえられてたのを見つけて直したけどやっぱだめ。
意味分からんと思いつつxenカーネルじゃなくて普通のカーネルを立ち上げたらさっくりつながった。

でもそれまったく意味ないし。

もういやです。