2012-04-13 9 views
7

Linuxカーネルが32ビットか64ビットかをチェックする必要があるbashスクリプトを書く必要があります。Linux用の32ビット/ 64ビットカーネルを確認する方法

私はのuname -aをコマンドを使用しています、そしてそれは私にx86_64の結果を提供します。しかし、私はそれが一般的な方法で使用することはできないと信じています。

Linux用の32ビット/ 64ビットカーネルを確認する方法は?あなたがlong intのサイズのためのシステムを照会できはuname出力の「64」

uname -a | grep 64 
+0

「インストール」と言うときは、カーネルを意味しますか? 32ビットインストールで64ビットカーネルを使用できるためです。 –

+0

はい...カーネル...ありがとうございました – VJS

答えて

-2

をGrep:

getconf LONG_BIT 

しかし、これはに完全に移植された場合、私はわからないんだけどすべての異なるアーキテクチャ。

+2

カーネルが64回コンパイルされた場合、これは偽陽性を引き起こします。サーバーの名前が 'blade64A'の場合は同じ。 –

+1

'uname -i |を使用してください。 grep 64'を実行します。 –

+0

@David Schwartz:私はこれで少し新しく、あなたの考えを得られなかった。少し説明してください。ありがとう、トン! – VJS

1

/proc/cpuinfoのlm(ロングモード)フラグを検索します。これが当てはまる場合は、64ビットプロセッサを搭載していることを意味します。シンプルなgrepはこの情報を提供するはずです。

カーネルバージョンに関しては、una​​me -a情報でいつでもgrepできます。 unameプログラムのソースを見つけて悪意のあるホスト名による不一致を減らす方がいいでしょう。

+2

これはi386/x86_64でのみ動作します。かつてはPOWERマシンで作業していましたが、 '/ proc/cpuinfo'のフォーマットはまったく違っていましたし、コンパクトで、これらのフラグもありませんでした。 –

+0

@above/proc/cpuinfoは、物理ビット数と仮想ビット数を示します。パワーマシンで作業中にこの情報を受け取りますか?私たちの次のステップは、この情報を理解することです。私は自分の努力をしています。もう1つ:私は、マシンの単語サイズを決定するためにCのintのサイズを使うことができると思います。 –

+0

@prathmeshkallurkar私はそのマシンにアクセスすることはできませんが、情報は実際には短く、CPUあたり4行、モデル名だけでなく、それ以上のものはほとんどありませんでした。たとえそれが利用可能なビットに関する情報を持っていたとしても、それは確かにx86とは異なるフォーマットであった。 –

1

私は以下を思いついた。 initが使用されているとします(一部のディストリビューションは他のローダーに切り替えましたが、合理的に頻繁に使用されるリストを得るのは簡単です)。を使用してください。a.outではありません。これらは、ほとんどのシステムではまったく問題ないと思われますが、おそらく組み込みシステムなどで壊れている可能性があります。プロセスまたは同等のものを入手し、fileを使用してそのビット数を確認するという一般的な考え方が可能でなければなりません。ルートとして実行している場合、ファイルのパスを経由する代わりに、file $(sudo readlink -e /proc/1/exe)(PID 1はinitである可能性があります。

if file /sbin/init | fgrep 'ELF 64-bit' &>/dev/null; then 
    echo "64-bit" 
else 
    echo "not 64-bit" 
fi 
+0

この方法の問題点は、64ビットカーネルを実行しているときに32ビットの実行可能ファイルを使用できることです。 – Job

+0

@Jobあなたは正しいですが、 'init'(PID 1)は最初のプロセスとして実行されるので、システム全体のビット数を決定すると思います。 –

+0

さて、私は、技術的には、 'init'が64ビットカーネル上で32ビットでも可能であるべきだと思っていますが、どのような"普通の "システムでもあなたのアプローチは大丈夫でしょう。 – Job

15

質問は、あなたが32または64にいるかどうかを知ることによって達成しようとしていることは何ですか?仮想の128ビット環境での結果はどうなりますか?そして、実際にNビットのためにどの部分がテストされていますか? CPUは64ビットモードでの実行をサポートしていますが、環境は32ビットです。さらに、環境自体は混在モードであってもよい。 32ビットのユーザー空間を持つ64ビットカーネルを実行することを検討してください(いくつかの古典的なRISC上で実行されます)。そして、ユーザ空間が均一なビット/実行形式でない場合はどうでしょうか?そのため、getconf LONG_BITはコンパイル方法にもよりますが、同じ意味で使用する必要はありません。

$ /rt64/usr/bin/getconf LONG_BIT 
64 
$ /usr/bin/getconf LONG_BIT 
32 
$ file /usr/bin/getconf /rt64/usr/bin/getconf 
/usr/bin/getconf:  ELF 32-bit MSB executable, SPARC32PLUS, V8+ Required, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.4, not stripped 
/rt64/usr/bin/getconf: ELF 64-bit MSB executable, SPARC V9, relaxed memory ordering, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.4, not stripped 
$ uname -m 
sparc64 
0

私は、ハードウェアを見れば、あなたが探しているものを、私は64ビットのPROCに32ビットにインストールしたマシンを持って、上記のすべてがlshwで、私の場合には

を32ビットを返すだろうがに依存Ubuntu(lshw -c cpu)では、CPUの説明から明らかに64ビットCPUを使用しているので、64ビット版のUbuntuをインストールできました。

/proc/cpuinfoも、lmフラグがロングモードを表しているのと同様に、ハードウェアに関する情報源です。

よろしくお願いいたします。 ジャック。

関連する問題