Hello,
On Fri, Sep 26, 2025 at 12:33 AM Askar Safin via Grub-devel < grub-devel@gnu.org> wrote: > > Hi, GRUB people. > > (debian-kernel is in "To" for reasons explained below.) > > Currently GRUB has a bug: on UEFI "insmod all_video" seems to enable wrong video driver and/or > multiple video drivers at once instead of enabling "efi_gop" and nothing else. > > This causes video artifacts when we run GRUB inside of Qemu and chainload EFI shell. > EFI shell becomes unusable. > > Also this sometimes affects Linux kernel: makes it unusable in early boot stages (more details below). > > This problem is urgent for reasons explained below. > > See full bug report, including full reproduction steps, here: https://gitlab.com/qemu-project/qemu/-/issues/2562 . > In this report Qemu people gave detailed answers why this bug happens. Thank you for the detailed reproduction steps / script in the Qemu report, that was very helpful to understand and recreate it. > > Qemu people rejected my report. They said the problem is in GRUB and/or its configuration. > > I reported this to GRUB: https://savannah.gnu.org/bugs/index.php?66200 , > but I got no answer for a year. > Does anybody read bug tracker at all? I personally do check it and try to fix all the ones I have the time to and that align to the project priorities, in my personal time.. I think some of the people on the mailing list have been swamped with other priorities for the project. > > So, I kindly ask GRUB people to make "insmod all_video" equivalent > to "insmod efi_gop" in UEFI mode. I. e. in UEFI mode no drivers should be > enabled except for efi_gop. (The same applies to use case, when we > build GRUB image using "grub-mkimage ... all_video".) > > It is possible to workaround at configuration side, i. e. not to invoke > "insmod all_video" in grub.cfg in UEFI mode and not to pass "all_video" > to "grub-mkimage -O x86_64-efi ...". > > I tested that this workaround indeed works. > > But I still believe that this problem should be fixed at core GRUB side, i. e. > I think that calling "insmod all_video" should not cause problems on its own. > > It seems that "insmod all_video" enables "video_bochs", which causes the problem. > (I tested that "insmod video_bochs; insmod efi_gop" is buggy and just "insmod efi_gop" > works. Bochs is output used by Qemu by default.) > > So I ask GRUB devs: do you agree that this should be fixed in GRUB itself? I wonder, is there any valid use case for the bochs driver to be built in efi configuration? I assume efi must provide that gop interface? That seems like a possibly simple fix… to remove bochs for efi so it isn’t loaded by all video. > > If not, then I will submit instead PR to Debian to fix the bug at configuration side. > (Debian is distro I use.) > > Also: if I run current Debian sid inside of Qemu, then this bug affects not only EFI shell, > but also Linux kernel. When GRUB transitions to Linux, image is damaged at first > (i. e. Linux is unusable), but then image becomes normal when Linux switches to > native driver. This problem can be fixed by replacing "all_video" with "efi_gop", too. > > Now let me explain why this is urgent. Debian tries to enable CONFIG_DRM_SIMPLEDRM=y > for its kernels: https://salsa.debian.org/kernel-team/linux/-/merge_requests/1453 . > Unfortunately, Ben Hutchings (CC'd) says that Linux output is broken: > https://salsa.debian.org/kernel-team/linux/-/merge_requests/1453#note_605334 . > Assuming that he sees this in Qemu (in UEFI mode), this seems to be exactly that bug I'm speaking about. > > So, this problem prevents Debian from enabling CONFIG_DRM_SIMPLEDRM=y > (it is already enabled by Fedora). > > Finally, here is patch: https://paste.debian.net/1398161/ , > which fixes this bug at configuration side for Debian's GRUB. > It is not designed to be applied right now, I send it just to > allow Debian people to proceed right now without waiting > for GRUB people first. > > -- > Askar Safin > https://types.pl/@safinaskar > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel Please let me know your thoughts. Thanks, Andrew
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
