The suggestion regarding
GRUB_GFXPAYLOAD_LINUX got me to investigate the issue a bit further.
In the file
/etc/grub.d/10_linux there is this bit of code:
Code: Select all
if grep -qx "CONFIG_FB_EFI=y" "${config}" 2> /dev/null \
&& grep -qx "CONFIG_VT_HW_CONSOLE_BINDING=y" "${config}" 2> /dev/null; then
echo " set gfxpayload=keep" | sed "s/^/$submenu_indentation/"
fi
That code is run for each kernel found in /boot when one installs a kernel or runs "
grub-mkconfig -o /boot/grub/grub.cfg". And, if a kernel's config has
CONFIG_FB_EFI and
CONFIG_VT_HW_CONSOLE_BINDING it adds "
set gfxpayload=keep" to the grub settings (menu entry) for that kernel.
I looked at my
/boot/grub/grub.cfg and yes, the kernels that don't display any output during boot have "
set gfxpayload=keep". That file also has "
set gfxmode=auto", but that's on a global scale and used for all kernels:
When I comment out the "
set gfxpayload=keep" lines those kernels start working normally again producing output properly during boot. I verfied this with
6.12 and
6.18 kernels.
Those lines from
/etc/grub.d/10_linux above are from the patch file
/usr/portage/sys-boot/grub/files/gfxpayload.patch. Comments in that file indicate the patch is specific to EFI:
Code: Select all
Subject: [PATCH] 10_linux: Default gfxpayload=keep only when booting using efi
Yet the grub ebuild includes that patch unconditionally and, as far as I can tell, it always has since it was introduce with grub 2.02_beta3 by commit fa02d3700e674800a25426dff1ee832ace2dfc72 back in Mar 2016.
As I mentioned ealier, rebuilding my kernel
without CONFIG_FB_EFI solved the issue for me, and the above partially explains why. To try and understand the full story I dug into the grub code to see what changed between sys-boot/grub
2.12-r11 and
2.14-r3 in terms of that
gfxpayload=keep setting, but I could not see anything obvious. It's clear though that something has change. I found an old stash of saved kernel config files for my problem machine and the
CONFIG_FB_EFI and
CONFIG_VT_HW_CONSOLE_BINDING kernel settings were used since at least 2014 with the 3.12.13 kernel, yet that only became a problem with sys-boot/grub 2.14-r3.
For completeness, here's the important bits from
emerge --info sys-boot/grub for my build:
Code: Select all
USE="device-mapper fonts nls sdl themes truetype -branding -doc -efiemu -libzfs -mount -protect -secureboot (-test) -verify-sig" ABI_X86="(64)" GRUB_PLATFORMS="pc -coreboot -efi-32 -efi-64 -emu -ieee1275 (-loongson) -multiboot -qemu (-qemu-mips) -uboot -xen -xen-32 -xen-pvh"
Also, here's the _FB and _VT config settings used my kernel:
Code: Select all
CONFIG_DRM_CLIENT_DEFAULT_FBDEV=y
CONFIG_DRM_FBDEV_EMULATION=y
CONFIG_DRM_FBDEV_OVERALLOC=100
CONFIG_FB=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_IMAGEBLIT=y
CONFIG_FB_CORE=y
CONFIG_FB_DEVICE=y
CONFIG_FB_IOMEM_FOPS=y
CONFIG_FB_IOMEM_HELPERS=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_NOTIFY=y
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
I did not explore
VESA_FB or
SIMPLE_FB because just removing
CONFIG_FB_EFI worked and I didn't have time to rebuild the kernel with those other settings.
Long story short, the issue is clearly related to a mismatch between the grub and kernel settings, which is agrivated by the fact that the ebuild for grub is including that bit of EFI code in /etc/grub.d/10_linux for non-EFI builds of grub.
