BootGraphicsArchitecture

Differences between revisions 1 and 2
Revision 1 as of 2011-10-02 05:52:44
Size: 4221
Editor: vorlon
Comment:
Revision 2 as of 2011-10-02 05:57:58
Size: 4313
Editor: vorlon
Comment:
Deletions are marked like this. Additions are marked like this.
Line 7: Line 7:

These settings can all be configured via the {{{/etc/default/grub}}} configuration file.

As of 11.10, Ubuntu includes graphics handling in its x86 boot sequence that is intended to provide an optimal, flicker-free graphical boot experience across a range of hardware and drivers. This page documents the components of this graphical boot architecture.

Boot loader

From Ubuntu 9.10 on, the Ubuntu desktop uses GRUB2 as the default bootloader. GRUB2 includes support, enabled by default, for displaying a graphical boot screen using the VESA BIOS extensions ("insmod vbe", "insmod gfxterm"). Ubuntu will use the preferred resolution as returned by VBE ("set gfxmode=auto").

More recent versions of GRUB2 also add support for passing this graphical boot screen through to the kernel at boot time as a pre-initialized linear framebuffer ("set gfxpayload=keep"). This enables the Linux kernel to start up in the preferred graphics video mode, instead of the traditional behavior of starting up in text mode and modesetting the video output afterwards.

These settings can all be configured via the /etc/default/grub configuration file.

GRUB2 is also configured to pass vt.handoff=7 to the kernel on the commandline, telling the kernel to start with this graphical display on VT7 instead of the default of VT1.

Live CD

FIXME: insert details about live CD bootloader graphics handling here

Kernel video initialization

Ubuntu relies on udev to detect video drivers for the hardware. For most cases a driver will be found and loaded by udev that provides a framebuffer interface to the kernel (/dev/fb0). In some cases however, such as when binary video drivers are configured (nvidia, fglrx) or when no native driver is available for a video device, it is necessary to fall back to the vesafb driver which uses the same linear framebuffer that GRUB does.

The fallback to vesafb is racy, because it is only loaded when no other more appropriate driver is detected, and there's never a good way to know when the kernel has finished notifying udev about a particular bus. In practice, the video system is among the first devices detected by the kernel, so there is very little risk of vesafb being loaded incorrectly because the video interface was found too slowly. If vesafb were probed before the correct driver, a suboptimal framebuffer interface would be used until the next reboot. In some cases, corrupted video output may also result due to the kernel console and the X server using different framebuffers.

Although loading multiple framebuffer drivers for the same video card would be problematic, and loading the nouveau and nvidia drivers at the same time, or the radeon and fglrx drivers at the same time, would not work correctly, it is expected that the vesafb driver will be loaded together with either of the nvidia or fglrx binary drivers and that vesafb will provide the framebuffer console interface while the binary driver is used exclusively for X.

Some users have reported that using the uvesafb driver instead of vesafb gives better results. This should not be necessary with the current bootloader framebuffer hand-off.

Initramfs

In the default case, there is no video handling in the initramfs. Video drivers are not included in the initramfs, nor is plymouth; the splash screen initialization is deferred until the switch to the root filesystem, for optimal boot speed.

This lack of video handling also means that break= boot options to interrupt the initramfs do not work correctly when gfxpayload=keep is set, as nothing is able to reset the console to text mode and as a result the command prompt is not visible (864466).

If cryptsetup is installed, however, as is the case whenever ecryptfs-encrypted home directories are selected at install time, framebuffer handling is included in the initramfs. This is done to support using plymouth to prompt for the passphrase for an encrypted root filesystem, but currently cryptsetup is included in the initramfs unconditionally whenever it's installed (444704). This results in the framebuffer always being initialized for plymouth's use in the initramfs.

Post-initramfs

Plymouth

Recovery mode

BootGraphicsArchitecture (last edited 2012-04-26 08:07:01 by host-89-243-201-237)