アップグレードされたFedoraシステムに問題があります。最近AmazonがEBSベースの画像を追加したので、試してみることにしました。基本的なFC8インスタンスを起動し、yumでアップグレードしました。最初はFC10まで、その後はFC12まで。
さて、私は今FC12インスタンスに/ dev/randomがありません、そして他のいくつかのあいまいなことがあります。例:/ dev/nullには600の権限があり、/ dev/urandomはブロックデバイスではありません。/dev/randomは完全になくなりました:)
私はここを読みました http://markus.revti.com/2007/12/creating-devrandom/ 、上記の問題を「修正」する方法ですが、システムを起動するたびにすべてが同じです。 /etc/rc.localに修正を追加する予定です。これは良い解決策/回避策だと思いますか?
問題が正確にどこにあるか誰かが知っていますか?
アドバイスや知識の共有に感謝します。
スタン。
p.s.インスタンスは次のカーネルを実行しています:2.6.21.7-2.ec2.v1.2.fc8xen
それらはudevによって作成されたと思います。/etc/udevディレクトリの内容を動作中のシステムと比較したり、/ var/log/udevを調べたりすると、洞察が得られる場合があります。
そのようなec2イメージを実際にアップグレードすることはできません。カーネルはAmazonによって提供されているため、一致するカーネルを使用してインスタンスを起動する必要があります。そうしないと、(説明したような)奇妙な動作が発生します。
カーネルの変更が必要なシステムを「アップグレード」する唯一の方法は、新しいイメージを最初から作成するか、必要なOSリビジョンで既存のAMIを見つけることです。
実行できます:
/sbin/MAKEDEV std
それらのデバイスファイル(および他のいくつかのファイル)を作成します。
私の問題がどこにあるかを見つけました:
https://bugs.launchpad.net/ubuntu-on-ec2/+bug/397187
実際、新しいUdevにアップグレードすると、signalfd(2)が使用されますが、これは私のEC2カーネルでは使用できません。
この情報が他の誰かに役立つことを願っています。
スタン。
最新のLinuxディストリビューションのほとんどは、 dev を使用して/dev
のコンテンツを動的に設定します。
通常、ルートFSは、ブートストラップするために/dev/console
と/dev/null
の静的エントリのみを必要とします。起動すると、tmpfs
マウントが/dev
をオーバーレイし、デバイスノードの完全な補完を提供します。 。
いくつかの診断手順。
dmesg | grep udev
ps ax | grep udevd
grep udev /proc/mounts
カイルの答えに従って、/etc/udev
の内容を確認することができます。 udevはルールなしで基本レベルで機能するはずですが、それが原因である可能性は低くなります。
後日戻ってくるので、すべてのノードを手動で作成しないでください。
カイルが言ったこと。 Fedora wikiには記事があります: yumを使用してFedoraをアップグレードする -特に、「クリーンなもの」のセクションで説明されているように、/ etc内の.rpmsaveファイルをチェックします。問題を修正することは、症状を修正しようとして重要な何かを見逃すよりも常に良い考えです。