多年来，我一直使用此处记录的“不支持”的 yum 更新方法
https://fedoraproject.org/wiki/Upgrading_Fedora_using_package_manager
除了 Fedora 16 或 17 左右的 systemd 灾难之外，这种方法一直像魅力一样有效，并尽可能地保持系统在线。您确实需要注意依赖关系，并且可能需要解决问题和恢复软件包，但它奏效了。我有几台（虚拟）机器，使用这种方法从 Fedora 1 以连续链升级到 Fedora 23（尽管 systemd 需要一些认真的恢复工作）。对我来说，这是远程系统的最佳方法（就像几小时的驾驶时间一样），在升级过程中您根本无法让它们离线。Fed-up 远胜于“preupgrade”，但对我来说毫无价值，因为它使用了 anaconda 并且在升级过程中使机器离线，而且如果出现任何问题，您可能会被远程机器迅速搞砸。
除了该 URL 中记录的直接手动“dnf --releasver=”方法之外，上面的 URL 指出他们已经创建了一个（是的，不支持的）脚本来自动化大部分内容。那是 fedora-upgrade 软件包。是的，它是“不支持的”，但应该支持。我遇到的唯一故障是依赖项错误，这些错误不应该一开始就出现在 rpm 存储库中。诸如循环依赖关系和损坏的过时依赖关系。如果他们实际支持 fedora-upgrade 过程，他们将被迫修复那些损坏的依赖关系。幸运的是，这些问题很容易解决，并且几乎可以在不停机或失去对远程服务器的控制的情况下进行干净的升级。只需备份已安装软件包的数据库，然后删除任何有问题的软件包（通常是 rpmfusion），然后在升级后重新安装即可。
多年来，我一直使用此处记录的“不支持”的 yum 更新方法
https://fedoraproject.org/wiki/Upgrading_Fedora_using_package_manager
除了 Fedora 16 或 17 左右的 systemd 灾难之外，这种方法一直像魅力一样有效，并尽可能地保持系统在线。您确实需要注意依赖关系，并且可能需要解决问题和恢复软件包，但它奏效了。我有几台（虚拟）机器，使用这种方法从 Fedora 1 以连续链升级到 Fedora 23（尽管 systemd 需要一些认真的恢复工作）。对我来说，这是远程系统的最佳方法（就像几小时的驾驶时间一样），在升级过程中您根本无法让它们离线。Fed-up 远胜于“preupgrade”，但对我来说毫无价值，因为它使用了 anaconda 并且在升级过程中使机器离线，而且如果出现任何问题，您可能会被远程机器迅速搞砸。
除了该 URL 中记录的直接手动“dnf --releasver=”方法之外，上面的 URL 指出他们已经创建了一个（是的，不支持的）脚本来自动化大部分内容。那是 fedora-upgrade 软件包。是的，它是“不支持的”，但应该支持。我遇到的唯一故障是依赖项错误，这些错误不应该一开始就出现在 rpm 存储库中。诸如循环依赖关系和损坏的过时依赖关系。如果他们实际支持 fedora-upgrade 过程，他们将被迫修复那些损坏的依赖关系。幸运的是，这些问题很容易解决，并且几乎可以在不停机或失去对远程服务器的控制的情况下进行干净的升级。只需备份已安装软件包的数据库，然后删除任何有问题的软件包（通常是 rpmfusion），然后在升级后重新安装即可。