内容

在大部分为 SUSE 15 SP2 和 openSUSE 15.2 计划的功能准备就绪后，团队正在将重点转移到 SP3 和 15.3。当然，我们仍在完善即将发布的版本，因此在本冲刺的总结中，您可以找到错误修复、小功能以及未来工作的准备的混合体。这些主题包括

挥之不去的幽灵：NCurses 安装和旧图形芯片

几个月前（针对 Leap 15.1 / SLE-15 SP1），我们开始对所有 NCurses（基于文本）安装使用 fbiterm。我们一直将其用于需要特殊字体支持的某些语言，例如中文、日语、韩语，但由于即使对于其他语言也存在字体相关问题，我们现在在所有情况下都使用它。

这修复了那些字体相关的问题，但结果却带来了另一个看似早已被遗忘的问题：特定图形芯片在文本模式下的性能差。

还记得 Matrox G200 吗？它曾经是 Linux 系统的好选择。很久以前，非常久以前；该 GPU 于 2018 年迎来了它的 20 周年纪念日，因此可以追溯到 1998 年（那时 Windows 98 还是新的）。它的图形性能……让我们称之为即使在当时对于一款入门级显卡来说也是相当不错的。

好吧，事实证明，它今天仍然被一些机架服务器制造商用作板载显卡。如今，大多数板载显卡都使用 Intel GPU（并且效果很好），但并非全部：有些确实使用该旧的 Matrox G200。

我们收到了一位商业客户的询问，为什么与 SLE-15 GA 相比，在安装他们的机架服务器时，SLE-15 SP1 的屏幕重绘速度如此之慢，这就是解释：这些机器具有板载的 Matrox G200 显卡，并且似乎没有对 framebuffer 控制台有益的硬件加速。有了 fbiterm，您现在可以真正看到差异。

在这种设置中，您可以以慢动作观察 NCurses 库的工作原理：您可以看到它如何从光标位置到行尾部分删除文本（使屏幕的一部分变黑），然后从那里重新绘制内容。这既不错误也不存在漏洞，只是速度慢。慢得令人难以忍受，就像回到拥有非常慢的（4800 波特）终端连接的时代（还记得那些吗？）。

因此，我们对这种硬件的建议是：最好不要使用 framebuffer 控制台。只需将机器保留在纯文本模式下，分辨率为 80x25，并使用 nomodeset 启动参数，或者进行 SSH 安装。

这些古老的幽灵不断回来困扰我们，甚至可以追溯到非常早期的 MS-DOS 时代。:smile:

改进从远程加密设备启动

但并非所有幽灵都如此古老。我们还收到了过去冲刺的灵魂的拜访。在其中一篇 11 月的帖子中，我们 向您解释了 我们如何通过将 _netdev 选项添加到 fstab 和 crypttab 文件中的所有基于网络的的文件系统来解决从远程加密设备启动时存在的问题。

几个月来，这似乎是最终的解决方案。但最近有报告称，尽管该选项确实让 systemd 满意，但它会混淆 dracut，当它用于根文件系统时。虽然他们说你无法让每个人都满意，但我们发现将该选项添加到除根文件系统之外的所有文件系统实际上似乎是 systemd 和 dracut 的正确解决方案。后者不再感到困惑，并且结果是根文件系统是唯一一个省略该选项对 systemd 来说是安全的。

有了这些，SLE-15-SP2（和 Leap 15.2）应该对涉及在网络磁盘上安装（加密或不加密）的所有场景表现出相当稳定的行为。有关更多技术细节，您可以查看 相应的拉取请求。

让我们尝试在 Linuxrc 中使用 ifcfg

Linuxrc 是一款负责启动安装介质的软件。它提供了一个友好的界面来设置一些基本内容（例如语言），并负责初始化硬件以及准备 YaST 需要执行其魔术的所有内容。

除了美观的界面之外，它还提供了一个功能强大的命令行。如果您以前没有这样做过，我们建议您查看 Linuxrc wiki 页面。

您可以使用命令行设置的一件事是 网络，这对于从网络源进行安装非常有用。

ifcfg=eth*=192.168.0.2/24 install=http://192.168.0.1/iso

使用这些设置，Linuxrc 会配置与 eth* 模式匹配的第一个设备。但是，如果您有多个网络接口怎么办？配置的接口是否是到达安装介质的正确接口？

为了处理这些情况，我们已将 try 功能添加到 ifcfg 选项

ifcfg=eth*=try,192.168.0.2/24 install=http://192.168.0.1/iso

在这种情况下，Linuxrc 会尝试找到匹配该模式并且可以访问安装源的设备。

try 关键字适用于静态配置以及 DHCP。当与 DHCP 一起使用时，区别在于 DHCP 设置仅对一个设备完成。没有 try 关键字，DHCP 配置将分配给所有匹配设备模式的设备。因此，如果您使用

ifcfg=eth*=try,dhcp

您最终将获得一个配置了 DHCP 的设备（具有正常网络连接的设备）。相反，省略 try 选项将通过 DHCP 配置所有匹配给定模式的设备。

您可以使用 Linuxrc 的任何网络感知选项作为 try 选项的标准（install、dud、info 和 autoyast）。但是，如果您提供多个选项，则无法明确确定将使用哪个选项。它仅仅取决于 Linuxrc 首先使用哪个选项。

更好地支持 S/390 系统中的自动配置设备

几周前，我们 宣布 我们已扩展 Linuxrc 和 YaST，使其与 zSeries 系统上的新 I/O 设备自动配置机制配合良好。在收集到我们 S/390 专家的反馈后，我们对当前实现进行了一些调整。

一方面，自动配置现在是可选的。Linuxrc 提供了一个新的 DeviceAutoConfig，允许用户指示是否应用配置。可能的值是 0（否）、1（是）和 2（询问）。后一种值是默认值。

另一方面，QA 检测到 AutoYaST 尝试配置已配置的设备时存在问题。除了解决该问题外，我们还花了一些时间清理了 yast2-s390 模块的部分内容。

改进 YaST 的 XML 解析器

XML 是 YaST 世界中的重要语言。最好的例子是所谓的控制文件，它定义了安装过程的许多方面。如果您有兴趣，可以查看 openSUSE 的控制文件。

YaST 实现了自己的 XML 解析器，该解析器已适应我们的需求。例如，它能够理解一个特殊的 config:type 属性，该属性作为提示，用于解释 XML 标记的内容。如果您使用过 AutoYaST，您应该知道我们在说什么。

<initialize config:type="boolean">true</initialize>

但是，它也有自己的一系列问题，尤其是在错误报告方面。因此，我们启动了一项新的计划来改进我们的 XML 解析器。yast-devel 邮件列表中正在进行一些讨论（例如 YaST XML Parser 和 Yast XML parser and strictness）。欢迎加入并分享您的观点。

结论

为了规划未来，该团队已开始研究 YaST 模块和 AutoYaST 的当前状态。如果您订阅了 yast-devel 邮件列表，您可能已经阅读过一些相关内容。如果您想分享您的观点，欢迎参与讨论。

无论如何，我们计划在未来几周内展示我们的结论。所以请保持安全并关注！