简介

像往常一样，在这个冲刺期间，我们一直在处理各种主题。下一个 (open)SUSE 版本的发布临近，我们需要关注重要的变化，例如新的安装介质或 /usr/etc 和 /etc 的拆分。

虽然我们一直在处理更多内容，但我们想重点介绍以下主题

  • 支持新的 SLE 安装介质。
  • 正确处理 shadow 套件设置。
  • 改进挂载点处理。
  • 帮助其他人保持 Live 安装正常运行。
  • 正确配置控制台字体。
  • 在调整 ext2/3/4 文件系统大小时，更准确地计算最小和最大大小。
  • 网络模块中的一些小修复。

新的在线和完整 SLE 安装介质

SUSE Linux Enterprise 产品的下一个 Service Pack 2 将以两种介质类型发布：在线和完整。

一方面，在线介质根本不包含任何仓库。它们将在注册选定的基础产品后从注册服务器 (SCC/SMT/RMT) 添加。在线介质非常小，仅包含启动系统和运行安装程序所需的文件。另一方面，完整介质包含几个仓库，包含基础产品和几个附加组件，这可以帮助节省一些带宽。

显然，由于安装程序对于两种介质类型都是相同的，我们需要对其进行调整，以使其在所有场景中都能正常工作。这是一个有趣的挑战，因为代码位于许多 YaST 包中，并且位于不同的位置。还要记住，相同的安装程序还需要与 openSUSE Leap 15.2 产品一起工作。这又增加了一组我们需要支持（或至少不破坏）的场景。

基本支持已经存在，我们现在正在微调细节和边缘情况，改善用户体验等等。

正确处理 Shadow Suite 设置

几周前，我们预计 (open)SUSE 将在 /usr/etc 和 /etc 目录之间拆分系统配置。前者将包含供应商设置，后者将定义主机特定设置。

首先被更改的软件包之一是 shadow，它现在将默认配置存储在 /usr/etc/login.defs 中。问题是 YaST 没有及时调整，仍然尝试仅从 /etc/login.defs 读取设置

在这个冲刺期间，我们利用这个机会修复了这种行为，更重要的是，定义了一种策略来适应未来其他文件的处理。在这种情况下，YaST 将考虑来自 /usr/etc 目录的设置，并将更改写入专用的 /etc/login.defs.d/70-yast.conf 文件。

缺少控制台字体设置

今年，YaST 团队收到了一份不错的礼物（圣诞节前很久），这要归功于 Joaquín，他通过重构键盘管理模块，为 YaST 项目做出了很棒的 贡献。非常感谢，Joaquín！

我们都欠你们一篇博客文章来解释细节，但目前，让我们说该模块现在可以很好地与 systemd 配合使用。

在合并这些更改后，我们的 QA 团队检测到控制台字体设置没有正确应用。你有没有想过控制台中的正确字体有多重要？问题是负责写入 SCR agent 的 虚拟控制台配置文件 被删除了。幸运的是，恢复已删除的 agent 就可以解决问题，所以你的控制台将再次正常工作。

帮助 Live 安装生存

几年前，YaST 团队由于可维护性原因停止支持从 openSUSE live 版本进行安装。但这并没有阻止其他人尝试保持这种可能性。他们没有修复旧的 LiveInstallation 模式的安装程序，而是将 openSUSE 的 live 版本调整为包含常规安装程序并使其能够与之配合使用。

有时，这会暴露安装程序中隐藏的错误，而没有人注意到，因为它们实际上并不影响受支持的标准安装过程。在这种情况下，YaST 并非总是将存储堆栈所需的所有软件包标记为目标系统进行安装。例如，用户可能决定使用 Btrfs，但安装程序仍然不会自动选择安装相应的 btrfsprogs 软件包。

这是因为 YaST 正在检查哪些软件包已经安装，并跳过它们。在 YaST 在已经安装的系统上运行时，这种检查是有意义的，并且在标准安装介质中执行时是无害的。但在 live 介质中却很棘手。现在，该检查在没有意义的地方被跳过，并且 live 安装再次正常工作。

更强大的 YaST 引导加载程序

为了执行任何操作，YaST 的引导加载程序模块首先需要检查系统的磁盘布局，以确定哪些设备分配了更相关的挂载点，例如 /boot 或根文件系统。Btrfs 的使用，及其所有子卷和快照等独有特性，扩展了 Linux 系统在这方面可能呈现的方式。有时，这意味着 YaST 引导加载程序无法清楚地识别根文件系统，并且只是崩溃了。

