[ 前のページ ] [ 目次 ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ A ] [ 次のページ ]
sarge の python2.X パッケージには、 標準モジュールである 'profile' と 'pstats' が含まれていません。 これは当該モジュールに適用されているライセンスが、DFSG に合致しないためです (詳細はバグ報告 #293932 を参照してください)。これら 2 つのモジュールは、Debian アーカイブ の non-free セクション内の python-profiler および python2.X-profiler パッ ケージにあります。
2.6 系カーネルは、2.4 系カーネルから大きな変更が加えられています。 モジュールの名称が変更され、 多くのドライバが部分的あるいはほとんど完全に書き換えられました。 したがって、以前のバージョンから 2.6 系カーネルへのアップグレードは、 それほど簡単に済ませられるものではありません。このセクションは、 直面するかもしれない問題のいくつかを知っておいてもらおうというのが狙いです。
それゆえ、woody から sarge へのアップグレードの一部として 2.6 系カーネルへのアップグレードを行うのはお勧めしません。 まずは、システムが sarge の 2.4 系 (もしくはそれ以前のバージョンの) カーネルで正しく動作するのを確認すべきです。その後、別の課題として、 2.6 系カーネルへのアップグレードを実施してください。
ソースから自分でカーネルをコンパイルしている人は、2.6
系カーネルで再起動する前に、 module-init-tools
がインストールされているのを確認してください。
このパッケージは、modutils を 2.6
系カーネル用のものに置き換えます。 Debian の kernel-image
パッケージのどれかを使っている場合は、
依存関係により自動的にこのパッケージが入っているはずです。
LVM を使っている場合は、2.6 系カーネルで再起動する前に
lvm2 パッケージもインストールしてください。 2.6 系カーネルは LVM1
を直接はサポートしていません。 LVM1
のボリュームにアクセスするには、lvm2 の互換レイヤ (dm-mod
モジュール) が使われます。
初期化スクリプトがどのバージョンのカーネルが使われているかを検出し、
適切なバージョンを実行するので、lvm10
はインストールしたままでも構いません。
/etc/modules ファイル (システム起動時にロードされる
モジュールの一覧) 内に記述をしているなら、いくつかのモジュール名が
変わっているかもしれないことに注意してください。変わっている場合は、
ファイル内の記述を新しいモジュール名で更新しなければならないでしょう。
いくつかの SATA ディスクコントローラでは、ドライブやそのパーティ
ションに割り当てられたデバイスが /dev/hdX から
/dev/sdX に変わっているかもしれません。変わっている場
合は、/etc/fstab とブートローダ設定を適切に修正しなけ
ればならないでしょう。これらの修正が正確に行なわれないと、システム
は正しく起動しないでしょう。
2.6 系カーネルをインストールした後、再起動を行う前に、復旧手段を 用意するようにしてください。まず、ブートローダの設定に新しいカーネル と稼働中の古い 2.4 系カーネルの両方の記述があることを確認してください。 ブートローダの設定が間違っていたために古いカーネルで起動できなくなる 場合に備え、"レスキュー用の" フロッピーか CD-ROM が手元にあることも 確認しておくべきでしょう。
2.6 系カーネルでの最も劇的な変化は、入力レイヤの基本部分の変更です。 この変更により、すべてのキーボードは「ふつうの」PC キーボードのように扱えます。 これは、現在異なるタイプのキーボード (例えば USB-MAC や Sun キーボード) を選択している場合、新しい 2.6 系カーネルで再起動後にキーボードがまったく 動かない状態になってしまう可能性が非常に高いということです。
別のシステムからそのマシンへ SSH を使ってログインできるのなら、 dpkg-reconfigure console-data と実行して "Select keymap from full list" オプションを選び、そこから "pc" キーボードを選択することでこの問 題を解決できます。
コンソールで使っているキーボードが影響を受けたということは、 X Window System
のキーボードも再度設定する必要があるでしょう。 dpkg-reconfigure
xserver-xfree86 を実行するか、 /etc/X11/XF86Config-4
を直接編集することになります。 リブート前にすべきこと, 第 4.6 節
で参照されている文書も読んでおいてください。
この問題は、すべての PS/2 および大半の USB キーボードがすでに "normal" PC キーボードとして設定されている Intel x86 アーキテ クチャでは影響がないでしょう。
これも入力レイヤの変更によるものですが、2.6 系カーネルへアップグレー
ドした後でマウスが使えなくなったなら、X Window System と gpm
を再設定する必要があるでしょう。よくある原因は、マウス
からのデータを受け取るデバイスが変わったせいです。別のモジュールを
ロードする必要もあるかもしれません。
2.6 カーネル用としては、OSS サウンドドライバよりも ALSA サウンドドラ
イバが推奨されます。ALSA サウンドドライバは、デフォルトではモジュールと
して提供されます。サウンドを鳴らすには、あなたのサウンドハードウェアに
合ったモジュールがロードされる必要があります。一般に該当モジュールがあり、
alsa-base に加えて hotplug パッケー ジか
discover パッケージのいずれかがインストールされて
いれば、自動的にロードされます。alsa-base パッケージは また、OSS
モジュールが hotplug や discover に
よってロードされないようそれらを "ブラックリスト化" します。
/etc/modules 内に OSS モジュールの記述があるなら、それらを
削除すべきです。
udev は、devfs のユーザ空間での実装です。これは /dev
ディレクトリにマウントされ、
カーネルモジュールがロード・アンロードされるときにデバイスファイルを
ディレクトリに動的に作成・削除します。また、新しいデバイスの検出は、
hotplug とともに動作するようになっています。udev は
2.6 系カーネルでしか動作しません。
udev は、例えば gnome などの依存関係により
自動的にインストールされるので、2.6 系カーネルへの変更は udev
を動作させる絶好のチャンスです。
udev は広範囲にわたってテストされていますが、
いくつかのデバイスでは若干の修正が必要になるという問題があるかもしれません。
たいていの問題は、デバイスファイルの権限や所有者が変更されるというものです。
(/dev/video や /dev/radio など)
デフォルトではデバイスファイルが作成されない場合もあります。
udev は、これらの問題に対処する設定の仕組みを提供しています。
詳しくは、udev(8) や /etc/udev を見てください。
マシンの起動後 X のロードに失敗し、 /var/log/XFree86.0.log 内に
"missing core pointer" と いうエラー表示があるなら、マウスドライバが
hotplug によって 事前にロードされなかったことが原因と考えられます
(バグ #255744)。解決法と
しては、使っているマウス用のドライバモジュール (psmouseなど) を
/etc/modules に追加することがあります。
sarge で配布されている X サーバは、最適化の結果多くの Transmeta(TM) Crusoe(TM) プロセッサでは正しく実行できないコードを含んでいます。この結果、 X のクライアントアプリケーションが特定の状況 (x86 から Crusoe CPU の VLIW 命令に変換された「morphed」コードが、キャッシュ内で不正な状態にある場合) で以下のようなエラーメッセージとともに接続に失敗します:
X Error of failed request: BadLength
(poly request too large or internal Xlib length error)
Major opcode of failed request: 18 (X_ChangeProperty)
Serial number of failed request: 15
Current serial number in output stream: 18
実際の問題として、数時間起動させていると、 アプリケーションが突然終了するようになってしまいます。 ディスプレイマネージャが起動しているなら、 同様に終了と再起動を繰り返すようになります。 この状態は、バグのある VLIW Transmeta コードがキャッシュから消えるまで続きます。
このバグはプロプライエタリな Transmeta Code Morphing Software (CMS)
内に存在し、ラップトップの BIOS は起動時にベンダのシグネチャとして CMS
をチェックするので、このバグを直すには Transmeta
とラップトップのベンダが協力する以外にありません。
この問題に関するより詳しい情報は、 http://www.cs.auc.dk/~fleury/bug_cms/
や Debian のバグ報告 #216933 にあります。
このバグを回避するには、xserver-xfree86-dbg
パッケージのような、最適化せずにコンパイルした X
サーバをインストールすることです。
[ 前のページ ] [ 目次 ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ A ] [ 次のページ ]
Debian GNU/Linux 3.1 (`sarge') リリースノート (Intel x86 用)
$Id: release-notes.ja.sgml,v 1.13 2006/04/17 11:56:08 jseidel Exp $debian-doc@lists.debian.org