这已经有一段时间了，我们的文章标题不再是“YaST 开发 Sprint 亮点”，这有充分的理由。

采用敏捷方式调整 YaST 团队结构

现在 openSUSE Leap 15.0 已经发布，SUSE Enterprise Linux 15 也准备好发布，我们觉得是时候重新思考我们的工作了。在 storage-ng 开发期间，我们将 YaST 团队拆分为两个子团队：Team S 用于 Storage，Team R 用于 Rest（其余部分）。但现在新的挑战在等待着我们；有些事情被搁置了，因为将 storage-ng 达到可接受的状态是首要任务。

我们决定尝试 SUSE 中其他开发团队已经成功使用的方案：在几个 Sprint 的时间内，将 YaST 团队拆分为 3-5 人组成的“小队”。每个小队围绕一个需要解决的大主题展开。没有人会被长期固定分配到任何小队；想法是根据需要调整人员和专业知识，当然，也要考虑到每位开发人员的兴趣。因此，小队和主题每几周都会变化。

这是否是 Scrum 和敏捷圣经的纯粹精神？我们不知道。我们也不在乎。敏捷精神是根据每个时刻的实际情况调整你的工作。我们以敏捷的方式工作，因此工作方式也必须是敏捷的。

下一次 Sprint 报告将包含有关第一组小队及其交付成果的更多信息。但与此同时，我们已经做了更多的事情，而不仅仅是重组我们的力量。虽然基于 Sprint 的工作已经暂停（因此博客标题不包含“Sprint”一词），但 YaST 团队仍然设法推出了许多功能、改进和错误修复，主要针对 Tumbleweed。

专家分区：移动分区

经过大量的努力，YaST 团队已经完全使用新的存储堆栈（又名 storage-ng）从头开始重写了专家分区。虽然这个新的专家分区已经提供了与旧版本几乎相同的所有功能，但一些最后的选项仍在不断增加。其中之一就是移动分区的按钮，这在很多情况下可以节省大量不必要的工作。例如，想象一下你正在安装 openSUSE Tumbleweed，安装程序自动建议你为 root 创建一个分区，然后创建一个 home 分区。如果你不喜欢默认的建议大小（例如，因为你想要更大的 root），你必须使用专家分区来修复这种情况。你必须完全删除 home 分区，调整 root 大小以扩大它，然后再次使用相同的选项创建 home。

现在，有了“移动”按钮，这种修改就容易多了。对于上面的例子，你可以通过简单地调整 home 大小（无需完全删除）并将调整后的 home 移动到磁盘末尾附近（使用移动按钮）来完成完全相同的操作。移动 home 分区后，你就有足够的可用空间来扩大 root 分区。在下面的截图中可以看到移动分区的对话框。

需要注意的是，分区移动仅适用于新分区，也就是说，无法移动磁盘上已存在的分区。

YaST 屏蔽 Systemd 挂载和交换单元

说到分区及其与系统的关系，从 SysVinit 到 Systemd 的过渡改变了 (open)SUSE 挂载设备的行为。Systemd 为各种文件系统生成挂载单元，例如，在 /etc/fstab 中列出的文件系统。结果是，Systemd 可能会自动挂载任何文件系统，即使该文件系统之前已被手动卸载。当用户需要卸载文件系统以进行某些操作（例如调整大小或拔出）时，这可能会成为问题。

因此，现在分区程序使用一种新的机制来防止这种情况在执行期间发生。从版本 4.0.194 开始，yast2-storage-ng 包包含并使用脚本 /usr/lib/YaST2/bin/mask-systemd-units 来逐个屏蔽所有挂载和交换单元。该脚本对于系统管理员直接使用也可能很有用。所以……有利可图！

以 Systemd 方式显示日志

既然我们谈到了 Systemd 如何改变整个系统的运作方式，那么值得注意的是越来越多的服务已经采用 Systemd journal 进行日志记录。

一些配置给定服务的现有 YaST 模块包含一个显示该服务日志的按钮。过去，它们会显示 /var/log/messages 的内容，并进行一些基本的过滤以确保仅显示与该服务相关的信息（例如 tftp）。但这对于已经使用 Systemd journal 的服务来说无法开箱即用，并且我们收到了一些关于它的错误报告。

幸运的是，解决方案就在我们指尖。你可能已经知道，YaST 包含一个用于查看 journal 内容的模块，该模块具有强大的查询功能，用于过滤、搜索等等。显而易见，可以使用该 YaST journal 模块在其他 YaST 模块中，以显示特定于领域的日志。

到目前为止，我们已经调整了 YaST tftp 模块，但修复其他使用旧方法的地方也很容易，而旧方法不再起作用。这就是当你单击 YaST 模块中配置 tftp 时的“显示日志”按钮时，它看起来的样子。

存储库管理器中的可用性改进

YaST 存储库管理器按优先级对存储库进行排序。但有些人系统中有大量的存储库，并且不使用优先级。由于没有明确的第二个标准，在这些情况下存储库列表的顺序看起来相当任意。现在，所有具有相同优先级的存储库都按名称排序，这更有意义。请参阅改进之前的样子。

并与现在的样子进行比较。

在升级期间处理不一致的启动方法

我们收到了相当多的关于 openSUSE Leap 15.0 在升级过程中 grub2 和 grub2-efi 引导加载程序之间发生冲突的错误报告。根本原因在于安装介质使用的启动模式与正在升级的系统使用的启动模式不同。例如，安装的系统使用 EFI 启动，但升级是从通过传统模式（即禁用 EFI）启动的 DVD 执行的。在这种情况下，从 DVD 运行的内核无法暴露写入 EFI 引导管理器所需的一些设备。此外，它还会给更新程序本身带来麻烦，后者并不期望这种情况。

从大多数错误报告来看，在大多数情况下，这并非由于用户有意识地尝试混合两种启动模式而意外发生。因此，为了改善用户体验，我们添加了一个警告，当检测到这种情况时，将在开始升级之前显示该警告。这让用户有机会修复问题或继续操作（如果情况确实是故意的）。

下面你可以看到它在图形模式和文本模式下的样子，在修补后的 openSUSE Leap 15.0 安装介质中，因为该功能开发得太晚，无法包含在官方安装镜像中。

接下来是什么？黑客周！

正如文章开头所评论的那样，我们已经重新启动了基于 Sprint 的工作，尽管略有调整，以尝试小队方法。但在我们向你展示第一个基于小队 Sprint 的结果之前，我们还有其他事情要做——Hack Week 17！。

再次到了 SUSE 工程师（以及任何愿意加入的开源爱好者）创新和学习新知识的时刻。所以请原谅我们，如果我们过于沉迷于玩乐而反应迟钝。很快再见！