According to the Changelog, the efi_uga.mod module has been removed in
2.14-2:
"* efi: Drop support for UGA Draw and Console Control protocols (Closes:
#1127371) (Closes: #1127556)".
However, #1127371 was complaining only about riscv64 and loong64, not
amd64 (and #1127556 looks really unrelated).

The problem with this decision is that it completely broke GRUB menu on
at least some Intel MacBooks, as they do not support EFI GOP. Namely,
the screen remains completely blank until the kernel boots (if it does,
otherwise the user is left completely blind as what to do).

UGA is still supported by the upsteam, so even if there is some real
reason to exclude it from the default grub.cfg on amd64, please at least
provide efi_uga.mod in x86_64-efi, so that affected users can insmod it
manually.

I cannot really test the version 2.14-1 (just before this change), since
it is not available from packages.debian.org and Debian FTPs, but I did
test 2.12-9+deb13u2, and it works fine.

Hello Mikhail,

GRUB 2.16 will drop the UGA Draw protocol upstream as well.

Best regards,
Mate Kukri

Hello Mikhail,

GRUB 2.16 will drop the UGA Draw protocol upstream as well.

Best regards,
Mate Kukri

Hello Mate,

Interestingly, this is not announced anywhere. Although I did find the
corresponding commit upsteam (apparently also yours). Seems very
questionable, taking into account that even i386 is still supported.

And Debian still has the grub-efi-ia32-bin package, claimed "for use
with the EFI-IA32 architecture, as used by Intel Macs", but now it also
does not include the UGA module, so I suspect that it will be in fact
hardly unusable.

Nevertheless, could you please suggest where I can find the 2.14-1
version for more tests? I did some checks with 2.12-9+deb13u2 and am now
not so sure that the problem is directly in the missing efi_uga.

Hello Mate,

Interestingly, this is not announced anywhere. Although I did find the
corresponding commit upsteam (apparently also yours). Seems very
questionable, taking into account that even i386 is still supported.

And Debian still has the grub-efi-ia32-bin package, claimed "for use
with the EFI-IA32 architecture, as used by Intel Macs", but now it also
does not include the UGA module, so I suspect that it will be in fact
hardly unusable.

Nevertheless, could you please suggest where I can find the 2.14-1
version for more tests? I did some checks with 2.12-9+deb13u2 and am now
not so sure that the problem is directly in the missing efi_uga.

Hello,

Debian no longer provides i386 kernels since Trixie, so I am not sure
if IA32 devices are really much of a concern now. The removal will not
be back-ported to previous Debian release, so you can use those until
long term support runs out.

Mate Kukri

Hello,

Debian no longer provides i386 kernels since Trixie, so I am not sure
if IA32 devices are really much of a concern now. The removal will not
be back-ported to previous Debian release, so you can use those until
long term support runs out.

Mate Kukri

I was expecting more interest and participation in finding the real
problem, but unfortunately had to dig this myself. Here are some
important updates.

I've downloaded the version 2.14-1 from snapshot.debian.org and
confirmed that it works fine. Further tests also confirmed my previous
suspicion that the problem is not in the efi_uga removal (actually, my
system uses GOP, and it works), but nevertheless seems to be associated
with the same patch.

Namely in 2.14-3, the command "terminal_output console" brings the
system to a state when GRUB thinks that it works in the text mode, but
the display is actually not switched to the text mode, so all GRUB
output goes nowhere, leaving the screen stuck (in my case, blank because
"terminal_output console" was in grub.cfg before any output). Blindly
typing "terminal_output gfxterm" makes GRUB usable (supposedly, if
necessary video modules were loaded).

So, removing "console" from the GRUB configuration made 2.14-3 usable,
although quite poorly, as that MacBook has a high-resolution screen
("Retina"), on which the default GRUB font is very tiny (line height <
2 mm). "videoinfo" shows that only the native resolution is supported,
so changing "gfxmode" does not help. The only solution that I've found
was to load a larger font (finding a reasonable font file that will work
with grub-mkfont was another quest). However, GRUB_FONT in
/etc/default/grub is not documented and apparently does not work
properly, so I had to edit grub.cfg manually and will need to do so
every time...

Interestingly, "efitextmode" still works in 2.14-3, showing available
text modes and allows selecting among them. But because their
initialization has been removed from grub_prepare_for_text_output(),
nothing really works.

I've also tested that "terminal_output console" works in 2.12-9 even on
the newest PC (made this year), so my opinion is that the decision to
"drop support for ... Console Control" was a mistake. However, if you
prefer formalism ("Console Control protocol was an implementation detail
of the deprecated Intel EDK") over real-world usability, please then
remove it _completely_ and document this breaking change accordingly,
because the current behavior is very confusing and frustrating (from the
user perspective; and keeps the code in a highly inconsistent state,
from the developer side).

I was expecting more interest and participation in finding the real
problem, but unfortunately had to dig this myself. Here are some
important updates.

I've downloaded the version 2.14-1 from snapshot.debian.org and
confirmed that it works fine. Further tests also confirmed my previous
suspicion that the problem is not in the efi_uga removal (actually, my
system uses GOP, and it works), but nevertheless seems to be associated
with the same patch.

Namely in 2.14-3, the command "terminal_output console" brings the
system to a state when GRUB thinks that it works in the text mode, but
the display is actually not switched to the text mode, so all GRUB
output goes nowhere, leaving the screen stuck (in my case, blank because
"terminal_output console" was in grub.cfg before any output). Blindly
typing "terminal_output gfxterm" makes GRUB usable (supposedly, if
necessary video modules were loaded).

So, removing "console" from the GRUB configuration made 2.14-3 usable,
although quite poorly, as that MacBook has a high-resolution screen
("Retina"), on which the default GRUB font is very tiny (line height <
2 mm). "videoinfo" shows that only the native resolution is supported,
so changing "gfxmode" does not help. The only solution that I've found
was to load a larger font (finding a reasonable font file that will work
with grub-mkfont was another quest). However, GRUB_FONT in
/etc/default/grub is not documented and apparently does not work
properly, so I had to edit grub.cfg manually and will need to do so
every time...

Interestingly, "efitextmode" still works in 2.14-3, showing available
text modes and allows selecting among them. But because their
initialization has been removed from grub_prepare_for_text_output(),
nothing really works.

I've also tested that "terminal_output console" works in 2.12-9 even on
the newest PC (made this year), so my opinion is that the decision to
"drop support for ... Console Control" was a mistake. However, if you
prefer formalism ("Console Control protocol was an implementation detail
of the deprecated Intel EDK") over real-world usability, please then
remove it _completely_ and document this breaking change accordingly,
because the current behavior is very confusing and frustrating (from the
user perspective; and keeps the code in a highly inconsistent state,
from the developer side).

Is 'terminal_output console' in your grub.cfg because you have
modified /etc/default/grub because you _want_ text mode console? If
you do want graphics mode (which is the default) then the config is
generated wrong and that is a bug. If you manually changed to text
mode I would have liked at least a mention of that.

Unfortunately it seems, this device when manually set to text mode,
will not render text without the console control protocol call (even
despite it not using UGA Draw). This behavior was not missed because I
am some reckless destroyer (as the unfortunate tone of your last email
suggests), but because it is completely non-standard, and not present
in the firmware of any non-Apple consumer device manufactured in the
last 20 years.  I unfortunately do not have a hardware museum at home
to discover that Apple unfortunately carried this relic forward to the
Retina era. I dropped it under the impression that only early UGA Draw
Intel Macs require it, but looks like that was mistaken.

Regardless, this device should still be entirely functional in the
default graphics mode configuration, and yes the small font is a
limitation on every device with a HiDPI screen (including the ones I
have), it is not a specific bug.

I would be tempted to re-instate just the console control protocol
(UGA Draw still remaining dropped), to support the edge case of
slightly newer Apple devices combined with text mode noting that it is
non-standard and old, but that Apple carried it forward way too far.

Regards,
Mate Kukri

P.S. Open source maintainers need to have the ability to drop
deprecated features they do not have the ability to test, calling that
"formalism" and sending emails of such unfortunate tone to a bug
tracker is not going to change that, but it will result in fewer
people wanting to maintain open source software.

instead of any help or suggestions how to solve or diagnose the problem,
I've got a dismissive one-line reply from you, implying that nobody
cares (not even cares to explain).

I did not mean that you are a reckless destroyer, but GRUB is a critical
part of the system, and thus suddenly finding out that some change,
which was not announced or even publicly discussed, broke its
functionality was very frustrating. I am not a professional software
developer, but I do contribute to and even maintain some open-source
software myself, so I know how important it is to interact with bug
reporters to get more information, at least if you feel responsibility
for your project.

To be clear: I am not familiar with EFI and GRUB internals, so my
initial report was off in identifying the cause of the observed problem.
My last tests show that UGA is apparently unrelated to it (so this bug
probably should be renamed, or I can open another one once we identify
the real cause). I am willing to do the necessary tests to find out what
exactly is broken, but due to my unfamiliarity with the details, I need
guidance and assistance from GRUB developers/maintainers.

I do have "GRUB_TERMINAL=console" in my /etc/default/grub. I've used
this on all my computers since CRT times because it avoided the flicker
from switching display modes (between POST, GRUB and Linux). On that
MacBook, it was still used as an obvious solution to the tiny font. This
worked perfectly fine until the last update (I've skipped 2.14-2, so
cannot tell anything about it). As far as I can tell, grub.cfg is still
generated as expected, but now "terminal_output console" started putting
GRUB in an unusable state.

As I've mentioned previously, efitextmode still shows the available text
modes and allows selecting between them (but "terminal_output console"
apparently does not switch to them). Also, UEFI 2.10 section
"12. Protocols — Console Support" says that text modes are still
supported. So please explain what exactly was dropped, and what I can do
to find why exactly "terminal_output console" is broken in my case.

The affected machine is "MacBookPro11,1" with 2019 firmware (that is,
not super ancient). I can also do tests on a recent (2025 firmware)
non-Apple PC. Preferably, booting only GRUB itself from an USB stick
instead of reinstalling it on the working system.

Mate, you apparently forgot to CC your last reply to the bugs.debian.org
address, so I'm leaving the full quote here (see my reply below it):

I did test 2.14-3 on my non-Apple PC, and "terminal_output console" does
work there (although see below). So yes, it seems that this is
specifically an Apple issue.

To confirm, I've downloaded the source package
("grub2_2.14-3.debian.tar.xz" and "grub2_2.14.orig.tar.xz") and built it
locally (required minor tweaking for gcc-16). It reproduced the behavior
that I've observed with the binary package.

Then I've partially reverted the parts related to console in
"efi-Drop-support-for-UGA-Draw-and-Console-Control-protoco.patch",
rebuilt and tested again. This made "terminal_output console" working on
MacBook again (without breaking it on non-Apple PC), which proves that
those parts are indeed needed at least for that particular MacBook
model. They are quite small, and I don't think that keeping them in GRUB
will harm, so please return them to 2.14 and Debian and to 2.16 upstream.

During all these tests, I've also noticed some other bugs not directly
related to the patch in question (they are present in both 2.14-1 and
2.14-3), but presumably indicating some problems with GRUB terminal
initialization, so I'll mention them here because maybe that call to the
Console Control protocol on Apple is not really needed but just
circumvents some missing steps.

1. After switching the GRUB terminal from "console" to "gfxterm" and
back to "console", the cursor becomes invisible. On both MacBook and
non-Apple PC.

On MacBook, GRUB can actually be started in the "gfxterm" mode, then
"terminal_output console" works fine (shows visible cursor) the first
time, but subsequent switching hides the cursor in the "console" mode.

On non-Apple PC, the only possibility to see the cursor in the "console"
mode is to start GRUB in that mode.

However, the "gfxterm" mode always has a visible cursor, so I suspect
that there is something wrong in setting the cursor for "console".

2. Running "videotest" from the "gfxterm" mode leaves the system
visually unresponsive.

On non-Apple PC, running "videotest" from the "console" mode works fine
(pressing any key return to the terminal and prints some information
about colors). Running from the "gfxterm" mode requires pressing any key
and then blindly executing "terminal_output console" to see anything.

On MacBook, even running from the "console" mode does not return
properly, requiring blindly switching the terminal_output mode in any case.

Executing "clear" does not help. Executing "terminal_output" with the
current mode also does not help (probably just skips the
initialization). So it seems that "videotest" cannot restore the
video/terminal mode properly, and manually changing the terminal_output
mode is required.

(It also would be nice if "videotest" would show "Press any key to
continue". Because currently it is unclear whether it is supposed to
"hang" and require rebooting or is just buggy.)

The problems with console cursor and videotest are reproducible in
VirtualBox (7.2.16_Debian) using its EFI. This means that they are not
hardware-specific and also that testing them should be easier.

They probably need their own bug reports, but I don't know whether they
are limited to AMD64, so I'm not sure to which package to report.

As Mate Kukri requested in a personal email, I've reported the
text-cursor and videotest bugs upstream:
https://gitlab.freedesktop.org/gnu-grub/grub/-/work_items/83
https://gitlab.freedesktop.org/gnu-grub/grub/-/work_items/84