Fedora/Redhat/CentOS 安装器 Anaconda 简要分析

Anaconda 安装器介绍

Anaconda简介

  Anaconda是Fedora，Red Hat Enterprise Linux及其衍生产品中使用的操作系统安装程序。它由Python模块和脚本以及一些其他文件组成，如Gtk小部件（用C编写），systemd单元和dracut库。它们共同构成了一个工具，允许用户设置生成（目标）系统的参数，然后在机器上安装设置的系统。安装过程有四个主要步骤：

• 安装目标准备（通常是磁盘分区）

• 包和数据安装

• 引导加载程序安装和配置

• 新安装的系统的配置

  Anaconda提供三种方法控制安装程序并指定安装选项。
    (1) 图形用户界面（GUI）。此接口旨在允许用户在开始安装之前以很少或不需要配置的交互式安装，并且应该涵盖所有常见用例，包括设置复杂的分区布局。图形界面还支持远程访问VNC，即使在没有显卡的系统上也可以使用GUI。
    (2) 文本模式（TUI）。此接口旨在允许用户执行交互式安装。TUI的工作方式类似于单色行式打印机，即在不支持光标移动，颜色和其他高级功能的串行控制台上也能工作。文本模式的局限性在于它只允许您自定义最常用的选项，例如网络设置，语言选项或安装（包）源; 此界面中不提供手动分区等高级功能。
    (3) Kickstart文件安装。一个带有类似shell语法的纯文本文件，它可以定义驱动安装过程的数据。Kickstart文件允许部分或完全自动化安装。配置所有必需区域的某组命令完全自动化安装; 如果缺少一个或多个所需命令，则安装将需要交互。如果存在所有必需的命令，则将以完全自动的方式执行安装，而无需任何交互。Kickstart提供的选项涵盖了TUI和GUI都不覆盖的用例。Kickstart支持Anaconda中的每个功能; 其他接口仅遵循所有可用选项的子集。

Anaconda 体系结构

Anaconda是由Python模块、shell脚本和几个外部包和库组成。此工具集的主要组件包括以下几块：

• pykickstart 用于解析和验证Kickstart文件，还提供存储驱动安装的值的数据结构
• yum 包管理器，它处理包的安装和解决依赖关系
• blivet 最初从anaconda包拆分为pyanaconda.storage; 用于处理与存储管理相关的所有活动
• pyanaconda 包含用户界面核心和Anaconda独有功能模块的软件包，例如键盘和时区选择，网络配置和用户创建，以及许多实用程序和面向系统的功能
• python-meh 包含一个异常处理程序，它在崩溃的情况下收集并存储其他系统信息，并将此信息传递给libreport库，库本身也是ABRT项目的一部分。

 安装过程中数据的生命周期很简单。如果提供了Kickstart文件，它将由pykickstart模块处理并作为树状结构导入到内存中。如果未提供Kickstart文件，则会创建一个空的树状结构。如果安装是交互式的（并非所有必需的Kickstart命令都已使用），则会根据用户在交互式界面中做出的选择更新结构。
 完成所有必需的选择后，安装过程开始，结构中存储的值用于确定安装的参数。这些值也写为Kickstart文件，保存在/root 已安装系统的目录中; 因此，可以通过重用此自动生成的Kickstart文件自动安装。
 树状结构的元素由pykickstart包定义，但其中一些可以通过pyanaconda.kickstart模块中的修改版本覆盖。管理此行为的一个重要规则是没有存储配置数据的位置，并且安装过程是数据驱动的，并且尽可能地依赖于事务。所以必须拥有以下功能：

• Kickstart 必须支持 安装程序的每个功能。
• 在安装过程中有一个明显的点，将更改写入目标系统之前，没有进行持久的更改（例如格式化存储）。
• 在用户界面中手动进行的每个更改都会反映在生成的Kickstart文件中，并且可以生成的Kickstart文件重复使用。

  安装是数据驱动的事实意味着安装和配置逻辑位于树状结构中的项的方法内。setup如果需要，设置每个项目（方法）以修改安装的运行时环境，然后执行（该execute方法）以在目标系统上执行更改。

Anaconda 开发模型

  在Fedora的早期版本中，安装程序的界面遵循向导设计模式，包括多个线性屏幕，偶尔嵌套模式弹出对话框。（参见下图）虽然使用向导作为设计模式并不存在任何问题，但安装程序所需的大量屏幕使其变得笨拙。你可以在这个过程中结束几个屏幕，并且需要返回并在之前的屏幕上更改某些内容，需要大量点击和屏幕翻转才能返回并返回到离开的位置。多个模态嵌套对话窗口有时使得与某些屏幕交互，特别是与分区相关的屏幕相混淆。

  为了解决这些问题和其他问题，安装程序开发团队将UI模型从基于线性向导的模型更改为中心辐射模型。基本上，安装程序UI已被提炼为两个主菜单，您可以从中选择访问各种选项屏幕。每个菜单都列出了每个子屏幕，并总结了为每个子屏幕选择的选项，因此您可以跳过不需要配置的屏幕（如果您愿意）。请参阅下图，了解中心和辐条模型的工作原理。

Hub＆Spoke模型中提供的新安装程序解决了旧代码库中难以解决的许多问题：

• 新安装程序是以模块化方式编写的，因此没有多个代码副本可以分散在代码库中。
• 使用安装程序时，可以在后台执行长时间运行的任务。例如，当您首次启动安装程序并登陆第一个屏幕进行语言选择时，安装程​​序将在后台尝试自动检测您的网络设置并为其设置网络连接。
• 新安装程序的UI编写方式使其在等待CPU和时间密集型任务处理时不会阻塞和冻结。
• 新安装程序主要基于kickstart，无论您是否使用自动和无人参与的kickstart选项进行安装，文本用户界面或图形用户界面。除了实时媒体安装方法之外，这三者共享一个通用代码库，提供跨安装方法的更一致的体验以及更容易维护的代码库。最终，计划是在安装期间自动检测系统可用的任何kickstart文件，并提供使用kickstart中的值预填充UI中的字段以帮助节省用户时间。
• 通过更改为hub-and-spoke模型而不是线性向导模型，新UI允许用户完全跳过他们不感兴趣与之交互的屏幕，将安装过程简化为仅对那些最重要的屏幕安装继续。
• 当Fedora 19完成该功能后，新安装程序将允许您在安装程序下载并安装Fedora到您的计算机时完成firstboot，从而有助于进一步简化安装过程。如果您选择在安装期间未完成firstboot，则在重新引导系统后将显示该引导。

线程和通信

  在安装过程中需要执行的某些操作（例如扫描现有分区的磁盘或下载程序包元数据）可能需要很长时间。为了防止等待并尽可能保持响应，Anaconda会在单独的线程中运行这些操作。在基于GTK工具包不支持从多个线程元素的变化。Gtk的主事件循环在Anaconda进程本身的主线程中运行，执行涉及GUI的操作的所有代码必须确保这些操作也在主线程中运行。唯一支持的方法是使用GLib.idle_add，这并不总是容易或需要。为了缓解这个问题，pyanaconda.ui.gui.utils模块中定义了几个辅助函数和装饰器。其中最有用的是@gtk_action_wait和@gtk_action_nowait装饰器。它们以这样一种方式更改装饰函数或方法：当调用此函数或方法时，它会自动排入Gtk的主循环，在主线程中运行，返回值分别返回给调用者或删除。
  如前所述，使用多个线程的主要原因之一是允许用户配置某些界面，而其他当前正忙的界面（例如下载包元数据时的安装源）自行配置。一旦配置完