linux-boot-proberは、grub.cfgを解析するときに複数のinitrdを処理しません。

私のホストはUbuntu 22.04に基づいてKDE Neonを実行しています。最近、私はシステムに追加のハードドライブを追加し、ここにManjaroをインストールすることにしました。

KDE Neonのインストールが自分のプライマリシステムに残るようにしたいので、そのドライブがプライマリブートドライブになり、KDE ​​Neonによって追加されたGRUBのインストールがマイブートローダになることを保証します。

sudo update-grubこの別々のインストールが自動的に検出され、Manjaroをインストールした後にこれを実行します。これには難しいことがわかりましたが、これらの問題は解決され、現在update-grub（またはより具体的には追加のos-proberManjaroインストールが正常に識別され、対応する開始項目が生成されました）です。

GRUBのブートエントリを使用する場合にのみカーネルパニックが発生します。 GRUBインストールのためにManjaroによって作成されたファイルと自動生成されたファイルを掘り下げて比較したgrub.cfg後（BIOSを使用してドライブから起動すると正しく動作します）、Manjaroのインストールが次の場所にあることを確認しました。grub.cfg

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

また、Manjaro用のKDE Neonで作成された設定には、次のものが含まれます。

initrd  /boot/intel-ucode.img

したがって、結果項目には2番目の初期RAMディスクがありません（明らかに）、Manjaroカーネルが何かを見つけるのを防ぎ、パニック状態になります。

update-grub私はそれがどのようにまたはより具体的に動作するのかについての内部を掘り下げて、現在確認されているブートパーティションのファイルを解析するスクリプトまたはむしろサブスクリプトに関する/etc/grub.d/30_os-prober問題linux-boot-probeを追跡してから（私の場合はManjaroを直接解析します）から関連情報を抽出します。ビルドしたいアイテムに（別々のスクリプトに）コピーするために、この特定のスクリプトにはブートアイテム内のステートメントを処理するロジックがあり、Manjaro構成の両方のRAMディスク仕様を使用してステートメントを解析します。 。ただし、この行を処理するコードは次のとおりです。/usr/lib/linux-boot-probes/mounted/40grub2grub.cfggrub.cfggrub.cfginitrd

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

（caseステートメントの一部です）ここで使用されている位置パラメーターは、以前に行の個々のコンポーネントinitrd（スペースで区切られています）に設定されていました。これは、私の場合、$1$ 3initrdが$2最初のRAMディスク（/boot/intel-ucode.img）で、$ 3が2番目のRAMディスク（/boot/initramfs-6.1-x86_64.img）であることを意味します。

スクリプトは、処理すべきRAMディスクが1つしかないと暗黙的に想定しているので$2。$3

今、これらすべての背景に基づいて、私が実際に質問するのはこれが知られているバグですか？最新バージョンではこの問題は解決されましたかlinux-boot-prober？現在このスクリプトを維持している人は誰ですか？一見すると、このスクリプトは次のように見えます。Debian の一部しかし、これはDebian管理者がスクリプトの管理者でもあることを意味しますか、それともスクリプトをパッケージ化して他の場所で開発します（他の多くのDebianパッケージのように）。

注：私のスクリプトバージョンでこの問題を解決する方法を知っていると思いますが、ここでの質問は、この問題がアップストリームでも解決されていることを確認するために誰に連絡する必要があるのか​​、およびアップストリームがどこにあるのかについてです。