Re: Bug: "insmod all_video" should be equivalent to "insmod efi_gop" on UEFI
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
Reply to: