The "novga" label is also reached from later code that checks boot_params.screen_info has been initialized, and then whether the screen is in a VGA16 mode not handled by VGACON.
For a while I was chasing a presumption that arch/x86/kernel/setup.c::setup_arch() was enabling EFI support with
efi_enabled=1;
After a lot of analysis of boot_params.efi_info I arrived at the "novga" code and realised it can also be triggered by the boot-loader leaving the display in a graphic mode.
I then investigated the GRUB configuration and discovered the GRUB_GFXPAYLOAD_LINUX option, described in the blueprint
The bug can be fixed in "/etc/default/grub" by adding
GRUB_GFXPAYLOAD_LINUX=text
However, this is a local workaround. The blueprint refers to the file "/boot/grub/gfxblacklist" which is generated by a script in the package "grub-gfxpayload-lists". The file contains PCI IDs of video devices that GRUB should not leave in graphics mode. These are declared in "/usr/share/grub-gfxpayload-lists/blacklist/"
The attached patch adds a new file "20_intel" to the blacklisted devices in the package.
If adding it manually to a system, place it in the "/usr/share/grub-gfxpayload-lists/blacklist/" directory.
To add the new device to "/boot/grub/gfxblacklist.txt" run:
I've been analysing the kernel's start-up code that sets the console.
The selection of the dummy console occurs in drivers/ video/console/ vgacon. c::vgacon_ startup( )
There is a code label "novga" which results in the VGA console driver not being used:
if (screen_ info.orig_ video_isVGA == VIDEO_TYPE_VLFB || info.orig_ video_isVGA == VIDEO_TYPE_EFI) { DUMMY_CONSOLE >con_startup( );
screen_
no_vga:
#ifdef CONFIG_
conswitchp = &dummy_con;
return conswitchp-
#else
return NULL;
#endif
The "novga" label is also reached from later code that checks boot_params. screen_ info has been initialized, and then whether the screen is in a VGA16 mode not handled by VGACON.
/* boot_params. screen_ info initialized? */ info.orig_ video_mode == 0) && info.orig_ video_lines == 0) && info.orig_ video_cols == 0))
if ((screen_
(screen_
(screen_
goto no_vga;
/* VGA16 modes are not handled by VGACON */ info.orig_ video_mode == 0x0D) || /* 320x200/4 */ info.orig_ video_mode == 0x0E) || /* 640x200/4 */ info.orig_ video_mode == 0x10) || /* 640x350/4 */ info.orig_ video_mode == 0x12) || /* 640x480/4 */ info.orig_ video_mode == 0x6A)) /* 800x600/4 (VESA) */
if ((screen_
(screen_
(screen_
(screen_
(screen_
goto no_vga;
For a while I was chasing a presumption that arch/x86/ kernel/ setup.c: :setup_ arch() was enabling EFI support with
efi_enabled=1;
After a lot of analysis of boot_params. efi_info I arrived at the "novga" code and realised it can also be triggered by the boot-loader leaving the display in a graphic mode.
I then investigated the GRUB configuration and discovered the GRUB_GFXPAYLOAD _LINUX option, described in the blueprint
https:/ /blueprints. launchpad. net/ubuntu/ +spec/packagese lection- foundations- n-grub2- boot-framebuffe r
The bug can be fixed in "/etc/default/grub" by adding
GRUB_GFXPAYLOAD _LINUX= text
However, this is a local workaround. The blueprint refers to the file "/boot/ grub/gfxblackli st" which is generated by a script in the package "grub-gfxpayloa d-lists" . The file contains PCI IDs of video devices that GRUB should not leave in graphics mode. These are declared in "/usr/share/ grub-gfxpayload -lists/ blacklist/ "
The attached patch adds a new file "20_intel" to the blacklisted devices in the package.
If adding it manually to a system, place it in the "/usr/share/ grub-gfxpayload -lists/ blacklist/ " directory.
To add the new device to "/boot/ grub/gfxblackli st.txt" run:
sudo update- grub-gfxpayload