"Missing '/' mount point" error

幸运的是，由于在此冲刺期间引入的所有调整和修复，包括 改进挂载点检测，这些场景现在已经减少到最低限度。但仍然存在一些极端情况，例如未完成的回滚过程或非常不寻常的子卷组织。

因此，除了在 yast2-storage-ng 中进行的上述改进之外，我们还指示 yast2-bootloader 更好地处理这些不寻常的 Btrfs 场景，以便即使情况棘手，它也能找到根文件系统。这意味着“缺少‘/’挂载点”错误应该永远消失了。

但以防我们忽略了什么，并且未来仍然存在再次达到相同情况的开放机会，我们还改进了 YaST 以显示解释并退出而不是崩溃。尽管我们尽了最大努力确保此博客条目将是我们的用户看到这个新的错误弹出窗口的唯一机会。

YaST2 Bootloader: root file sytem not found

改进挂载点检测

如上所述，改进挂载点检测有助于防止影响 yast2-bootloader 的一些问题。但是，并非只有该模块能从这些更改中受益。

当运行一些客户端（如专家分区程序）时，它们会自动使用 libstorage-ng 库来发现所有存储设备。在此阶段，libstorage-ng 尝试通过检查 /etc/fstab 和 /proc/mounts 文件来查找所有文件系统的挂载点。通常，文件系统只挂载一次，要么在启动时，要么由用户手动挂载。对于第一种情况，/etc/fstab 和 /proc/mounts 文件将包含文件系统的条目，例如

$ cat /etc/fstab
/dev/sda1  /  ext4  defaults  0  0

$ cat /proc/mounts
/dev/sda1 / ext4 rw,relatime 0 0

在上面的示例中，libstorage-ng 将 / 挂载点与位于分区 /dev/sda1 上的文件系统关联。但是，如果用户绑定挂载了一个目录会发生什么？在这种情况下，/proc/mounts 将包含相同设备的两个条目

$ mound /tmp/foo /mnt -o bind
$ cat /proc/mounts
/dev/sda1 / ext4 rw,relatime 0 0
/dev/sda1 /mnt ext4 rw,relatime 0 0

在专家分区程序中，该文件系统将显示为挂载在 /mnt 而不是 /。所以看起来你的系统根本没有根文件系统！

通过改进将挂载点与设备关联的启发式方法解决了此问题。现在，如果该挂载点也出现在 /proc/mounts 文件中，则将 /etc/fstab 挂载点分配给设备。这意味着，如果设备包含在 /etc/fstab 中并且该设备仍然挂载在该位置，则 /etc/fstab 挂载点优先。

作为奖励，并且也与挂载点处理相关，现在专家分区程序能够检测到在执行基于快照的回滚后，系统尚未重新启动的情况。因此，它将向用户显示一个友好且信息丰富的消息。

System not rebooted after snapshot rollback

改进 ext2/3/4 的最小和最大大小计算

如果你想使用 YaST 调整文件系统大小，它需要找到给定文件系统的最小和最大大小。直到现在，ext2/3/4 的估计基于 statvfs 系统调用，并且 根本不起作用。

最近，我们改进了 YaST 以使用 resize2fs 报告的值作为最小大小，这更精确。此外，YaST 现在检查块大小和 64 位功能是否启用，以计算最大大小。

完善网络模块

作为我们最近的网络模块重构的一部分，我们改进了无线设备配置的工作流程，以及其他 UI 更改。通常，这些更改存在争议，因此我们收到了一些关于实际上不再需要的步骤的错误报告。但是，检查这些错误使我们能够找到一些小的 UI 故障，例如身份验证模式小部件的问题。

此外，我们利用这个冲刺来放弃对一些已弃用设备类型的支持，例如 Token Ring 或 FDDI。下面你可以看到设备类型选择现在看起来有多糟糕。但别担心！我们知道，并且将在下一次冲刺期间给予它一些关注。

Network Device Type Selection

结论

今年的最后一个冲刺已经在进行中。这一次，我们仍在完善我们的存储和网络堆栈，改进迁移过程，并修复几个杂项问题。我们将在两周后通过我们的下一个冲刺报告向你提供所有详细信息。在此之前，祝你玩得开心！