Ubuntuのアップグレードプロセスはどのように機能しますか？

Ubuntuは、オペレーティングシステムを実行したまま、新しいディストリビューションにシームレスにアップグレードする方法を教えてください。10.10から11.04にアップグレードしていますが、以前に何度かアップグレードしたことがあり、update-manager -dを実行してそれらをダウンロードしてインストールし、再起動するだけの簡単な方法です。

これはどのように正確に機能しますか？アップグレードマネージャは、オペレーティングシステムがまだ使用されているときに、それをどのように更新できますか？

私の経験から、パッケージとモジュールが実行されている間、それらはメモリに保持され、ハードドライブ上のコピーをあまり参照しないと思います。これは、ubuntuでプログラムを実行し、実行中に関連パッケージを削除すると確認できます。実行は継続しますが、閉じると再起動できません。

ディストリビューションのアップグレードでも同じことが起こると思います。ubuntuの元のバージョンに関連するすべてのパッケージは、削除されて新しいパッケージに置き換えられた後も引き続き実行されているため、システムの再起動時に最終的に停止すると、新しいパッケージが引き継ぎます。

ここでプロセスのより詳細な説明。テキストが長くなりすぎて申し訳ありません。

私の経験は、Ubuntuで使用されているパッケージングおよびアップグレードシステム全体がもともと発明されたDebianに由来しています。毎日のUbuntuセキュリティアップグレードは、apt-get upgrade通常はソフトウェアを削除しない実行に対応しています。大きなリリースのアップグレードは、apt-get dist-upgradeソフトウェアパッケージを完全に交換できる期間に対応しています。

実際、非常に低レベルのコンポーネントは通常、リリースのアップグレード中に交換されません。アップグレード直後に、2つのカーネルとinitrdイメージが/ bootディレクトリにあるはずです。これは、プログラムとは異なり、カーネルコンポーネントがうまく交換できないためです。アップグレード中に新しいデバイスドライバーを読み込む必要が生じた場合、それらは実行中のカーネルと互換性がある必要があります。システムが新しいカーネルで起動した後、古いカーネルを削除できます。前回、これを手動で行う必要があることを確認したとき、現在のアップデーターがこれをどのように処理するのかわかりません。これはBTWです。主な理由、カーネルイメージのファイル名にバージョン番号が記載されている主な理由-異なるバージョンのカーネルを同時にインストールできます。モジュールパスも同じ（/ lib / modules / ...）

ソフトウェアパッケージは、依存関係hirarchyで最も低いパッケージから順に1つずつアップグレードされます。これらは通常、libcなどのプログラムライブラリです。ただし、パッケージの更新順序はハードコーディングされておらず、パッケージの依存関係が解決されるときに動的に計算されます。ほとんどの場合、古いプログラムは新しいライブラリで機能するので、それらのライブラリが最初に置き換えられても問題はありません。

ここでは、システムが手動でインストールされたパッケージ（つまり、直接インストールを要求したパッケージ、つまりchromium）と、手動でインストールされたパッケージの依存関係（およびそれらの依存関係の依存関係のみを満たすためにインストールされた自動インストールパッケージ）を区別することを理解する必要があります。 ）。

手動でインストールされたプログラムごとに、アップデータは新しいバージョンを探します。多くの場合、これらのプログラムは "ubuntu-desktop"のようなメタパッケージであり、データを含まず、依存関係のみを含みます。依存ライブラリの新しいバージョンは、直接更新された（手動で要求された）プログラムによって要求されたときに取り込まれます。アップデーターは常に、依存するパッケージの最新の使用可能なバージョンをインストールしようとします（リリースのアップグレードだけでなく、アップグレード中も）。

新しいライブラリバージョンで機能しないプログラムは、ライブラリがアップグレードされた後、プログラム自体もアップグレードされる前に起動できません。ただし、ライブラリのアップグレード前にこれらのプログラムが既に実行されている場合は、古いライブラリバージョンが使用されている限りメモリに残っているため、引き続き実行されます。アップグレードされる前に開始されたプログラムも同様です。これらは、終了して再起動するまで新しい機能を提供しません。

更新後、一部のライブラリ（または一般的な依存関係）は孤立します。これらは、古いバージョンのプログラムでは必要でしたが、新しいバージョンでは不要になったライブラリです。これらのパッケージは自動的にインストールされるものとしてマークされており、手動でインストールされたprgramはそれらに関連していないため、これらのパッケージは簡単に見つけて削除できます。これを更新プロセスの最後のステップとして観察することもできます（アップデーターは「廃止されたパッケージの削除」など）。

一部のパッケージはインストールされますが、以前にインストールされていない場合、それらは単に新しい依存関係であり、自動的にインストールされるようにマークされ、将来の要件がなくなった場合に削除できます。

このメカニズムにより、ユーザープログラム全体を交換することもできます。たとえば、Gnome2からUnityに切り替えるようなものです。どちらもubuntu-desktopの自動依存関係にすぎないため、そもそも新しいバージョンが実際に要求される数少ないパッケージの1つです。

プログラムは通常、OSカーネルの特定のバージョンに依存しないため、通常、実行中のカーネルで正常に動作します。

別にこのすべてから、私は疑う Ubuntuのアップデータを回避状況この理論の休憩に、ミックスにいくつかの特定の修正と回避策をスローします。

更新中にわかるように、システムが限られた部分でしか使用できないという非常に良好な状態があります。更新中に問題が発生した場合は、システムが壊れている可能性があります。多くの場合、アップグレードプログラムも影響を受ける可能性があるため、簡単に修復できないものです。依存関係が壊れているプログラムは引き続き機能しますが、再起動できません。依存関係が壊れている限り、これはアップデーターにも当てはまります。

