☰

linux-boot-prober 解析 grub.cfg 时不处理多个 initrd

tag-icon • tag-icon grub2 dual-boot
linux-boot-prober 解析 grub.cfg 时不处理多个 initrd

我的主机运行的是 KDE Neon，它基于 Ubuntu 22.04。最近，我在系统中添加了一个额外的硬盘，并选择在其中安装 Manjaro。

我希望我的 KDE Neon 安装保留在我的主系统中，因此相应的驱动器是我默认引导的驱动器，这确保了 KDE Neon 添加的 GRUB 安装将成为我的引导加载程序。

我sudo update-grub在安装 Manjaro 后执行，以便自动检测这个单独的安装并为其创建启动项。事实证明，这有其自身的困难，但这些问题已经解决，现在update-grub（或者更具体地说，os-prober成功识别了额外的 Manjaro 安装并创建了相应的启动项。

只是当使用 GRUB 的引导条目时，我会出现内核恐慌。经过一番挖掘并将自动生成的文件grub.cfg与 Manjaro 为其 GRUB 安装生成的文件进行比较（如果我使用 BIOS 引导到其驱动器，则效果很好），我注意到我的 Manjaro 安装在以下位置它是grub.cfg

initrd  /boot/intel-ucode.img /boot/initramfs-6.1-x86_64.img

而我的 KDE Neon for Manjaro 上生成的配置仅包含

initrd  /boot/intel-ucode.img

因此，生成的条目缺少第二个初始 ramdisk，这反过来（显然）阻止了 Manjaro 内核查找某些内容并因此出现恐慌。

我深入研究了如何update-grub或更具体地/etc/grub.d/30_os-prober工作的内部原理，并将问题跟踪到脚本linux-boot-probe或更确切地说是/usr/lib/linux-boot-probes/mounted/40grub2子脚本，它解析grub.cfg当前检查的启动分区的文件（所以在我的例子中它直接解析 Manjaro 的grub.cfg），然后从中提取相关信息，以便（在单独的脚本中）将其复制到要生成的grub.cfg.这个特定的脚本具有处理initrd启动条目内的语句的逻辑，并且它确实使用 Manjaro 配置中的两个 ramdisk 规范来解析该语句。然而，处理这一行的代码看起来像

        initrd)
            initrd="$(echo "$2" | sed 's/(.*)//')"
            # Initrd same.
            if [ "$partition" != "$bootpart" ]; then
                initrd="/boot$initrd"
            fi
        ;;

（它是 case 语句的一部分）并且此处使用的位置参数先前设置为该initrd行的各个组件（以空格分隔）。这意味着在我的例子中$1，initrd是$2第一个 ramdisk ( /boot/intel-ucode.img)， $3 是第二个 ( /boot/initramfs-6.1-x86_64.img)。

可以清楚地看到，该脚本隐式假设只存在一个需要处理的 ramdisk，因此它只检查$2.但是，就我而言，它还必须处理$3.

现在有了所有这些背景，我的实际问题是：这是一个已知的错误吗？这个问题已经在最新版本中修复了吗linux-boot-prober？目前谁在维护这些脚本。乍一看，这些脚本似乎是Debian 的一部分，但这是否意味着 Debian 维护者也是该脚本的维护者，或者他们只是将脚本打包并在其他地方开发（与许多其他 Debian 软件包一样）？

注意：我想我知道如何在我的脚本版本中解决这个问题，但我在这里的问题实际上归结为与谁联系以确保这也已在上游得到解决 - 以及上游在哪里。

答案1

在这里回答我自己的问题：在浏览 Debianos-prober软件包后，我发现了一个关于这个问题的错误报告：https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958218

我将与参与该报告的人员取得联系。

相关内容