Ubuntu升级过程如何工作？

在操作系统仍在运行的情况下，Ubuntu如何无缝升级到较新的发行版？我从10.10升级到11.04，并且之前已经升级了好几次，就像运行update-manager -d并下载并安装它们，然后重新启动一样简单。

但是，这到底如何工作？升级管理器在仍在使用时如何能够更新操作系统？

根据我的经验，我会假设程序包和模块在运行时将它们保存在内存中，不会过多地参考硬盘驱动器上的副本。如果您在ubuntu中运行程序，然后在运行时删除相关软件包，则可以看到此信息。它会继续运行，但是如果关闭它，将无法重新启动它。

我认为发行版升级也会发生同样的情况。即使已删除并替换为新软件包，所有与ubuntu原始版本相关的软件包仍在运行，因此当它们最终在系统重新启动时停止时，新软件包将接管。

这里对过程进行更详细的描述。抱歉，文本太长了。

我的经验来自Debian，最初是为Ubuntu开发的整个打包和升级系统的发明。每天的Ubuntu安全升级对应于运行apt-get upgrade，通常不会删除任何软件。大版本升级对应于apt-get dist-upgrade可以完全交换软件包的时间。

实际上，发行版升级期间通常不会交换非常低级别的组件。升级后，您应该立即在/ boot目录中找到两个内核和initrd映像。这是因为与程序不同，内核组件之间的互换性不是很好。如果需要在升级期间加载新的设备驱动程序，则这些驱动程序必须与正在运行的内核兼容。系统使用新内核启动后，可以删除旧内核。上一次我必须手动完成此操作时，我不知道当前的更新程序如何处理此问题。这是顺便说一句。主要原因是内核映像在文件名中带有版本号的原因-因此您可以同时安装不同的内核版本。与模块路径相同（/ lib / modules / ...）

从依赖关系层次结构中最低的软件包开始，一个软件包一个接一个地升级。这些通常是程序库，如libc和其他程序库。但是，更新包的顺序不是硬编码的，而是在解决包依赖关系时动态计算的。在大多数情况下，旧程序可以与新库一起使用，因此，如果这些库首先被替换就不会有问题。

您必须在这里了解到，系统区分手动安装的软件包（即您直接要求自己安装的软件包，即铬）和自动安装的软件包，仅安装这些软件包以满足手动安装的软件包的依赖关系（以及这些依赖关系的依赖关系） ）。

对于每个手动安装的程序，更新程序仅查找较新的版本。通常，这些程序只是诸如“ ubuntu-desktop”之类的元软件包，其中不包含任何数据，而仅包含依赖项。根据直接更新（手动请求）程序的要求，将引入依赖库的新版本。更新程序将始终尝试安装任何依赖程序包的最新可用版本（在升级过程中，不仅是发行版升级）。

在库升级之后以及程序本身升级之前的时间内，无法启动无法与新库版本一起使用的程序。如果这些程序在库升级之前就已经在运行，则它们将继续运行，因为旧的库版本会一直保留在内存中，只要它仍在使用中。在升级之前启动的程序也是如此。这些将不会提供新功能，直到它们终止并重新启动。

更新后，某些库（或一般的依赖项）将被孤立。这些是旧程序版本所需的库，但新版本不再需要。由于这些软件包被标记为自动安装，并且由于不再有手动安装的prgram与它们相关，因此可以轻松地找到和删除这些软件包。您甚至可以将其视为更新过程的最后一步（更新程序说“删除过时的软件包”或类似内容）。

将安装某些软件包，而以前从未安装过，只​​是简单的新依赖项，这些依赖项被标记为自动安装，并且在将来对它们的需求消失时可以将其删除。

该机制甚至允许交换整个用户程序。例如，从Gnome2切换到Unity。由于两者都是ubuntu-desktop的自动依赖项，因此它是为数不多的几个软件包之一，因此实际上首先要求提供新版本。

程序通常不依赖于特定版本的OS内核，因此它们通常可以与运行中的内核正常工作。

除了所有这些，我怀疑 Ubuntu更新程序会添加一些特定的修复程序和变通办法，以避开这种理论破坏的情况。

正如您在更新过程中看到的那样，在某些情况下，系统只能在有限的一部分中使用。是否应走的东西，你在更新过程中错将最有可能留下一个破碎系统。由于升级程序也可能会受到影响，因此即使是通常也很难修复的产品。请记住，具有破坏性依赖关系的程序可以继续运行，但不能重新启动，只要破坏了依赖关系，更新程序也是如此。

