BootGraphicsArchitecture

Differences between revisions 3 and 4
Revision 3 as of 2011-10-02 06:17:00
Size: 5486
Editor: vorlon
Comment: recovery mode
Revision 4 as of 2011-10-02 07:06:16
Size: 6392
Editor: vorlon
Comment: plymouth
Deletions are marked like this. Additions are marked like this.
Line 35: Line 35:
Plymouth is always started as early as possible in the boot sequence in order to capture any messages (including questions and prompts) which should be displayed to the user; however, the splash screen is not displayed until the kernel has had a chance to initialize the framebuffer interface. On systems with sufficiently fast disks when there are no prompts requiring user interaction, this means that the plymouth splash screen may appear only briefly before X starts, or may not appear at all. This is a deliberate tradeoff between boot speed and visibility of the splash screen, because the only way to ensure the splash screen is shown is to start it from the initramfs, where the system would block waiting for the video to be initialized. (Bug:540801) The lack of splash screen is expected to be less of a concern going forward, now that GRUB brings the console up in graphics mode by default.

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

When video initialization is not handled in the initramfs, it will instead be handled by udev when started from the root filesystem. This uses the same fallback to vesafb as in the initramfs case, via /etc/init/udev-fallback-graphics.conf. Binary video drivers, if configured, are always loaded from the rootfs and not from the initramfs. It is therefore assumed that binary drivers will interoperate with vesafb regardless of whether they are loaded before or after the framebuffer.

Plymouth

Plymouth is always started as early as possible in the boot sequence in order to capture any messages (including questions and prompts) which should be displayed to the user; however, the splash screen is not displayed until the kernel has had a chance to initialize the framebuffer interface. On systems with sufficiently fast disks when there are no prompts requiring user interaction, this means that the plymouth splash screen may appear only briefly before X starts, or may not appear at all. This is a deliberate tradeoff between boot speed and visibility of the splash screen, because the only way to ensure the splash screen is shown is to start it from the initramfs, where the system would block waiting for the video to be initialized. (540801) The lack of splash screen is expected to be less of a concern going forward, now that GRUB brings the console up in graphics mode by default.

Recovery mode

The kernel console is always started in text mode when booting the "recovery mode" option. This is mostly an accident due to bug 864466, though it also serves the goal of maximizing the debuggability of booting in recovery mode since the full kernel output will be shown from the beginning. However, since the usual reason for booting into recovery mode is that a normal boot does not succeed, for most users the GRUB2 "recordfail" handling (which switches the console to text mode automatically after a failed boot) would be sufficient; so the recovery mode may be switched to use gfxpayload=keep at a later date once bug 864466 is fixed.

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