存储重构已进入启动阶段
正如 上一份报告 中已经预料的那样，本次冲刺的目标之一是将新的存储堆栈合并到 SUSE Linux Enterprise 15 和 openSUSE Leap 15 的代码库中。这意味着首先将其提交到 Factory，并确保结果在那里看起来无害且足够好。感谢出色的 openSUSE 工具和流程，这种实验可以在一个专门的暂存项目中隔离，从而使我们能够在不冒风险稳定性和 Tumbleweed 功能的情况下获得有用的结论。
因此，我们向 Factory 提交了两个新的源代码包 libstorage-ng 和 yast2-storage-ng，以及所有受影响软件包的新版本（已经适应使用新的系统，而不是旧的 yast2-storage）和修改后的软件包列表，用于在安装期间使用。
所有内容都在 Staging:E 项目中混合和烹饪……猜猜怎么着！我们获得了带有 storage-ng 的全新 Factory ISO，成功构建并通过 openQA 验证，如 Staging Dashboard 的此屏幕截图所示。
是的，我们知道仪表板中存在两个测试失败，但这完全是可以预料的，因为这些测试使用专家分区程序配置在 MD RAID 系统之上的 openSUSE 安装，而重新实现的分区程序仍然缺乏一些控制来配置 MD RAID 阵列。
新的堆栈将在 Factory:Staging:E（或 Tumbleweed 团队决定的任何其他暂存项目）中存在一段时间，直到它与旧存储层的功能相匹配，从而可以进一步推进其前往 Tumbleweed 的旅程。但 Factory 只是第一站，本次冲刺的最终目标是进入下一代 SLE 和 openSUSE Leap 的初步版本。
第二次集成花费的时间稍长一些，因为它与安装程序和基本系统中的其他重要更改同时发生……而且八月是典型的欧洲假期，这并不完全有助于理顺所有细节。但由于新的存储系统适用于 Factory，我们确信它也适用于 SUSE Linux 和 Leap。
正如熟悉 Tumbleweed 开发过程的读者可能已经注意到的那样，将所有这些软件包放在 Staging:E 中意味着它们的新版本只有在 yast2-storage-ng 被认为足够成熟时才会一次性到达 Tumbleweed。某种程度上，这将阻止我们为仪表板图像中提到的列表中显示的软件包提供新功能。但不用担心，如果发生严重问题并且需要关键更新，我们不会让心爱的 Tumbleweed 用户失望。
但 YaST 领域除了存储重构之外，还有很多事情正在发生。让我们看看其他领域的改进。
无需 Grub 包即可安装
有时，用户已经在他们的系统中安装了 Linux，并且他们不想在新 Linux 发行版中再次在 MBR 中安装 Grub，因为已安装的 Linux 可以管理引导加载程序。在这种情况下，用户可能会决定根本不安装 grub 包。但是，直到现在，如果用户决定不安装引导加载程序，则会显示错误消息，如下面的图像所示。
对于某些特定场景，如 此处 所示，甚至需要其他软件包，并且当用户决定不安装引导加载程序时，这些软件包仍然需要用于安装。
我们在 Tumbleweed 和 SLE 15 中更改了此行为，现在如果用户决定通过另一个操作系统管理引导加载程序，他们将能够安装系统中不需要的软件包。
但这并不是本次冲刺期间引导加载程序管理中引入的唯一改进。
改进 YaST 查找在 MBR 中安装 Grub 的磁盘的方式
在 Leap 42.3 和 SLE 12.3 中，我们发现，在某些非常特定的情况下（有关更多详细信息，请查看 错误报告），YaST 没有找到在 MBR 中安装 Grub 的正确磁盘。当发生这种情况时，安装结束时会显示错误消息，表明无法将 Grub 安装在 /dev/btrfs 磁盘中。
我们改进了查找正确 MBR 设备的策略，方法是添加了专门搜索位于 /boot 或 /（如果 /boot 不存在）的磁盘的分区。
此更改将作为维护更新和自更新发布，并且仅影响 Leap 42.3 和 SLE 12.3，因为 SLE 15 将使用新的存储层，该层不需要对正确磁盘进行双重检查。
说到新的存储系统……
移除对 ReiserFS 的支持
对使用 ReiserFS 进行新安装的支持已从 SUSE Linux Enterprise 12 和 openSUSE Leap 42 中的 YaST 中删除，但仍支持升级。
使用 SUSE Linux Enterprise 15 和 Leap 15，YaST 将完全删除对 ReiserFS 的支持，并且安装程序将阻止升级格式化为 ReiserFS 的系统。
如果系统中要升级的 /etc/fstab 文件中的某些条目正在使用 ReiserFS，则安装程序将建议在将系统迁移到 SUSE Linux Enterprise 15 或 openSUSE Leap 15 之前将其转换为另一种文件系统类型。
对于 ReiserFS 根分区，将报告类似的阻止错误。
另一个 Ruby 2.4 修复
这对于一般的 Ruby 开发者来说可能很有趣。我们收到了一份关于 YaST 崩溃 的错误报告，最终发现这是由于升级到 Ruby 2.4 引起的。棘手的部分是 YaST 会随机崩溃，并且很难重现该问题。
事实证明，当 Ruby 想要在错误输出上打印警告时，崩溃发生了，在某些情况下，这失败了。我们没有修复竞争条件，因为调试 Ruby 内部可能太困难了，但我们至少 修复了代码 以不再生成警告。
所以，如果您是 Ruby 开发者，请接受来自 YaST 同行的免费建议 – 如果您的代码使用 Ruby 2.4 随机崩溃，请首先检查 Ruby 警告。
关于网络设备名称的提示
两冲刺前 我们告诉您 关于使用 AutoYaST 已经可以在第一阶段配置网络的新可能性，从而避免在大多数情况下对系统进行额外的重启。
在此冲刺期间，我们花了一些时间来测试旧的 AutoYaST 配置文件（具有复杂的网络配置），并使用即将发布的 SUSE Linux Enterprise Server，使用我们的一套自动 AutoYaST 集成测试。但我们发现了一些问题，这些问题可能对我们的一些读者感兴趣。
让我们先了解一些技术背景。
Tumbleweed 已经使用“可预测的网络接口名称”一段时间了，并且它适合大多数常规用例。受或遵循 ‘biosdevname’ 引入的方案理念的启发，可预测的网络接口名称 被 systemd/udev v197 采用，试图解决经典网络接口命名方案（eth0、eth1、eth2…）的长期存在的问题。
基本上，它将基于 固件、拓扑和位置信息 分配固定的名称，使其在系统重启、硬件添加或删除以及内核或驱动程序更新之间保持稳定。
对于即将发布的 SLE15，我们正在尝试使用可预测的网络接口名称（它们在 SLE12 和 openSUSE Leap 42.x 中被禁用）。对于我们来说，这变成了一个问题，因为我们的 AutoYaST 测试套件在每次系统重启时都会动态创建新的虚拟机（而不是真正重启之前创建的虚拟机）。因此，从正在测试的操作系统来看，所有网络设备都会在每次重启时被新的设备替换，这会使网络设置陷入困境。
这只是我们的情况（可以说“我们的错”），但可能还有其他情况，在这种情况下，返回旧的命名方案（使用像 ‘eth0’ 这样的名称）比使现有的 AutoYaST 配置文件适应新的方案更方便。在这种情况下，您仍然可以通过使用这些参数启动 SLE15 安装来使用旧方案。
biosdevname=0 net.ifnames=0
更多内容即将到来
除了本文中报告的所有内容之外，我们还一直在努力为即将发布的 SLE15 获得一些新的酷功能，并使存储重构功能足够完善，以便在所有可能的情况下替代旧的存储。
因此，即使现在仍然是夏天（在欧洲），请在两周后关注更多新闻。