[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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


Reply to: