Bug#958218: update-grub fails to process more than one argument to initrd
Hi Krzmbrzl, On Mon, May 01, 2023 at 02:42:41PM +0200, Krzmbrzl wrote: >Hi everyone, > >In this report, there seems to be an indication that this issue was fixed >with grub2/2.04-5. At least that's how I interpret the auto-generated line >"No longer marked as found in versions grub2/2.04-5" that was somehow >triggered by Colin Watson (though when checking the respective mail, it seems >like that is only about reassignment and not about a resolution). > >In either case, I want to report that this issue still exists when having >grub2-common/2.06 installed (on Ubuntu 22.04), which comes with >os-prober/1.79. If you're seeing this in Ubuntu, then you'll need to talk to the Ubuntu developers. There are two parts to this, one in os-prober itself and one in GRUB. The os-prober part was fixed in version 1.80 in Debian. The fix in GRUB will be included shortly in Debian - see https://salsa.debian.org/grub-team/grub/-/commit/358e8faa1329e9ed3467f6f9cacaa781fc34a7b8 I'd suggest you ask the Ubuntu folks to pick that up. >Furthermore, I can explain exactly where this issue occurs. I have written up >a question on the Unix StackExchange about this, that contains the >explanation: https://unix.stackexchange.com/q/744624/203826 ACK. -- Steve McIntyre, Cambridge, UK.st...@einval.com Mature Sporty Personal More Innovation More Adult A Man in Dandism Powered Midship Specialty
Bug#958218: update-grub fails to process more than one argument to initrd
Hi everyone, In this report, there seems to be an indication that this issue was fixed with grub2/2.04-5. At least that's how I interpret the auto-generated line "No longer marked as found in versions grub2/2.04-5" that was somehow triggered by Colin Watson (though when checking the respective mail, it seems like that is only about reassignment and not about a resolution). In either case, I want to report that this issue still exists when having grub2-common/2.06 installed (on Ubuntu 22.04), which comes with os-prober/1.79. Furthermore, I can explain exactly where this issue occurs. I have written up a question on the Unix StackExchange about this, that contains the explanation: https://unix.stackexchange.com/q/744624/203826 The gist of it is that the script that parses the grub.cfg on the separate Arch (in my case Manjaro) partition, the initrd statement is parsed as expected, but the code only handles the first argument to the initrd command, which in Arch's case is the microcode stuff, while completely ignoring any subsequent arguments. Where can I hand in a patch to fix this issue?
Bug#958218: update-grub fails to process more than one argument to initrd
Package: grub-common Version: 2.04-5 When update-grub is run from the Debian bullseye/sid system, 30_os-prober detects another OS (in this case Arch Linux) on a second drive. However, that Arch Linux system uses early loading of microcode updates - see: https://wiki.archlinux.org/index.php/Microcode The grub.cfg generated on the Arch Linux disk provides two arguments to initrd: initrd /boot/intel-ucode.img /boot/initramfs-linux.img The grub.cfg generated by the Debian system produces an initrd for the Arch Linux boot selection that contains only: initrd /boot/intel-ucode.img As one might expect, attempting to boot Arch Linux from the grub boot menu selection generated by the Debian system results in: Kernel panic - not syncing: VFS: unable to mount root fs on unknown block(0,0) The fix would seem to be to make sure update-grub (or whatever it calls) reads all arguments to initrd. Manually editing grub.cfg on the Debian system adding the second argument to initrd solves the problem and the second OS boots as expected.