コマンドラインプログラムapt-markを使用して、手動でインストールされたとマークされているパッケージと自動的にインストールされたパッケージを見つけることができます。同じプログラムを使用してこれらのマークを切り替えることもできます。これは、更新プロセスに直接影響します。

より複雑なソフトウェア設定では、アップデーターは依存関係を手動で解決するように要求することがあります。つまり、手動でインストールされたプログラムが更新されて新しいバージョンのライブラリを要求し、手動でインストールされた別のプログラムが同じライブラリの古いバージョンに依存しているため、新しいライブラリで動作できない場合です。次に、これらのプログラムのいずれかを放棄するか、両方のアップグレードを控えるかを選択する必要があります。依存関係はしばしば複雑なので、これは非常に乱雑に非常に速くなる可能性があります（「依存関係の地獄」という言葉を聞いたことがあるかもしれません）。

ここで、特定の質問に：

1. 低レベルのインフラストラクチャが変更された場合（カーネル、ドライバ、ライブラリなど、ユーザーが直接操作しないものなどの低レベル）、非推奨のバイナリはどうなりますか？
   • わかった...これはすでにカバーした
2. 完全に廃止されたアプリはどうなりますか？たとえば、Unity 2D（または、パッケージが新しいレポジトリにない、放棄された/メンテナがいない他のソフトウェア）。
   • アプリが手動でインストールされた場合、システムに残り、私が説明した依存関係の地獄を引き起こすことがよくあります。
3. ubuntu-desktopは、デフォルトのUbuntuアプリケーションを依存関係としてプルするメタパッケージです。Firefoxを削除してChromeをインストールした場合、Firefoxはアップグレードの一部として引き続き組み込まれますか？
   • 新しいリリースの標準ブラウザである限り、はい。Chromiumもアップグレードされます。ubuntu-desktopを削除せずにFirefoxを削除できるかどうかはわかりません。厳密な依存関係は別として、パッケージシステムは推奨の概念も知っていることに注意してください。ソフトウェアは通常、依存関係のようにインストールされますが、独自の依存関係以外に影響を与えることなく後でアンインストールできます。
4. さらに、単一のアプリがpackage-xに依存していたが、新しいリリースでは依存しなくなった場合はどうなりますか。孤立しているにもかかわらず、package-xは残りのパッケージと一緒にアップグレードされますか？
   • いいえ。

他にご不明な点がありましたら、私にお尋ねください。

ファイルシステムレベルでは、Windowsとは異なり、Unixシステムでは開いているファイルを削除できます。削除しても、ファイルの内容ではなくファイルの名前が削除されるだけなので、ファイルを開いたままのプログラムは、ファイルを閉じるまでファイルにアクセスできます。その後、データが解放されます。

したがって、アップグレードプロセスでは、古いファイルが削除され、新しいファイルに置き換えられます。特定のシステムサービスでは、再起動して新しいバージョンが実行されるようにします。

コンピュータ全体を再起動しないと再起動できないコンポーネントが1つまたは2つあるため、それらをアップグレードした後、新しいバージョンを使用するために再起動するように求められます。

Linuxがまだ使用されている間に、Linuxをどのように更新することができますか？

主な理由は、Linux（およびほとんどのディストリビューション）が単純にそのように設計されているためです。実行中のシステムでパッケージをアップグレードできることは、ほとんどのLinuxベースのディストリビューションの目標です。

Linuxでは、ファイルがアプリケーションによって現在開かれているか、ファイルが現在実行中のコードの実行可能ライブラリまたは共有ライブラリである場合でも、パッケージマネージャープロセスがディスク上のファイルに書き込むのを妨げるものはありません。非常に低レベルでは、単一の書き込み/読み取り操作中にファイルへのアクセスを保護するロックがありますが、これらは数ミリ秒以上保持されるように設計されておらず、他のアプリケーションが同じファイルに書き込もうとすることはありません単にそれらのミリ秒を待ちます。

実行中に実行可能ファイルを置き換えることができますが、実行中のプロセスに対して実際には何も実行しません。これは、プロセスがディスク上のファイルを必要としないためです。そのコードはすべてメモリに読み込まれています。

そのため、Linuxでは、実行中にアプリケーションをアップグレードできますが、アップグレードしたアプリケーションが再起動されるまで、アップグレードは実際には有効になりません。システムサービスなどのバックグラウンドプロセスをアップグレードする場合、そのサービスを再起動する必要があります。カーネルをアップグレードした場合、これは再起動を意味します。

プログラムの実行中にプログラムのファイルを置き換えると、一部のプログラムが壊れませんか？

Linuxディストリビューションの一部のパッケージには、パッケージの更新中に特定のシステムサービスを停止し、更新の完了後にそれらのサービスを再起動するようにパッケージマネージャーに指示するインストール手順が含まれています。これにより、たとえば、特定のサービスの構成ファイルが更新され、実行中のバージョンのサービスが新しいバージョンの構成ファイルに対応できない可能性があります。

一般に、通常のユーザーアプリケーションは、それ自体が生成し、ユーザーのホームディレクトリなどの場所に配置するファイルを除いて、構成ファイルを実行する必要はありません。そのため、更新時にパッケージマネージャーがこれらに触れることはありません。

これは別の機能に似ています。これが基本的なプロセスの理解に役立つことを願っています。

私は、オペレーティングシステムの起動時に「ルートを切り替える」機能について言及しています。

オペレーティングシステムが起動しているとき、ルートファイルシステム（読み取り： "/"）は、最初はRAMでのみ使用できます。このブートプロセスの実行中に、RAMから/ハードディスクの/ファイルシステムに/が切り替わります。