Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #89412 > unrolled thread

Bug: "insmod all_video" should be equivalent to "insmod efi_gop" on UEFI

Back to article view | Back to linux.debian.kernel

Contents

  Bug: "insmod all_video" should be equivalent to "insmod efi_gop" on  UEFI Askar Safin <safinaskar@zohomail.com> - 2025-09-26 02:50 +0200
    Re: Bug: "insmod all_video" should be equivalent to "insmod efi_gop"  on UEFI Andrew Hamilton <adhamilt@gmail.com> - 2025-09-27 16:50 +0200
      Re: Bug: "insmod all_video" should be equivalent to "insmod  efi_gop" on UEFI Askar Safin <safinaskar@zohomail.com> - 2025-09-28 00:50 +0200

#89412 — Bug: "insmod all_video" should be equivalent to "insmod efi_gop" on UEFI

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.

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?

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?

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

[toc] | [next] | [standalone]

#89431 — Re: Bug: "insmod all_video" should be equivalent to "insmod efi_gop" on UEFI

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#89436 — Re: Bug: "insmod all_video" should be equivalent to "insmod efi_gop" on UEFI

---- On Sat, 27 Sep 2025 18:27:29 +0400 Andrew Hamilton <adhamilt@gmail.com> wrote ---
 > 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.

Yes, I totally agree.

I don't want to write such patch myself, because I'm not familar with GRUB codebase.

Also: I did bisect and I discovered, that this bug also affects Linux kernel
starting from GRUB commit cfbfae1aef0694b41 ("efi: Use generic EFI loader for x86_64 and i386").

Reproduction steps are same, you just need to ensure that your GRUB version
has cfbfae1aef0694b41 and replace "chainloader /boot/shellx64.efi" with
"linux vmlinuz", where "vmlinuz" is some Linux kernel with EFI stub.

You will see artifacts, and Linux will be unsable until native Linux bochs driver
will be loaded.

This bug is fixed by dropping video_bochs, too.

-- 
Askar Safin
https://types.pl/@safinaskar

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web