セントス7カーネルのアップグレード事故を覚えておいてください
シーン＃＃
同社は保証待機3の評価を行い、システムの脆弱性の検出中にカーネルに脆弱性があり、アップグレードする必要があることを発見しました。
| 名前 | バージョン |
|---|---|
| アップグレード前のカーネル | CentOSLinux（3.10.0-327.el7.x86_64）7（コア） |
| アップグレード後のカーネル | CentOSLinux（3.10.0-957.1.3.el7.x86_64）7（コア） |
正しい操作プロセス##
アップグレード方法###
アップグレード方法は非常に簡単です。対応するバージョンのカーネルrpmパッケージを見つけて、yumまたはrpmを直接使用してインストールします。このプロセスでは、パッケージ間のいくつかの依存関係を処理する必要がある場合があります。
$ yum install -y kernel-3.10.0-957.1.3.el7.x86_64.rpm kernel-headers-3.10.0-957.el7.x86_64.rpm kernel-tools-3.10.0-957.1.3.el7.x86_64.rpm kernel-tools-libs-3.10.0-957.1.3.el7.x86_64.rpm
カーネルの効果的な新しいバージョン###
新しいバージョンのカーネルをインストールした後、次のように進める必要があります。そうしないと、私のようなサーバーを再起動するときにピットを踏むことになります。
**次の操作の目的は、サーバーがgrubを介して起動したときにロードされるカーネルのバージョンを変更することです。 ****
-
現在インストールされているシステムカーネルを表示する
$ rpm -qa kernel* kernel-3.10.0-957.1.3.el7.x86_64 kernel-headers-3.10.0-957.el7.x86_64 kernel-tools-3.10.0-957.1.3.el7.x86_64 kernel-tools-libs-3.10.0-957.1.3.el7.x86_64 -
現在のシステムのデフォルトのカーネルバージョンを確認してください。結果は次のようになります。
$ grub2-editenv list＃結果1：関連情報なしsaved_entry = 0＃結果2：現在実行中のシステムバージョンsaved_entry = CentOS Linux（3.10.0-327.el7.x86_64）7（コア） -
システムの起動時にデフォルトのカーネルバージョンを切り替えます。
$ grub2-set-default 'CentOS Linux (3.10.0-957.1.3.el7.x86_64) 7 (Core)' -
その後、サーバーをスムーズに再起動し、再起動後にシステム情報を確認できます。
$ uname-aまたは$ cat / proc / version Linuxバージョン3.10.0-957.1.3.el7.x86_64（[email protected]）（gccバージョン4.8.5 20150623（Red Hat 4.8.5-36 ）（GCC））＃1 SMP Thu Nov 29 14:49:43 UTC 2018
これでカーネルのアップグレードが完了しました。
事故＃＃
正しい操作方法があるので、間違えることがよくあります。カーネルのアップグレードは初めてだったので、スムーズにピットを踏みました。エキサイティングなプロセスを見下ろしてください：
再起動＃＃＃
新しいバージョンのカーネルをインストールした後、サーバーを再起動して有効にする必要があります。最初の操作は通常のrpmパッケージのアップグレードとして処理されます。インストールが完了すると、「init 6」が実行されてサーバーが再起動されます。結果は、次のように悲惨です。
ここに留まって動かなかった。プロンプトが表示されてもエラーは報告されなかった。Enterキーを押すだけで、次のシーンが表示されます。
対応するバージョンのカーネルが見つかりません！ ！ ！
WTF！！！
問題を解く＃＃＃
注意深く分析した後、プロンプトメッセージに「3.10.0-327.el7.x86_64」バージョンのカーネルが見つからないことが示されます。その場合は、Baidu（google）に任せてください。キーワード「centos7カーネルのアップグレードと再起動でカーネルが見つかりません」、次の記事を見つけてください。
- カーネルの再インストール：[http://blog.51cto.com/zhaoqifly/1841868]（http://blog.51cto.com/zhaoqifly/1841868）（この方法は推奨されません）
- カーネルの起動シーケンスを変更し、不要なカーネルを削除します：[https://www.cnblogs.com/anliven/p/7944842.html]（https://www.cnblogs.com/anliven/p/7944842.html）（アイデアのソース）
- centos7でカーネルのブートシーケンスを変更する方法：[https://www.cnblogs.com/cnsong/p/7058000.html]（https://www.cnblogs.com/cnsong/p/7058000.html）（正しい操作プロセスのリファレンスドキュメント）
最初と2番目のドキュメントを読んだ後、おそらく修復の原則、つまりカーネルのブートシーケンスを変更することを理解しました。最初の記事での元のシステムカーネルの再インストールは、このカーネルのアップグレードにはほとんど意味がありませんが、2番目は注意です。私はコアです-Linuxシステムのすべてがファイルです！
サーバーがクラッシュする前にgrubコマンドラインを介してカーネルブートシーケンスを変更することが可能であるため、クラッシュ後にレスキューモードを介してgrubの変更またはその他の方法を確実に入力できます。
問題の再発###
この問題が発生したのは初めてだったので、仮想マシンを手元に置いていたので、試してみるという精神でエラーシーンを再現し、仮想マシンを再起動してカーネル選択インターフェイスにアクセスしました。
ヒント：「** e **」は、現在選択されているアイテムを編集します。とにかく、それは仮想マシンであり、何気なくそれを行い、決定的に編集状態に入ります。
カーネル情報が表示されたばかりで、とてもうれしかったので、ここでシステムバージョン情報を変更して、次の情報を読み続けてみませんか。
すべてを一度に変更するだけで、システムを再インストールすることが重要です（ただし、現在のサーバーが特に重要なサービスで展開されていない場合は、より厳密にする必要があります）。上の図の赤いボックスの情報を新しいバージョン「3.10.0-957.1.3.el7.x86_64」に変更してから、Ctrl-xを押してシステム読み込みインターフェイスに入ると、すぐに安心します。
システムの起動が完了するのを待ち、ログインしてステータスを確認します。すべて正常です。 ！ ！
実践からの本当の知識！ ！ ！ （追記：大丈夫です、いじりまわさないでください、それをする前に一生懸命勉強しなければなりません!!!）
Bでドキュメントを投稿してください！ ！ ！
( adsbygoogle = window.adsbygoogle || []).push({});
Recommended Posts