システムの残りの部分はそのままにして、Linuxカーネルを更新する
私はOpenBSDユーザーです。 OpenBSD FAQ にはこう書かれています：
OpenBSDは完全なシステムであり、同期を保つことを目的としています。カーネルと、個別にアップグレードできるユーティリティではありません。
システムをアップグレードすると、一度にアップグレードできます。カーネルと基本システムが置き換えられます。次に、 サードパーティパッケージ を更新します。 ソースからのコンパイル の場合、カーネルを再コンパイルして起動します。次に、基本システムを再構築し、次に、インストールしたパッケージを再構築します。すべてを最後に再構築してから数週間/月以上経過している場合は、最初にスナップショットをインストールし、そこから再構築します（最新のCVSブランチに従っている場合）。
同期が取れていないカーネル、ベースシステム、サードパーティのパッケージがあると、問題が発生する可能性があり、公式のメーリングリストから深刻な支援を受けることができなくなります。
私はこれで大丈夫です。実際、これがOpenBSDを使用する理由の1つです。それはシステムを一貫したユニットにし、私がそれの精神的な概要を形成することを簡単にします。
Linuxではどうですか？私が知っているほとんどのLinuxには、BSDと同じ意味の「基本システム」がありませんが、ディストリビューションプロバイダーによって組み立てられたパッケージのコレクションがあります。その後、ローカル管理者が追加のソフトウェアを追加し、最初からそこにあったものと後で追加したものとの境界がせいぜいぼやけるようにします。
Linux（一般的に）は、ユーザー空間との強い結合を備えていませんか？カーネルは、他のソフトウェアパッケージと同様に、私の知る限り更新されていますそして、これがまったく可能であると少し混乱します。これに加えて、一部はカスタムカーネル（OpenBSDでは推奨されません）をコンパイルし、ブートメニューに多数のさまざまなカーネルバージョンがリストされていることもあります。
Linuxシステムのさまざまなサブシステムが相互に独立して更新されている場合でも、相互に連携できることを誰または何が保証しますか？
私が尋ねる理由は、このサイトの別のユーザーがmeのLinuxシステムのカーネルを新しいバージョンの「実行可能」に置き換えるかどうか尋ねたからです。 OpenBSD側から来ると、私はそうは言えません、これはシステムを壊さないことを保証することです。
上記の「Linux」は、「Linuxディストリビューション」、カーネル+ユーティリティの省略形として使用しています。
Linus Torvaldsは、ユーザー空間の回帰を引き起こすカーネルの変更に対して非常に strong 意見を持っています（質問「Linuxカーネル：ユーザー空間の破壊）を参照してください 」 = "詳細については）。
ユーザー空間とカーネル間のインターフェースは、システムコールによって提供されます。新しいカーネルでは、より多くのシステムコールを使用でき、既存のアプリケーションに影響を与えない場合は既存のカーネルを変更します。システムコールインターフェイスにフラグパラメーターがある場合、新しいカーネルは新しい機能を新しいビットフラグで公開することがよくあります。このようにして、カーネルは古いアプリケーションとの下位互換性を維持します。
ユーザー空間を壊さずに既存のインターフェースを変更することができなかった場合、拡張機能を提供する追加のシステムコールが追加されました。これが、 dup の3つのバージョンと umount システムコールの2つのバージョンがある理由です。
安定したユーザースペースを確保するという方針が、カーネルの更新によってユーザースペースアプリケーションで問題が発生することはほとんどなく、カーネルのアップグレード後に問題が発生することは通常ないと考えられる理由です。
ただし、カーネルインターフェイスおよびその他の実装の詳細については、同じAPIの安定性は保証されません。 Sysfs（/sys）およびprocsfs（/proc/）低レベルのアプリケーションで使用されるランタイム構成、ハードウェア、ネットワーク、プロセスなどに関するカーネル実装の詳細を公開します。正当な理由がある場合、これらのインターフェイスがカーネルバージョン間で互換性のない方法で変更される可能性があります。変更は、可能であれば非互換性を最小限に抑えようと試み、問題を引き起こす可能性が最も低い方法でアプリケーションがインターフェイスを使用する方法について rules があります。低レベルでないアプリケーションがこれらのインターフェースを使用してはならないため、影響も限定されます。
@ PeterCordesprocfsまたはsysfsの変更により、ディストリビューションの初期化スクリプトで使用されているアプリケーションが破損した場合、問題があるかもしれません。
これは、ディストリビューションがカーネルを更新する方法（長期サポートまたはメインライン）に多少依存しますが、ディストリビューションは通常、更新されたツールを同時に出荷するため、問題は比較的まれです。
@ StephenKitt アップグレードされたユーザースペースでは新しいバージョンのカーネルが必要になる可能性があることを追加しました。その場合、システムは古いカーネルで起動できない可能性があり、そのディストリビューションのリリースノートに記載これは適切な場合です。
LinuxカーネルとLinuxディストリビューションのユーザースペースは、歴史的にGNUプロジェクトによって開発されたユーザーツールによって支配されていましたが、疎結合です。一部はこれが設計によるもので、一部は必要に応じて。
カーネルとベースユーザースペースが一緒に設計および保守されるBSDとは異なり、Linuxカーネルとそのユーザースペースは、さまざまな人々によって開発および保守されています。したがって、コミュニティが望んでいたとしても、それらを緊密に結合することは難しいでしょう。私はそうは思いません。
また、@ sebasthは、Linuxカーネルプロジェクトの主要なポリシーは、ユーザースペースを壊してはならないということを優れた点としています。もちろん、どちらが疎結合を強制する別の要因です。
ただし、ある程度の結合はまだあります。十分に古いLinuxカーネルは、最新のディストリビューションでは動作しません。
私の理解は、Linux isカーネルであり、その他はすべて付随的なものだということです。それらは一般にカーネル自体ではなくlibrariesに関連付けられているため、インストールされた（多くの）パッケージとは無関係にカーネルを確実にアップグレードできます。通常、カーネルバージョンとハードウェアドライバー（GPUドライバーなど）の間のこのような結合のみが表示されます。 Someソフトウェアは特定のバージョンのカーネルとのみ互換性がありますが、それらはそれらのプログラムの個別のドキュメントで指定する必要があります。
現在使用されているパッケージと以前にインストールされたパッケージの2つのカーネルパッケージスイートをシステムにインストールすることは、かなり一般的です。アップグレードする場合、新しいバージョンが適切に機能することを確認した後、最も古いバージョンを削除しても、既知の安全なフォールバックが残っています。たとえば、Red Hat（およびそのいとこ）にはpackage-cleanup --oldkernels --count 2これを自動的に行います。
ここですべての良い議論に加えて、私は役立ついくつかのポイントを追加することがあります。
私たちはすでにカーネルチームのポリシーを知っており、Linuxディストリビューションとして、カーネルソースコードをできるだけ純粋に保つようにしています。つまり、脆弱性が発生した場合やパッチが必要な場合は、カーネルチームに通知してパッチのサポートを試みますが、最終的には最終決定はカーネルチームが行います。
一部のディストリビューションは、他のディストリビューションよりも追加のパッチを追加しますが、上流の開発者からのパッチを維持するという考え方です。明らかに、特別なカーネル構成を必要とするプログラムがあり、特に仮想化とサードパーティのドライバーがあり、通常、両方とも特定のカーネルバージョンまたは少なくとも古くないバージョンでの作業に使用されます...その理由は、最新のカーネル機能で動作するため、古いカーネルで実行しようとすると、正しく動作しない可能性があります。
心に留めておくべきもう1つの要素は、すべてのLinuxディストリビューションにメンテナチームがいることです。つまり、すべてのソフトウェアがシステムと互換性があることを保証します。そのため、ほとんどすべてのディストリビューションに安定版と不安定版があります。開発者は「不安定な」ソフトウェアを使用し、すべてがテストされたときに安定とマークします。その後、通常のユーザーがパッケージをアップグレードできるようになります。そのため、通常のユーザーであると尋ねた人が90％安全であれば、ソフトウェアは十分にテストされています。 。
つまり、誰が、コミュニティが、そして何が一般的なアプローチであるべきか、私たちはソフトウェアを一緒に動作させ、システムを壊さないようにする必要があるので、Filesystem Hierarchy Standardのようないくつかの標準に従うようにしています。