教安装程序进行自我更新，使其成为更好的公民
如你所知，YaST 包含一个 不错的功能，允许安装程序自我更新，以解决安装介质中的错误。此机制已包含在 SUSE Linux Enterprise 12 SP2 中，但默认情况下未启用（你需要传递一个额外的选项 selfupdate=1 才能使其工作）。
因此，在收到一些反馈后，我们正在努力修复一些可用性问题。其中第一个问题是，在某些情况下，自我更新机制过于具有侵入性。
考虑以下场景：你正在通过防火墙安装系统，该防火墙阻止机器连接到外部网络。由于无法访问 SUSE 客户中心，YaST 会抱怨无法获取自我更新的仓库列表。然后，你又收到另一个抱怨，因为无法访问备用仓库。两个错误消息和 2 次超时。
如果无法访问 DNS 服务器，情况可能会更糟（再添加一个错误消息）。
因此，经过一些讨论，我们决定仅在用户指定 SMT 或自定义自我更新仓库（这也是可能的）时才显示此类错误。在任何其他情况下，错误将被记录，并且自我更新将完全跳过。
你可以在我们的 自我更新用例和错误处理文档 中找到更多信息。
在接下来的冲刺中，我们将继续努力使自我更新功能更加出色！
在 CaaSP 安装期间配置工作节点
随着 CaaSP 版本的发布临近，我们的团队仍在努力满足新的需求。幸运的是，YaST 是一个非常灵活的工具，它允许我们更改很多东西。
对于 CaaSP 安装，YaST 具有一个单对话框安装屏幕。在此冲刺期间，已实现了 Worker 角色的配置，包括验证输入的 URL 并将值写入已安装的系统。你可以查看动画截图以获取详细信息。
openSUSE 安装程序中的新桌面选择屏幕
Linux 桌面环境的世界变化相对较快，新的选项不断涌现，一些项目也被放弃。感谢 openSUSE 的打包社区，我们在 openSUSE 发行版上可以使用许多新的桌面环境。但这些软件包在 openSUSE 上的状态也可能发生变化：一些桌面环境维护不良，而另一些则拥有强大而活跃的打包者和维护者团队。
YaST 团队没有足够的时间和精力来关注所有这些桌面环境并评估哪些环境准备好安装程序的桌面选择屏幕。因此，openSUSE 发布团队决定用一些更通用但仍然对新手有用的东西来替换此对话框。
他们要求 YaST 团队设计一个新的对话框，其中包含两个 openSUSE 主桌面（KDE Plasma 和 GNOME），并允许轻松选择其他环境，而无需重新设计对话框。该新对话框的目标是替换以下屏幕中看到的现有对话框。
我们决定新对话框应该依赖模式，原因有几个。最主要的原因是模式集受到 openSUSE 社区的严格控制，社区比我们更密切地关注桌面环境及其与发行版的集成。此外，每个模式都指定了自己的图标和描述，这些图标和描述可以由安装程序以某种方式重用。
我们还借此机会将这个几乎为空且过时的对话框与新的对话框合并。
由于 openSUSE 不再生成插件，因此现在只有第二个复选框才有意义。此外，第二个复选框的功能直接影响可用模式的选择，因此将所有内容合并到一个屏幕中比为了适应一个复选框而增加一个额外的步骤更有意义。
因此，我们将新对话框的提案发送到 opensuse-factory 邮件列表，并在实施了那里讨论的许多想法（例如更好的措辞或使用按钮而不是复选框来表示在线仓库）之后，这就是替换上述两个对话框的新对话框。
选择“自定义”会将用户带到现有的模式选择屏幕。以防你忘记该屏幕的样子，可以查看此图像。
如果这些屏幕截图不足以让你了解更改，你可以查看以下动画，其中 KDE Plasma 最初被选择，稍后更改为 LXQt（返回工作流程）。
由于这些更改显然会对 openQA 测试产生重大影响，因此需要进行一些调整，因此在 Tumbleweed 安装程序中实现这些更改还需要一些时间。
我们感谢所有为这个新功能提供反馈和建议的人员通过邮件列表。再次，openSUSE 社区证明了其卓越的品质！
存储重新实现：改进逻辑分区处理
我们存储层的重新实现不断进行改进。在基本 x86 案例工作之后，我们现在正在实现棘手的部分，例如在处理 MBR 风格分区表中的逻辑分区时发生的分区重新编号。
使用 GPT 分区表或 MBR 分区表中的主分区时，分区在创建时会获得一个编号（例如 sda1），并在其整个生命周期内保持该编号。但是，逻辑分区在其他分区创建和销毁时会不断重新编号。我们需要提前知道每个分区将获得什么设备名称，以便提前配置所有内容，并在用户单击“安装”（在安装过程中）或“提交”（如果运行专家分区程序）时才将更改提交到磁盘。
现在，libstorage-ng 能够模拟内存中的重新编号过程，因此我们可以在真正触及磁盘之前计算与分区相关的所有设置（例如引导加载程序的配置）。
使 kdump 在 CaaSP 中工作
当你启用内核崩溃转储 (kdump) 时，你可能希望获得类似于常规进程的转储文件。你可能不会期望自动重启。这是一个不错的奖励。如果你厌倦了等待实际内核崩溃，你可以通过自己触发崩溃来测试你的 kdump 设置。只需以 root 身份运行以下命令
echo c > /proc/sysrq-trigger
kdump 的工作方式是在启动时分配一些额外的内存，并将第二个内核+initrd 放在那里。当主内核意识到它正在崩溃时，它会将控制权（通过 kexec）转移到另一个内核，该内核只有一个目的，即转储崩溃内核的内存。
在即将推出的容器即服务平台中，kdump 无法工作，因为根文件系统是只读的，我们无法创建 kdump initrd。我们 修复了它，在安装 RPM 后立即创建它，此时 FS 仍然是可写的。
CaaSP 中 Snapper 的修复
kdump 并不是受到文件系统只读影响的唯一组件。Snapper 在尝试执行 rollback 和 cleanup 操作时也遇到了问题。现在这些问题已得到修复。在处理这些问题时，我们发现了一些有趣的事情，值得写一篇单独的博文。因此，你很快可以在 Snapper.io 博客 上看到一篇新的文章。
专家分区程序中与快照相关的改进
虽然我们正在开发新的存储系统，但我们仍在关注并改进当前的系统，该系统将继续与 SLE12-SP3、SUSE CaaSP 和 openSUSE Leap 42.3 一起提供。在此冲刺期间，我们对专家分区程序中与 Btrfs 子卷相关的可用性进行了两项改进。
首先，我们将几乎隐藏在“子卷处理”对话框中的“启用快照”复选框移动到它真正应该在的位置——文件系统类型选择器下方。
此外，我们添加了你在屏幕截图中看到的警告，用于提醒用户在潜在的问题设置中启用快照。
在 CaaSP 上恢复 Beta 警告
说到警告，我们改进了 CaaSP 安装对话框，以便在开始时显示 Alpha/Beta 产品警告。在更改 CaaSP 安装以使用我们在 上一篇博文中描述的全合一对话框后，此功能丢失了，因为它属于初始 EULA 对话框的一部分。现在它回来了，用户应该能够正确看到当前产品状态。
存储重新实现：加密 LVM 提案
回到我们的存储层重新实现，新的系统现在能够提出一个带有加密 LVM 的设置。从几个冲刺前开始，我们已经能够提出基于分区和 LVM 的设置。这意味着新的提案现在与旧的提案具有相同的功能，唯一的例外是 Btrfs 子卷（不应该是一个大挑战）和 s/390 存储（尚未由基础 libstorage-ng 正确管理）。
好消息是，新代码的编写考虑了可重用性，这意味着实现一个基于分区的加密提案（没有 LVM）将是微不足道的。新代码由自动单元测试完全覆盖，并且在所有自动质量检查器中都名列前茅（例如 Rubycritics、CodeClimate 和 Rubocop）。
因此，现在我们已经为未来做好了准备，并且在前进的道路上没有失去任何功能。
存储重新实现：提案设置的 UI 原型
回到我们的存储层重新实现，下一个挑战是通过用户界面向用户提供新存储提案的力量。在 上一篇博文中，我们介绍了我们想与 UX 专家讨论的一般想法。
我们很高兴地宣布我们已经与专家会面，并且很容易就用户交互应该如何进行达成一致。在此冲刺期间，我们已经实现了未来提案设置向导的原型，如我们所习惯的那样，包含在我们的 测试 ISO 中。
现在我们有了坚实的基础，接下来的冲刺很可能会产生一个功能齐全的向导，具有几乎最终的措辞和设计。
将 CaaSP 添加到 AutoYaST 集成测试中
在修复 AutoYaST 和 CaaSP 的问题时，我们决定扩展我们的 AutoYaST 集成测试工具以支持 CaaSP。但作为副作用，我们还进行了一些长期需要的其他改进（例如改进下载 ISO 的过程、减少超时等）。
现在，我们的内部 Jenkins 实例负责运行 CaaSP 开发版本的 AutoYaST 集成测试（就像它已经为 SLE 12 SP2 所做的那样）。
服务管理器移动到第一个自动安装阶段
AutoYaST 允许 定义要在已安装系统中启用/禁用的服务集，并在第二个阶段（第一次重新启动后）应用此配置。
不幸的是，这种方法不适用于 CaaSP，因为在这种情况下，第二个阶段将不可用。因此，在此冲刺期间，我们调整了 AutoYaST，以便在第一个阶段写入服务配置。
像往常一样，不仅 CaaSP，而且其他未来的（open）SUSE 版本也将受益于此更改。
在无法下载发行说明时加快 YaST 安装速度
有时，程序中的一个非常小的简单更改会对日常使用产生非常明显的影响。这就是在此冲刺中实施的修复。如果第一次尝试不成功，YaST 通常会多次尝试下载发行说明。虽然从一般观点来看这是正确的，但在某些情况下，重试毫无意义，只会延迟安装。现在，我们将 DNS 解析失败添加到此列表中，这应该会在许多情况下导致安装速度明显加快。
此外，在 AutoYaST 的情况下，我们现在完全跳过下载发行说明。下载它们在 AutoYaST 处理的这种无人值守场景中没有太大意义，跳过此步骤和所有可能的关联问题会导致更可靠的过程。
改进 Libyui 的持续集成
在上一冲刺中，我们切换到 Docker 在 Travis 上，以便我们可以在本机 openSUSE 系统中构建和测试我们的软件包，而不是默认的 Ubuntu。本冲刺中，我们对 Libyui 库进行了相同的更改，该库实现了 YaST 的 UI 部分。
最初，我们无法在 Travis 上构建 Libyui 软件包，因为缺少所需的构建依赖项或依赖项版本过旧且无法使用。通过此切换，我们可以轻松使用 openSUSE Tumbleweed 的最新软件包，从而为所有 Libyui 软件包启用 Travis 构建。
Hack Week 之后再见！
如前所述，本周是 Hack Week 15！因此，我们的 Scrum 流程将暂停几天。这并不一定意味着 YaST 的开发将停滞。由于 YaST 相关的项目有很多在 Hack Week 页面上，你可以预期 YaST 会简单地朝意想不到的方向发展。
请记住，Hack Week 不是 SUSE 内部倡议，我们欢迎公司内外任何人的合作。所以加入我们，一起玩得开心！