uname is broken：現在実行中のカーネルを確認するにはどうすればよいですか？

13

> uname -r
FATAL: kernel too old
> cat /proc/cmdline
FATAL: kernel too old

/ bootには3つの* .vmlinuz-linuxファイルがあります。現在実行中のカーネルを確認するにはどうすればよいですか？

最小限のシェルを備えた限られた環境で実行していることに注意してください。私も試しました：

> sh -c 'read l < /proc/version; echo $l'
FATAL: kernel too old
> dd if=/proc/version
FATAL: kernel too old

何かご意見は？

linux glibc

— ウィリアム・パーセル
ソース

リブート。GRUBがインストールされている場合は、問題を解決するためのオプションを選択できます。または、ライブCDまたはUSBを使用します

— ...-jcm69

2

私は興味がありますが、どうやって起動したのですか？で、それ何？いくつかの重要な情報が欠落しているようです。これはレスキューシェルですか？詳細を教えてください。

— リザード

クロムがインストールされている場合は、以下を参照してくださいchrome://system/

— 。– GAD3R

はい、それはレスキューシェルです。glibcを含む多くのパッケージをアップグレードしていました。レスキューシェルを実行しているデーモンはまだ生きており、ポートでリッスンしているので、そこに入ることができました。

— ウィリアムパーセル

1

マシンがハード再起動された（たとえば、誰かがボタンを押した）ようで、これは学術的な問題になっています。それは興味深い状態であり、私は何を探すべきかについてのいくつかのハードデータが好きだったでしょうが、私は持ち帰りがおそらくあると思います：glibcをアップグレードする前にカーネルをアップグレードしてリブートします。

— ウィリアムパーセル

19

libc（最も基本的なシステムライブラリ）をアップグレードしましたが、プログラムは動作しません。正確には、動的にリンクされたプログラムは機能しません。

特定のシナリオでは、再起動が機能するはずです。現在インストールされているlibcには新しいカーネルが必要です。再起動する場合は、新しいカーネルを入手する必要があります。

実行中のシェルがある限り、多くの場合、回復する方法がありますが、計画していなかった場合は注意が必要です。シェルがない場合、通常は再起動以外の解決策はありません。

ここでは、リブートしないと回復できない場合がありますが、実行中のカーネルを少なくとも簡単に見つけることができます。/proc/version外部コマンドを必要としない読み取り方法を使用してください。

read v </proc/version; echo $v
echo $(</proc/version)               # in zsh/bash/ksh

古いlibcのコピーがまだある場合は、それを使用してプログラムを実行できます。たとえば、古いlibcがあり、/old/libこの古いlibcで動作する実行可能ファイルがある/old/bin場合、次を実行できます。

LD_LIBRARY_PATH=/old/lib /old/lib/ld-linux.so.2 /old/bin/uname

静的にリンクされたバイナリがある場合でも、それらは機能します。この種の問題には、統計的にリンクされたシステムユーティリティをインストールすることをお勧めします（ただし、問題が始まる前にインストールする必要があります）。たとえば、Debian / Ubuntu / Mint /…で、busybox-static（シェルを含む基本的なLinuxコマンドラインツールのコレクション）、sash（いくつかの追加ビルトインシェル）、zsh-static（シェルだけですが、かなりの数の便利なツールが組み込まれています）。

busybox-static uname
sash -c '-cat /proc/version'
zsh-static -c '</proc/version'

— ジル「SO-悪であるのをやめる」
ソース

再起動する場合、その新しいカーネルを取得する必要があります。またははるかに可能性が高いと思われる黒い画面

— 猫

LD_LIBRARY_PATHを割り当てることをお勧めします。残念ながら、レスキューシェルは内部読み取りを持たず、リダイレクトを許可せず、環境変数の割り当てさえ許可しません！envの割り当てをシェルに取得するためのバグを提出しています。

— ウィリアムパーセル

6

これは、ライブラリがサポートするためにコンパイルされているものよりも古いカーネルで実行されている場合、glibcがスローするエラーのようです。エラーメッセージは、次のDL_SYSDEP_OSCHECK(FATAL)マクロにあります。sysdeps/unix/sysv/linux/dl-osinfo.h

これにはコンパイル時オプションがあります。

--enable-kernel=version
このオプションは現在、GNU / Linuxシステムでのみ有用です。バージョンパラメータの形式はXYZである必要があり、生成されたライブラリがサポートする予定のLinuxカーネルの最小バージョンを記述します。バージョン番号が大きいほど、追加される互換性コードは少なくなり、コードは高速になります。

何らかの理由で、古いカーネルを使用しているが、古いカーネルをサポートしていないglibcをインストールしたシステムを実行しているようです。どのようなシステムであるかについての情報なしでは、どのように入手したかを知ることは困難ですが、ライブラリは更新されているがカーネルは更新されていない場合に起こる可能性があります。

file 実行可能ファイルまたはライブラリに必要な最小バージョンが表示されているようですが（もちろん、実行するには作業ライブラリが必要です）：

/lib/x86_64-linux-gnu/libc-2.23.so: ELF 64-bit LSB shared object, x86-64, ..., for GNU/Linux 2.6.32, stripped

私の準現在のDebianシステムでは、2.6.32チェックしたすべてのバイナリで必要なカーネルバージョンが上記のとおりであるため、カーネルバージョンで問題が発生することはほとんどありません。

— イルカチュウ
ソース

5

これで試してください：

cat /proc/version

— スヴェン
ソース

> cat /proc/version FATAL: kernel too old

— ウィリアムパーセル

これは良い考えですが、互換性のないglibcではcat利用できません。

— ウィリアムパーセル

私も同じくらい恐れていましたが、試してみる価値がありました

— スベン

猫がいないからといって？なぜvimまたはnano / proc / versionではありませんか？

— jesse_b

方法：head /proc/version|| tail /proc/version|| sed '1q;d' /proc/version

— jesse_b

0

stringsコマンドを使用して、vmlinuzファイルから印刷可能な情報を抽出します。

strings vmlinuz | grep version

サンプル出力：

4.9.0-6-amd64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516
(Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02)

— GAD3R
ソース