新しいディスク暗号化機能を使用してルートファイルシステムを暗号化すると、システムをシャットダウンした際に以下のようなエラーメッセージがコンソールに報告されます。
Stopping disk encryption [FAILED]
このメッセージは無視しても問題ありません。シャットダウンは最後まで正しく実行されます。
When using an encrypted device, the following error message may be reported during bootup:
insmod: error inserting '/lib/aes_generic.ko': -1 File exists
This message can safely be ignored.
マルチパス上で MD (マルチデバイス) RAID を使用してインストールを行うと、マシンがブートできなくなります。RAID を内部で提供する SAN (ストレージエリアネットワーク) デバイスは影響を受けません。
When a large number of LUNs are added to a node, multipath can significantly increase the time it takes for udev to create device nodes for them. If you experience this problem, you can correct it by deleting the following line in
/etc/udev/rules.d/40-multipath.rules
:
KERNEL!="dm-[0-9]*", ACTION=="add", PROGRAM=="/bin/bash -c '/sbin/lsmod | /bin/grep ^dm_multipath'", RUN+="/sbin/multipath -v0 %M:%m"
This line causes udev to run multipath every time a block device is added to the node. Even with this line removed, multipathd will still automatically create multipath devices, and multipath will still be called during the boot process, for nodes with multipathed root filesystems. The only change is that multipath devices will not be automatically created when multipathd is not running, which should not be a problem for the vast majority of multipath users.
以前のバージョンの Red Hat Enterprise Linux を 5.3 にアップグレードすると、以下のようなエラーが発生することがあります。
Updating : mypackage ################### [ 472/1655]
rpmdb: unable to lock mutex: Invalid argument
このロッキングの問題は、glibc 内の共有 futex のロッキングが 5.2 と 5.3 間のプロセス毎の futex によって強化されたことが原因です。そのため、5.2 glibc で実行しているプログラムが、5.3 glibc で実行しているプログラムに対して正しく共有 futex ロッキングを実行できません。
エラーメッセージは、インストールスクリプトの 1 つとして rpm を呼び出すパッケージによるものです。アップグレードを実行する rpm インスタンスはアップグレードが終わるまで以前の glibc を使用しますが、スクリプトから開始された rpm インスタンスは新しい glibc を使用します。
To avoid this error, upgrade glibc first in a separate run:
# yum update glibc
# yum update
You will also see this error if you downgrade glibc to an earlier version on an installed 5.3 system.
Red Hat Enterprise Linux 5 の mvapich
および mvapich2
は、InfiniBand/iWARP 相互接続のみをサポートするためにコンパイルされています。そのため、イーサネットやその他のネットワーク相互接続上では実行できません。
暗号化されたブロックデバイスを 3 つ以上持つシステム上で、anaconda はオプションでグローバルパスフレーズを提供しますが、init スクリプトはこの機能をサポートしていません。システムをブートする際にすべての暗号化デバイスに対して個別にパスフレーズを入力する必要があります。
When upgrading openmpi using yum, the following warning may be returned:
cannot open `/tmp/openmpi-upgrade-version.*' for reading: No such file or directory
The message is harmless and can be safely ignored.
ベクトル毎のマスキングができない MSI(メッセージ信号割り込み)を使用するデバイスの一部は、IRQ SMP アフィニティを設定しても設定が反映されません。このようなデバイスの 1 つが bnx2
ドライバを使用する Broadcom NetXtreme Ethernet デバイスです。
このようなデバイスに対して IRQ アフィニティを設定する必要がある場合は、/etc/modprobe.d/
内に次の行を含むファイルを作成し、MSI を無効にします。
options bnx2 disable_msi=1
また、カーネルブートパラメータ pci=nomsi
を使用して MSI を完全に無効にすることもできます。
更新済みの /etc/udev/rules.d/50-udev.rules
ファイル内のバグは、その名前の中に 9 以上の数字を持つテープデバイス用に固執の名前を作成することを阻止します。例えば、nst12
を持つ名前にはテープデバイス用に固執の名前を 作成しません。
これを迂回するには、/etc/udev/rules.d/50-udev.rules
内の ストリング nst[0-9]
の全ての表示の後にアスターリスク(*) を 追記します。
smartctl
ツールは SATA デバイスから SMART パラメータを 正しく読み取れません。
openmpi
と lam
の以前のバージョン内の バグは、これらのパッケージのアップグレードを阻止するかもしれません。このバグは、openmpi
、 又は lam
のアップグレードを試みるときに以下のエラーにより判明します:
error: %preun(openmpi-[version]) scriptlet failed, exit status 2
そのため、openmpi
と lam
の 旧バージョンを手動で削除して、それらの最新バージョンをインストールする必要が あります。これを達成するには、以下の rpm
コマンドを 使用します:
rpm -qa | grep '^openmpi-\|^lam-' | xargs rpm -e --noscripts --allmatches
When using dm-multipath
, if features "1 queue_if_no_path"
is specified in /etc/multipath.conf
then any process that issues I/O will hang until one or more paths are restored.
To avoid this, set no_path_retry [N]
in /etc/multipath.conf
(where [N]
is the number of times the system should retry a path). When you do, remove the features "1 queue_if_no_path"
option from /etc/multipath.conf
as well.
If you need to use "1 queue_if_no_path"
and experience the issue noted here, use dmsetup
to edit the policy at runtime for a particular LUN (i.e. for which all the paths are unavailable).
To illustrate: run dmsetup message [device] 0 "fail_if_no_path"
, where [device]
is the multipath device name (e.g. mpath2
; do not specify the path) for which you want to change the policy from "queue_if_no_path"
to "fail_if_no_path"
.
同じカーネルモジュールの複数のインストール済みバージョンを有効にすることは、 サポートされていません。これに加えて、カーネルモジュールバージョンが構文解析 される方法に関するバグが、時として同じカーネルモジュールの旧バージョンを有効に してしまうことがあります。
Red Hat では、インストール済みのカーネルモジュールの新バージョンをインストールする時には 最初に旧バージョンを削除することを推奨します。
NFS root で設定されている IBM Bladecenter QS21 又は、 QS22 上で kdump
を実行すると、 失敗します。これを回避するには、/etc/kdump.conf
で NFS ダンプターゲットを指定します。
IBM T60 ラップトップは、サスペンドの時とドッキングステーションに 挿入されている時には、完全に電源が切れます。これを回避するには、システムを 引数 acpi_sleep=s3_bios
で起動します。
IBM Bladecenter 用の QLogic iSCSI Expansion Card はイーサネットと iSCSI の両方の機能を提供します。 カードの一部は両方の機能で共有されます。 しかし、 現在の qla3xxx
ドライバと qla4xxx
ドライバはイーサネットと iSCSI の機能を別々にサポートします。 いずれのドライバもイーサネットと iSCSI 機能の同時使用はサポートしていません。
この制限のため、連続的なリセット(継続的な ifdown
/ifup
コマンドの使用)はデバイスをハングします。これを回避するには、ifup
を実行した後に 10秒ほど経過してから、ifdown
を実行してください。また、同様に ifdown
を実行した後には、10秒ほど経過してから ifup
を 実行して下さい。この間隔により、ifup
が発行される時に全ての機能を安定させて 初期化する時間を十分に与えます。
Cisco Aironet MPI-350 ワイヤレスカードを装備している ラップトップでは、ワイヤ付きイーサネットポートを使用してネットワークベースの インストールをする間に、DHCP アドレスの取得をしようとしてハングする可能性があります。
これを回避するには、インストール用のローカルメディアを使用します。別の方法として、 インストール前にラップトップ BIOS 内のワイヤレスカードを無効にすることも出来ます。 (インストールの後にワイヤレスカードは再度、有効にできます)
/var/log/boot.log
へのブート時のロギングは、Red Hat Enterprise Linux 5.3 では使用できません。
X が稼働中で、vesa 以外のドライバーを使用している場合、システムは kexec
/kdump
カーネルに正しく再起動しないことがあります。この問題は ATI Rage XL グラフィクスチップセットでのみ発生します。
ATI Rage XL を持つシステムで X が稼動している場合、 kexec
/kdump
カーネルに正しく再起動するようにするため vesa ドライバを使用するようにしてください。
nVidia CK804 チップセットを持つマシンで Red Hat Enterprise Linux 5.2 を 使用する場合、以下のようなカーネルメッセージを受ける可能性があります:
kernel: assign_interrupt_mode Found MSI capability
kernel: pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS
これらのメッセージは特定の PCI-E ポートが IRQ を要求していないことを示します。しかし、これらのメッセージは如何なる面でも操作に影響することはありません。
取り出し可能なストレージデバイス(CD や DVD など)は、 root としてログインしている場合には 自動的にマウントしません。その場合、グラフィカルファイルマネージャを通じて手動でデバイスを マウントする必要があります。
別の方法として、以下のコマンドを使用してデバイスを /media
に マウントします:
mount /dev/[device name] /media
設定済のストレージシステムで LUN が削除されると、その変更はホスト上では反映されません。そのようなケースでは、LUN がその時点で 滞留(stale)状態になるため、 dm-multipath
が 使用されると lvm
コマンドは無限にハングします。
これを迂回するには、滞留している LUN に特有の /etc/lvm/.cache
内にある 全てのデバイスと mpath
リンクエントリを削除します。
次のコマンドを使用してこれらのエントリが何かを調べます:
ls -l /dev/mpath | grep [stale LUN]
例えば、[stale LUN]
が 3600d0230003414f30000203a7bc41a00 の場合、以下のような結果が 出ます:
lrwxrwxrwx 1 root root 7 Aug 2 10:33 /3600d0230003414f30000203a7bc41a00 -> ../dm-4
lrwxrwxrwx 1 root root 7 Aug 2 10:33 /3600d0230003414f30000203a7bc41a00p1 -> ../dm-5
これは、3600d0230003414f30000203a7bc41a00 が二つの mpath
リンク : dm-4
及び dm-5
にマップされていると言う意味です。
その状況では、以下の行が /etc/lvm/.cache
から削除される 必要があります:
/dev/dm-4
/dev/dm-5
/dev/mapper/3600d0230003414f30000203a7bc41a00
/dev/mapper/3600d0230003414f30000203a7bc41a00p1
/dev/mpath/3600d0230003414f30000203a7bc41a00
/dev/mpath/3600d0230003414f30000203a7bc41a00p1
-ll
オプションを持つ multipath
コマンドの 実行は、パスの1つがブロックデバイス上にある場合、このコマンドがハングする原因になります。 デバイスが反応しない場合も、ドライバーはしばらく時間を取ると要求を失敗しないことに注意して ください。
これは、パスチェッカー要求が完了するか、失敗するかを待つクリーンアップコードが原因です。コマンドをハングせずに現在の multipath
状態を 表示するには、代わりに multipath -l
を使用します。
Red Hat Enterprise Linux 5.2 Beta バージョンの pm-utils
から pm-utils
をアップグレードしようとすると、次のようなエラーが発生し、アップグレードに失敗します。
error: unpacking of archive failed on file /etc/pm/sleep.d: cpio: rename
この問題発生を防ぐには、 アップグレードを行う前に /etc/pm/sleep.d/
ディレクトリを削除しておきます。 /etc/pm/sleep.d/
になんらかのファイルがある場合は、そのファイルを /etc/pm/hooks/
に移動します。
Mellanox MT25204 のハードウェアテストにより特定の高負荷条件下で内部エラーが発生することが明らかになりました。 ib_mthca
ドライバがこのハードウェア上で重篤なエラーを報告する場合、 通常、 ユーザーアプリケーションによって生成される未処理の作業要求数に対して完了できるキューの深さが不十分な場合に関連します。
ドライバがハードウェアをリセットしてこのようなイベントから回復しても、 既存の接続はすべてエラー発生時に失われます。 これは一般的にユーザーアプリケーションのセグメンテーション障害となります。 さらに、 opensm
がエラー発生時に稼働していた場合は、 正常な動作を再開させるため手動で再起動する必要があります。
ゲストに Red Hat Enterprise Linux 5 をインストールする際に、dom0
によって提供される一時インストールカーネルをゲストが明示的に使用するよう設定すると、ゲストの最初のリブートに対してシャットダウンを強制した場合のみ、インストール終了後に独自のブートローダを使用することができます。
そのため、ゲストのインストールの最後に表示される ボタンをクリックすると、ゲストはシャットダウンしますが、リブートしません。これは予期される動作です。
この後にゲストをブートすると、独自のブートローダを使用するようになります。
KDE または qt
開発パッケージ (qt-devel
など) がインストールされると compiz
ソース RPM で rpmbuild
の実行に失敗します。これは、compiz
設定スクリプトのバグが原因です。
このバグに対処するには、KDE または qt
開発パッケージを削除してから、ソース RPM から compiz
パッケージをビルドするようにします。
システムにATI Radeon R500 または R600 グラフィックカードが装備されている場合、インストール後に firstboot
を実行しようとしても実行されません。システムは直接グラフィカルログイン画面に移り、firstboot
の実行をスキップします。フェールセーフターミナルなどから手作業で firstboot
を実行しようとすると X セッションがクラッシュします。
この問題は ATI Radeon R500/R600 ハードウェアが使用するドライバが原因となっています。これらのグラフィックカードがデフォルトで使用するドライバは技術プレビューの段階です。これに対処するには、/etc/X11/xorg.conf
ファイルをバックアップした後、X を設定して以下のコマンドではなく、サポートされる vesa
ドライバが使用されるようにします。
system-config-display --reconfig --set-driver=vesa
これで、firstboot
を実行できるようになります。元の設定に戻すには、元の/etc/X11/xorg.conf
をリストアします。
システムが TSC タイマを使用する場合、gettimeofday
システムコールが後方に移動する場合があります。これは、場合によって TSC タイマが大幅に前方移動するオーバーフローの問題が原因です。この問題が発生すると、TSC タイマは独自に問題の修正を行いますが、最終的に後方移動します。
この問題は、トランザクションシステムやデータベースとして使用される時間依存のシステムにとっては重要な問題です。そのため、正確な時間計測が必要となるシステムには、別のタイマ (HPET など) を使用するよう、カーネルを設定することが推奨されます。
sniff
を実行しようとするとエラーになることがあります。これは、一部の必要なパッケージが dogtail
と共にインストール されていないことが原因です。
この問題が発生しないようにするには、以下のパッケージを手作業でインストールします。
librsvg2
ghostscript-fonts
pygtk2-libglade
Thin Provisioning (also known as "virtual provisioning") will be first released with EMC Symmetrix DMX3 and DMX4. Please refer to the EMC Support Matrix and Symmetrix Enginuity code release notes for further details.
/etc/multipath.conf
内で max_fds
を unlimited
に設定すると、multipathd
デーモンが正しく起動しません。そのため、十分に大きい値を使用するようにしてください。
SystemTap は現在 GCC を使用してユーザースペースのイベントをプローブします。しかし、GCC はパラメータの正確な場所リストを持つデバッガを提供できません。また、GCC は一部のパラメータで可視性も提供できないことがあります。そのため、ユーザースペースをプローブする SystemTap スクリプトが不正確な読み出しを返す場合があります。
IBM T41 ラップトップモデルでは正しく が入力されないため、 を選択しても通常通り電源が消費されます。これは、Red Hat Enterprise Linux 5 には radeonfb
モジュールが同梱されていないからです。
この問題に対応するには、次の行を含む hal-system-power-suspend
という名前のスクリプトを /usr/share/hal/scripts/
に追加します。
chvt 1
radeontool light off
radeontool dac off
このスクリプトを追加すると、IBM T41 ラップトップが を正しく入力するようになります。システムが適切に普通の操作に戻るようにするため、次の行を含む restore-after-standby
スクリプトを同じディレクトリに追加します。
radeontool dac on
radeontool light on
chvt 7
edac
モジュールがロードされると、BIOS メモリ報告が動作しません。これは、BIOS がメモリエラーの報告に使用するレジスタを edac
モジュールが削除してしまうためです。
現在の Red Hat Enterprise Linux Driver Update Model は、デフォルトでカーネルに対して edac
を含む利用可能なモジュールをすべてロードするよう指示します。システム上の BIOS メモリ報告を有効にするには、手作業で edac
をブラックリストする必要があります。edac
をブラックリストするには、以下の行を /etc/modprobe.conf
に追加します。
blacklist edac_mc
blacklist i5000_edac
blacklist i3000_edac
blacklist e752x_edac
Red Hat Enterprise Linux 5.3 は、基礎のブロックデバイスのオンライン拡張や縮小を検出できますが、デバイスのサイズ変更を自動的に検出するメソッドはありません。そのため、デバイスのサイズ変更を認識したり、デバイスに存在するファイルシステムのサイズを変更するには、手作業で行う必要があります。サイズ変更されたブロックデバイスが検出されると、以下のようなメッセージがシステムログに表示されます。
VFS: busy inodes on changed media or resized disk sdi
ブロックデバイスが拡張された場合は、このメッセージを無視しても問題ありません。しかし、ブロックデバイス上のデーターセットが縮小される前にブロックデバイスが縮小された場合、デバイスに存在するデータが破損する場合があります。
LUN (またはブロックデバイス) 全体で作成されたファイルシステムのサイズのみオンラインで変更できます。ブロックデバイスにパーティションテーブルがある場合、ファイルシステムをアンマウントしてパーティションテーブルを更新する必要があります。
システムに GFS2 ファイルシステムがマウントされている場合、キャッシュされた i ノードが1 つのノードでアクセスされ、別のノードでリンクされないとノードがハングすることがあります。この問題が発生すると、ハングしたノードをフェンスし、通常のクラスタリカバリメカニズムでリカバリを実行するまでハングしたノードは使用できません。また、ハングしたノードに残されたプロセスのスタックトレースにgfs2_dinode_dealloc
および shrink_dcache_memory
関数呼び出しが出力されます。
この問題は単一ノードの GFS2 ファイルシステムには関係ありません。
The following message may be encountered during system boot:
Could not detect stabilization, waiting 10 seconds.
Reading all physical volumes. This may take a while...
This delay (which may be up to 10 seconds, dependant on the hardware configuration) is necessary to ensure that the kernel has completed scanning the disks.
現在 ipmitool に実装されている により、デバイスは設定できてもデバイスの現在の設定を読み出すことはできません。
--maxsize
パラメータを同時に設定せずに kickstart ファイルで swap --grow
パラメータを使用すると、anaconda がスワップパーティションの大きさを制限します。拡張してデバイスを満杯にすることはできません。
物理メモリが 2GB 未満のシステムでは、この制限は物理メモリの 2 倍になります。物理メモリが 2GB 以上のシステムでは、物理メモリの大きさに 2GB を足したサイズが制限になります。
The
gfs2_convert
program may not free up all blocks from the GFS metadata that are no longer used under GFS2. These unused metadata blocks will be discovered and freed the next time gfs2_fsck is run on the file system. It is recommended that
gfs2_fsck
be run after the filesystem has been converted to free the unused blocks. These unused blocks will be flagged by gfs2_fsck with messages such as:
Ondisk and fsck bitmaps differ at block 137 (0x89)
Ondisk status is 1 (Data) but FSCK thinks it should be 0 (Free)
Metadata type is 0 (free)
These messages do not indicate corruption in the GFS2 file system, they indicate blocks that should have been freed, but were not. The number of blocks needing to be freed will vary depending on the size of the file system and block size. Many file systems will not encounter this issue at all. Large file systems may have a small number of blocks (typically less than 100).