Re: Bug: "insmod all_video" should be equivalent to "insmod efi_gop" on UEFI
Andrew Hamilton <[email protected]> Sat, 27 Sep 2025 09:27:29 -0500
| Newsgroups | gmane.comp.boot-loaders.grub.devel,gmane.comp.boot-loaders.grub.bugs,gmane.linux.debian.devel.kernel |
|---|---|
| Message-ID | <CA+04=DanA8CLdcOLduyswY3G1BfGuJAbQtkTdOnotq6AueQwww@mail.gmail.com> |
--===============7594583855765261182== Content-Type: multipart/alternative; boundary="0000000000006fa1b3063fc93421" --0000000000006fa1b3063fc93421 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, On Fri, Sep 26, 2025 at 12:33=E2=80=AFAM Askar Safin via Grub-devel < [email protected]> 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=E2=80=A6 to remove bochs for efi so = it isn=E2=80=99t 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=3Dy > 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_60533= 4 . > 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=3Dy > (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 > [email protected] > https://lists.gnu.org/mailman/listinfo/grub-devel Please let me know your thoughts. Thanks, Andrew --0000000000006fa1b3063fc93421 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div>Hello,</div><div><br> <br> <br> On Fri, Sep 26, 2025 at 12:33=E2=80=AFAM Askar Safin via Grub-devel <<a = href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>= > wrote:<br> ><br> > Hi, GRUB people.<br> ><br> > (debian-kernel is in "To" for reasons explained below.)<br> ><br> > Currently GRUB has a bug: on UEFI "insmod all_video" seems t= o enable wrong video driver and/or<br> > multiple video drivers at once instead of enabling "efi_gop"= and nothing else.<br> ><br> > This causes video artifacts when we run GRUB inside of Qemu and chainl= oad EFI shell.<br> > EFI shell becomes unusable.<br> ><br> > Also this sometimes affects Linux kernel: makes it unusable in early b= oot stages (more details below).<br> ><br> > This problem is urgent for reasons explained below.<br> ><br> > See full bug report, including full reproduction steps, here: <a href= =3D"https://gitlab.com/qemu-project/qemu/-/issues/2562" rel=3D"noreferrer" = target=3D"_blank">https://gitlab.com/qemu-project/qemu/-/issues/2562</a> .<= br> > In this report Qemu people gave detailed answers why this bug happens.= <br> <br></div><div> Thank you for the detailed reproduction steps / script in the Qemu report, = that was very helpful to understand and recreate it.</div><div><br> <br> ><br> > Qemu people rejected my report. They said the problem is in GRUB and/o= r its configuration.<br> ><br> > I reported this to GRUB: <a href=3D"https://savannah.gnu.org/bugs/inde= x.php?66200" rel=3D"noreferrer" target=3D"_blank">https://savannah.gnu.org/= bugs/index.php?66200</a> ,<br> > but I got no answer for a year.<br> > Does anybody read bug tracker at all?<br> <br></div><div dir=3D"auto"> 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 o= f the people on the mailing list have been swamped with other priorities fo= r the project.</div><div dir=3D"auto"><br> <br> ><br> > So, I kindly ask GRUB people to make "insmod all_video" equi= valent<br> > to "insmod efi_gop" in UEFI mode. I. e. in UEFI mode no driv= ers should be<br> > enabled except for efi_gop. (The same applies to use case, when we<br> > build GRUB image using "grub-mkimage ... all_video".)<br> ><br> > It is possible to workaround at configuration side, i. e. not to invok= e<br> > "insmod all_video" in grub.cfg in UEFI mode and not to pass = "all_video"<br> > to "grub-mkimage -O x86_64-efi ...".<br> ><br> > I tested that this workaround indeed works.<br> ><br> > But I still believe that this problem should be fixed at core GRUB sid= e, i. e.<br> > I think that calling "insmod all_video" should not cause pro= blems on its own.<br> ><br> > It seems that "insmod all_video" enables "video_bochs&q= uot;, which causes the problem.<br> > (I tested that "insmod video_bochs; insmod efi_gop" is buggy= and just "insmod efi_gop"<br> > works. Bochs is output used by Qemu by default.)<br> ><br> > So I ask GRUB devs: do you agree that this should be fixed in GRUB its= elf?<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">I wonder, is th= ere any valid use case for the bochs driver to be built in efi configuratio= n? I assume efi must provide that gop interface?</div><div dir=3D"auto"><br= ></div><div dir=3D"auto">=C2=A0That seems like a possibly simple fix=E2=80= =A6 to remove bochs for efi so it isn=E2=80=99t loaded by all video.<br></d= iv><div> <br> ><br> > If not, then I will submit instead PR to Debian to fix the bug at conf= iguration side.<br> > (Debian is distro I use.)<br> ><br> > Also: if I run current Debian sid inside of Qemu, then this bug affect= s not only EFI shell,<br> > but also Linux kernel. When GRUB transitions to Linux, image is damage= d at first<br> > (i. e. Linux is unusable), but then image becomes normal when Linux sw= itches to<br> > native driver. This problem can be fixed by replacing "all_video&= quot; with "efi_gop", too.<br> ><br> > Now let me explain why this is urgent. Debian tries to enable CONFIG_D= RM_SIMPLEDRM=3Dy<br> > for its kernels: <a href=3D"https://salsa.debian.org/kernel-team/linux= /-/merge_requests/1453" rel=3D"noreferrer" target=3D"_blank">https://salsa.= debian.org/kernel-team/linux/-/merge_requests/1453</a> .<br> > Unfortunately, Ben Hutchings (CC'd) says that Linux output is brok= en:<br> > <a href=3D"https://salsa.debian.org/kernel-team/linux/-/merge_requests= /1453#note_605334" rel=3D"noreferrer" target=3D"_blank">https://salsa.debia= n.org/kernel-team/linux/-/merge_requests/1453#note_605334</a> .<br> > Assuming that he sees this in Qemu (in UEFI mode), this seems to be ex= actly that bug I'm speaking about.<br> ><br> > So, this problem prevents Debian from enabling CONFIG_DRM_SIMPLEDRM=3D= y<br> > (it is already enabled by Fedora).<br> ><br> > Finally, here is patch: <a href=3D"https://paste.debian.net/1398161/" = rel=3D"noreferrer" target=3D"_blank">https://paste.debian.net/1398161/</a> = ,<br> > which fixes this bug at configuration side for Debian's GRUB.<br> > It is not designed to be applied right now, I send it just to<br> > allow Debian people to proceed right now without waiting<br> > for GRUB people first.<br> ><br> > --<br> > Askar Safin<br> > <a href=3D"https://types.pl/@safinaskar" rel=3D"noreferrer" target=3D"= _blank">https://types.pl/@safinaskar</a><br> ><br> ><br> > _______________________________________________<br> > Grub-devel mailing list<br> > <a href=3D"mailto:[email protected]" target=3D"_blank">Grub-devel@gnu= .org</a><br> > <a href=3D"https://lists.gnu.org/mailman/listinfo/grub-devel" rel=3D"n= oreferrer" target=3D"_blank">https://lists.gnu.org/mailman/listinfo/grub-de= vel</a><br> </div><div dir=3D"auto"><br></div><div dir=3D"auto">Please let me know your= thoughts.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Thanks,</div>= <div dir=3D"auto">Andrew</div> --0000000000006fa1b3063fc93421-- --===============7594583855765261182== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KR3J1Yi1kZXZl bCBtYWlsaW5nIGxpc3QKR3J1Yi1kZXZlbEBnbnUub3JnCmh0dHBzOi8vbGlzdHMuZ251Lm9yZy9t YWlsbWFuL2xpc3RpbmZvL2dydWItZGV2ZWwK --===============7594583855765261182==--