您可以使用命令行程序apt-mark来找出哪些软件包被标记为手动安装，哪些已被自动安装。您也可以使用同一程序切换这些标记。这将直接影响更新过程。

在更复杂的软件设置中，更新程序有时会要求您手动解决依赖性。即，当一个手动安装的程序被更新并请求一个新版本的库时，而另一个手动安装的程序则依赖于该库的旧版本，因此无法与新库一起使用。然后，您将不得不做出选择，要么放弃其中一个程序，要么不升级这两个程序。由于依赖关系通常很复杂，因此很快就会变得非常混乱（您可能听说过“依赖关系地狱”一词）。

现在来具体问题：

1. 当低级基础结构发生更改（低级结构，如内核，驱动程序，库等用户不直接与之交互的东西）时，不赞成使用的二进制文件会如何处理？
   • 好...我已经讲完了
2. 完全弃用的应用程序会发生什么情况？例如，Unity 2D（或放弃其软件包不在新存储库中的任何其他软件/放弃/没有维护者）。
   • 如果该应用程序曾经是手动安装的，它将保留在系统中，通常会导致我描述的依赖关系。
3. ubuntu-desktop是一个元软件包，可将默认的Ubuntu应用程序作为依赖项。如果我删除了Firefox并安装了Chrome，是否仍会在升级过程中加入Firefox？
   • 只要它是新版本的标准浏览器，就可以。铬也将升级。我不确定是否可以在不删除ubuntu-desktop的情况下删除Firefox。请注意，除了严格的依赖关系外，软件包系统还了解建议的概念，在该建议书中，软件通常会像依赖关系一样安装，但以后可以卸载而不会影响其自身的唯一依赖关系。
4. 而且，如果单个应用程序过去曾经依赖于package-x而在新版本中不再依赖它会发生什么；是否将package-x与其他软件包一起升级（尽管是孤立的）？
   • 不。

请问我是否还有其他问题。

在文件系统级别，与Windows不同，在Unix系统上，您可以删除打开的文件。删除只是删除文件的名称，而不是删除其内容，因此，任何仍打开文件的程序仍可以访问文件，直到他们关闭文件，然后才释放数据。

因此，升级过程只需删除旧文件，将它们替换为新文件，然后对于某些系统服务，重新启动它们，以便新版本正在运行。

如果不重新启动整个计算机，则有一个或两个组件无法重新启动，因此在升级这些组件后，系统会提示您重新启动，因此您将使用新版本。

Linux仍在使用时如何更新自身？

主要是因为Linux（以及它的大多数发行版）都是以这种方式设计的。能够在运行的系统上升级软件包是大多数基于Linux的发行版的目标。

在Linux中，没有什么可以阻止程序包管理器进程写入磁盘上的文件的，即使该文件当前是由应用程序打开的，或者该文件是当前正在运行的可执行文件或共享代码库。在非常低的级别上，有一些锁可以保护在一次写/读操作期间对文件的访问，但是这些锁的设计时间永远不会超过毫秒，并且任何其他试图写入同一文件的应用程序只会等待这些毫秒。

您可以在可执行文件运行时对其进行替换，而该文件实际上不会对正在运行的进程执行任何操作，因为该进程不再需要磁盘上的文件-它的所有代码都已加载到内存中。

这就是为什么在Linux上，即使您可以在运行时升级应用程序，升级也不会真正生效，直到重新启动您升级的应用程序。在升级诸如系统服务之类的后台进程时，该服务将需要重新启动。如果您已经升级了内核，则意味着重启。

运行时不会替换程序的文件会使某些程序中断吗？

Linux发行版中的某些软件包将包含安装说明，指导软件包管理器在软件包更新时停止某些系统服务，并在更新完成后重新启动这些服务。这样可以防止出现以下情况：例如，特定服务的配置文件已更新，并且该服务的运行版本可能无法应对较新版本的配置文件。

通常，常规用户应用程序不需要运行任何配置文件，除了它自己生成的文件以及放置在用户主目录等位置的文件外。因此，更新时包管理器将不会触及这些。

这类似于另一个功能。希望这有助于了解基本过程。

我指的是操作系统启动时“切换根目录”的功能。

操作系统启动时，根文件系统（读取：“ /”）最初仅在RAM中可用。在此引导过程运行时，它将/从RAM切换到硬盘上的/文件系统。