do-release-upgrade 和 Ubiquity 中的 GUI“升级”选项有什么区别?

do-release-upgrade 和 Ubiquity 中的 GUI“升级”选项有什么区别?

在实时会话中选择此选项与do-release-upgrade在常规安装中运行有什么不同?如果不同,有什么不同?

(请忽略版本 - 我实际上是从 12.04 升级到 16.04)

在此处输入图片描述

我安装了很多软件包并配置了很多服务。

我不知何故有这样的印象:至少基于 iso 的方法(ubiquity)或多或少会解压一个新的基本系统替换,然后安装大约相同的一组软件包,但大多数配置只是被替换(没有合并等)。

我宁愿使用尽可能保留我的配置的方法。

答案1

由于没有其他答案,我将写下我在过去几天尝试这两种方法以及过去各种场合所收集到的信息。

  1. Ubiquity/GUI 升级会记录之前安装的软件包。然后,它会继续安装一个新的基础系统,并主要替换旧系统。之后,将安装同一组软件包。在此过程中,许多 /etc 文件(例如 /var/www)会被重置。

对于具有自定义配置或数据的服务器来说,这种方法不是很好,但它非常快并且保证系统正确现代化。

  1. do-release-upgrade方法从系统内部运行。它执行一些自定义过渡脚本,但大多数情况下只是apt-get upgrade过渡到下一个 LTS 系统。如果您像我一样落后 2 个 LTS 版本,则需要运行两次。安装软件包时会检测默认配置文件之间的差异。

如果一切顺利,许多自定义配置将被保留或由升级指出,每个配置都需要少量的手动工作。

缺点是这个过程需要很长时间,并且可能需要多次手动干预。试图找出新旧配置文件之间的差异可能会变得很技术化。结果可能是最新的 Ubuntu 技术与旧软件包和配置之间出现奇怪的交叉。

关于运行和图形会话的一些注意事项do-release-upgrade:从图形用户界面运行它可能不是一个好主意。当软件包从其下方升级时,图形会话会以各种方式受到折磨。明智的是,它将do-release-upgrade自己包装在screen会话中。(我无法重新连接到会话screen。幸运的是,我还有一个tmux运行在上面的。在获得旧版本后,tmux我能够从文本控制台恢复。)

相关内容