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. On Sat, Sep 5, 2026 at 9:28 PM Mikhail Ryazanov <[email protected]> wrote: > > 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). >
