grub.cfg falls back to 'text' video mode on UEFI which is not supported

Bug #1711452 reported by Steve Langasek
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
grub2 (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

The grub.cfg generated by update-grub for both UEFI and BIOS includes the following logic:

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
        set gfxpayload="${1}"
        if [ "${1}" = "keep" ]; then
                set vt_handoff=vt.handoff=7
        else
                set vt_handoff=
        fi
}
if [ "${recordfail}" != 1 ]; then
  if [ -e ${prefix}/gfxblacklist.txt ]; then
    if hwmatch ${prefix}/gfxblacklist.txt 3; then
      if [ ${match} = 0 ]; then
        set linux_gfx_mode=keep
      else
        set linux_gfx_mode=text
      fi
    else
      set linux_gfx_mode=text
    fi
  else
    set linux_gfx_mode=keep
  fi
else
  set linux_gfx_mode=text
fi
export linux_gfx_mode

[...]

menuentry [...]
    gfxmode $linux_gfx_mode

This means that in some cases, we are calling 'set gfxpayload="text"' on UEFI systems.

However, grub-core/loader/i386/linux.c has:

#ifdef GRUB_MACHINE_EFI
#include <grub/efi/efi.h>
#define HAS_VGA_TEXT 0
#define DEFAULT_VIDEO_MODE "auto"
#define ACCEPTS_PURE_TEXT 0
#elif [...]

and if ACCEPTS_PURE_TEXT is 0, grub_linux_boot() masks GRUB_VIDEO_MODE_TYPE_PURE_TEXT out of the allowed set when calling grub_video_set_mode().

So our generated grub.cfg should *never* be setting gfxpayload=text on a UEFI system. If we do, we get the following error message from grub at boot:

error: invalid video mode specification `text'.
Booting in blind mode

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Confirming, there are other such reports of "booting in blind mode".

Changed in grub2 (Ubuntu):
status: New → Confirmed
Revision history for this message
Steve Langasek (vorlon) wrote :

Booting up the grub shell, I see that I have 'grub_platform=efi' set. It should be possible for grub.cfg to key off of this, and e.g. set a gfx_fallback_mode variable to either 'text' or 'auto' depending on its value, then feeding that into linux_gfx_mode instead of hard-coding of 'text'.

Steve Langasek (vorlon)
summary: - grub.cfg fails back to 'text' video mode on UEFI which is not supported
+ grub.cfg falls back to 'text' video mode on UEFI which is not supported
Steve Langasek (vorlon)
Changed in grub2 (Ubuntu):
status: Confirmed → Triaged
Revision history for this message
Junien Fridrick (axino) wrote :

Is there a workaround we could apply from MAAS to work around this ? Perhaps a kernel boot option that would change grub's behaviour ? Likely a long shot, I know.

Revision history for this message
Steve Langasek (vorlon) wrote :

Junien, no, this can't be worked around with a kernel boot option.

Are you experiencing this when booting via MAAS? MAAS does its own grub.cfg management, and would need to be fixed separately for this issue.

You can work around this in the grub.cfg on a given installed system by running:

  sudo sed -i -e'/linux_gfx_mode/s/text/auto/' /etc/grub.d/10_linux && sudo update-grub

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

I've been attempting to test this locally on hardware and in a virtualized environment (Hyper-V to be precise), and I can't reproduce the failure case. This makes it hard to test that my fix works.

So, what I can tell is that while we can also change the grub config itself, it looks like 'text' is not being properly skipped in the EFI case, where it's already known not to be supported. I have an untested (see above) patch to fix that.

Could you please attach a grub.cfg that is affected, and tell more about the system on which this is happening?

It looks to me like just forcing 'set gfxpayload=text' does not cause the warning message to appear (or it shows up and quickly disappears, too quickly to be noticeable). I have also tried setting console=ttyS2 (some other device I knew would not be connected) to avoid text being obliterated by kernel messages, but it still does not exhibit the failure behavior.

Revision history for this message
Steve Langasek (vorlon) wrote :

When we reproduced this, it was with the grub2 build in xenial.

Are you booting with or without secureboot enabled, and with or without a signed kernel? This would make a difference to which entry point grub uses into the kernel, which does impact how kernel early boot does video setup.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package grub2 - 2.02-2ubuntu7

---------------
grub2 (2.02-2ubuntu7) bionic; urgency=medium

  [ Julian Andres Klode ]
  * debian/patches/shorter_version_info.patch: Only show the upstream version
    in menu and console, and hide the package one in a package_version
    variable. (LP: #1723434)

  [ Mathieu Trudel-Lapierre ]
  * debian/patches/skip_text_gfxpayload_where_not_supported.patch: Skip the
    'text' payload if it's not supported but present in gfxpayload, such as
    on EFI systems. (LP: #1711452)

 -- Mathieu Trudel-Lapierre <email address hidden> Fri, 09 Feb 2018 16:30:45 -0500

Changed in grub2 (Ubuntu):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.