From Fedora Project Wiki
 
(43 intermediate revisions by 7 users not shown)
Line 5: Line 5:
== Summary ==
== Summary ==


The startup experience needs to be flicker-free, seamless and shiny.
The startup experience needs to be flicker-free, seamless and shiny.  To do this we are getting rid of RHGB and writing a new program, Plymouth, that starts earlier (even before / is mounted!), doesn't require an X server, and gets rid of a lot of the noise during startup.
 
Plymouth will requires DRM kernel modesetting drivers to get pretty graphics, but will have a text mode fallback for systems without driver support.


== Owner ==
== Owner ==
* Name: RayStrode, JonMcCann, PeterJones, DavidAirlie et al
* Name: RayStrode, KristianHoegsberg, JonMcCann, PeterJones, DavidAirlie, JeremyKatz et al


== Current status ==
== Current status ==
* Targeted release: Fedora 10
* Targeted release: Fedora 10
* Last updated: 2008-06-02
* Last updated: 2008-10-21
* Percentage of completion: 25%
* Percentage of completion: 100%
 
F9 had kernel modesetting for Intel hardware.
Ray has been working on a prototype rhgb replacement called Plymouth. It was put on hold while kernel modesetting was maturing, and has been revived after F9.  Modesetting is again in flux, though, in rawhide, since there are two memory managers in play.  These are the long anticipated TTM memory manager from tungsten graphics, and the newer GEM memory manager from Eric Anholt at Intel that supercedes TTM.  Intel is currently targeting working Intel kernel modesetting driver on top of GEM by F10. 
 
ATI recently released a kernel side atom parser to make radeon kernel modesetting (at least for r500 and higher) possible. Dave Airlie uses that parser to provide a GEM like api on top of the existing work that uses the TTM memory manager.  We have kernel modesetting for most ATI hardware for F10.


F9 has kernel modesetting for Intel hardware.
The current plymouth sources can be found here: http://gitweb.freedesktop.org/?p=plymouth;a=summary . There are plymouth packages in rawhide already, though, some modesetting drivers, aren't, so a lot of people won't be able to see graphical boot up.  Having said that, we enable the text plugin by default now.  Anyone using rawhide will see it, although it's sort of ugly and flickery.  Live images now also run plymouth in their initrd.
Ray has been working on a prototype rhgb replacement called Plymouth. It was put on hold while kernel modesetting was maturing, and has been revived after F9. The current plymouth sources can be found here: http://gitweb.freedesktop.org/?p=plymouth;a=summary . There are plymouth packages in rawhide already, but they are not useful for trying it out until the necessary mkinitrd changes land.


== Usage cases/rationale ==
The new startup sequence (including quiet kernel,
quiet grub, plymouth, smooth transition to the login screen) has been demonstrated at the Red Hat Summit
and was shown informally to various people at FUDcon.


== Scope ==
== Scope ==
Line 28: Line 36:
== Test Plan ==
== Test Plan ==


* Verify that holding a key during power-on gets you to the grub menu
* Verify that boot without rhgb in the kernel cmdline gives a traditional text mode boot sequence
* Verify that boot without rhgb in the kernel cmdline gives a traditional text mode boot sequence
* Verify that failure to set a mode in initrd falls back to a traditional text mode boot sequence
* Verify that failure to set a mode in initrd falls back to a clean and simple text mode boot sequence
* Verify that the graphical boot sequence contains only a single mode switch from blank text mode
* Verify that the graphical boot sequence contains only a single mode switch from blank text mode to graphical mode, and that there is a smooth transition from the startup animation to the login screen
to graphical mode, and that there is a smooth transition from the startup animation to the login
screen
* Verify that entering encryption passwords works both in the graphical case and in the fallback case
* Verify that entering encryption passwords works both in the graphical case and in the fallback case
* Verify that specifying a mode in the kernel commandline works
* Verify that specifying a mode in the kernel commandline works
* Verify that failure messages from service startup can inspected after boot
* Verify that failure messages from service startup can be inspected after boot
* Verify that dropping to a shell on critical errors works
* Verify that dropping to a shell on critical errors works
* Verify that pressing Escape in plymouth brings you to the detailed mode showing boot messages
* Verify that all of the above work with non-US keyboards


== Dependencies ==
== Dependencies ==


This feature depends on plymouth getting into F10. It also depends on a ton of other things...
This feature depends on plymouth getting into F10. For other packages involved in realizing this feature, see Scope.


== Details ==
== Details ==
Line 51: Line 60:
* there should be good, smooth transitions
* there should be good, smooth transitions


The fallback if mode-setting is present in the initrd but fails, is a standard 1024x786 mode.
The fallback if mode-setting fails or is unavailable is text mode.
The fallback if mode-setting is not in the initrd is text mode.


=== Timeline of the current bootup ===
=== Timeline of the current bootup ===
Line 84: Line 92:


* do away with mode switch for grub menu by default (ie, don't show the image unless "needed")
* do away with mode switch for grub menu by default (ie, don't show the image unless "needed")
** This is in rawhide now, but the default configuration isn't making use of it.
* make kernel, nash and init obey the quiet option
* make kernel, nash and init obey the quiet option
** There are patches for these, though the kernel keeps sneaking messages in.
* switch to graphical mode in the initrd, draw an animation and keep it running until gdm starts up
* switch to graphical mode in the initrd, draw an animation and keep it running until gdm starts up
** We have an animation but need there are some changes we need to make to the X server and GDM to keep the transitions smooth
* rhgb goes away
* rhgb goes away
** rhgb is already gone
* make the X server started by gdm take over the existing vt, mode and framebuffer content
* make the X server started by gdm take over the existing vt, mode and framebuffer content
** krh has a patch which adds a -nr ("no root") option which makes the root window keep the framebuffer contents that were around when X started
* improve the transitions animation -> gdm -> session
* improve the transitions animation -> gdm -> session
* firstboot runs on the gdm X server
* firstboot runs on the gdm X server
Line 113: Line 126:
|}
|}


One complication is support for encrypted disks. This may require us to ask for a password in the initrd, before
One complication is support for encrypted disks. This may require us to ask for a password in the initrd, before we have X or toolkits. The proposal for acceptable input-handling (at least as far as keyboard layouts are concerned) is to write an xkb-to-console-converter.
we have X or toolkits. The proposal for acceptable input-handling (at least as far as keyboard layouts are concerned)
is to write an xkb-to-console-converter.


=== Tasks ===
=== Tasks ===


* Make grub not display a splash image unless the user enters the menu. It has been pointed out that a timeout of 0 is not ideal for this, the current timeout value of 3 may be just fine.
* Make grub not display a splash image unless the user holds down some key (such as ctrl) to get to a menu. Grub will have a near zero timeout, but users will be able to hold the key down at the bios before grub shows up.
* Make grub not report which choice was selected if the user didn't pick a choice [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239760 #239760]  
* Make grub not report which choice was selected if the user didn't pick a choice [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239760 #239760]  
* Make drm drivers/mode-setting happen in the upstream kernel (see http://www.ussg.iu.edu/hypermail/linux/kernel/0705.2/0893.html)
* Make drm drivers/mode-setting happen in the upstream kernel (see http://www.ussg.iu.edu/hypermail/linux/kernel/0705.2/0893.html)
* Put drm drivers in the initrd
* Put drm drivers in the initrd
* If rhgb is in the kernel commandline, switch mode in initrd, use drmfb on vt7
* If rhgb is in the kernel commandline, switch mode in initrd, use drmfb and then GDM on vt1
* If rhgb is not in the kernel commandline, we still run plymouthd and it handles input but we just don't do the graphical plugins.  This lets us consistently be able to count on plymouth being available
* Put animation drawing app in the initrd, keep initrd mounted until that app exits
* Put animation drawing app in the initrd, keep initrd mounted until that app exits
* For selecting the mode, make s-c-d set a kernel commandline like rhgb=1600x1200
* Open question: what about multihead ? answer for now: all heads painted in background color except one chosen randomly with animation
* Open question: what about multihead ? answer for now: clone mode
* Display animation all the way from initrd until gdm comes up, keep initrd mounted until it exits
* Display animation all the way from initrd until gdm comes up, keep initrd mounted until it exits
* Redirect init output early on to a pseudo-terminal
* Redirect init output early on to a pseudo-terminal
* Have something that buffers the output, can buffer it on the initrd
* Have something that buffers the output, can buffer it on the initrd
* If something happens that drops us to a shell (filesystem errors), hook up a framebuffer console with
* If something happens that drops us to a shell (filesystem errors), hook up a framebuffer console with the pseudo-terminal
the pseudo-terminal
* If there are warnings in the saved bootup messages, show a "Show boot messages" button on the login screen and/or in the notification area
* If there are warnings in the saved bootup messages, show a "Show boot messages" button on the login
* Need to start X on the existing vt, not set mode (unless we are still in text mode), preserve existing framebuffer content
screen and/or in the notification area
* Need to start X on the existing vt, not set mode (unless we are still in text mode), preserve existing
framebuffer content
* Coordinate session startup. fade in ? might be able to do something nice if we have compositing
* Coordinate session startup. fade in ? might be able to do something nice if we have compositing
== Post F10 TODO ==
* Need to get intel modesetting drivers working.
* Make sure grub patch works with efi, too.  This would probably have to be either Peter or krh, since Peter knows about EFI, krh wrote the silent patch for legacy bioses, and both have efi hardware.  Peter is planning on moving grub over to an efi library, so this should block on that.
* Need to make an upstream webpage, and also do a write up that compares plymouth to other graphical boot splashes


== Contingency Plan ==
== Contingency Plan ==


If things don't work out as expected, we can bring back rhgb from the dead.
If things wouldn't have worked out as expected, we could have brought back rhgb from the dead.
 
== User Documentation ==
 
Plymouth's graphical boot plugins require kernel modesetting (KMS) support.  KMS is currently supported on most ATI Radeon chips; anything from the Radeon 9500 and newer should work.  Intel KMS support is in development, but is not yet supported.  An early version of the graphical boot sequence looks like [http://katzj.fedorapeople.org/plymouth-live.ogg this].
 
For all other graphics hardware, the text plugin is used, and looks like [http://ajax.fedorapeople.org/text-boot-hotness.ogg this].
 
Plymouth's behaviour can be controlled through kernel command line options:
* 'rhgb' on the command line will direct plymouth to run with defaults.  Removing rhgb will force it to run in detailed mode.
* 'nomodeset' on the command line will direct the kernel to not enable KMS support in the DRM driver.  Use this option if you experience stability problems in X or if the graphical plugin hangs.
* 'vga=0x318' on the command line will force the hardware into graphics mode without using KMS drivers.  This will give 1024x768 resolution and will have weird interactions with X, so should only be used for testing.
 
== Developer Documentation ==
 
We eventually need to have developer documentation for
* communicating with plymouth from init scripts
* writing plugins for plymouth


== Documentation ==
For now, all we have is the [http://cgit.freedesktop.org/plymouth/tree/README README] in the plymouth git repository.


== Release Notes ==
== Release Notes ==


== Comments ==
The release notes need to explain how to get to the grub menu by holding a key during power-on. Should also explain that the graphical mode of plymouth requires kernel modesetting and will only work on certain hardware (likely only intel for F10), or by forcing a vga mode on the kernel cmdline. Also, switching to detailed mode with Escape should be mentioned, along with the fact that boot warnings will be available via a statusicon on the login screen.
* LuyaTshimbalanga: What happened to early-login project?
 
* "Ray Strode: early-login was ditched a while ago, though, Jon Nettleton recently started something similiar. See fedora-desktop-list"
== Comments and Discussion ==
* MartinJürgens: The shutdown experience should also be nice and shiny. Would be nice if this spec would include that.
 
* "Ray Strode: potentially, although I'd like shutdown to just be 'kill all processes that have open files' and cut power"
See [[Talk:Features/BetterStartup]]
* MikePetullo: There is an [https://fedoraproject.org/wiki/Releases/FeatureEncryptedFilesystems effort] to bring encrypted root filesystems to Fedora. One of the weaknesses of our work so far is that we can't provide an ''internationalized'' encryption key prompt very early in the boot process (i.e., in the initrd). Could this better startup feature allow us to do this?
 
* "Ray Strode: Given that encrypted block devices are slated for F9, i think we have to bring this into account.  I talked to Jeremy Katz about this last week some.  The answer to the i18n problem, may be to use icons instead of text.  We could potentially have text, but it means bringing in my libraries, potentially translations, etc"
----
----
[[Category:ProposedFedora10]]
 
[[Category:FeatureAcceptedF10]]

Latest revision as of 18:10, 16 June 2009

Better Startup Experience (Graphical Boot Sequence)

Summary

The startup experience needs to be flicker-free, seamless and shiny. To do this we are getting rid of RHGB and writing a new program, Plymouth, that starts earlier (even before / is mounted!), doesn't require an X server, and gets rid of a lot of the noise during startup.

Plymouth will requires DRM kernel modesetting drivers to get pretty graphics, but will have a text mode fallback for systems without driver support.

Owner

  • Name: RayStrode, KristianHoegsberg, JonMcCann, PeterJones, DavidAirlie, JeremyKatz et al

Current status

  • Targeted release: Fedora 10
  • Last updated: 2008-10-21
  • Percentage of completion: 100%

F9 had kernel modesetting for Intel hardware. Ray has been working on a prototype rhgb replacement called Plymouth. It was put on hold while kernel modesetting was maturing, and has been revived after F9. Modesetting is again in flux, though, in rawhide, since there are two memory managers in play. These are the long anticipated TTM memory manager from tungsten graphics, and the newer GEM memory manager from Eric Anholt at Intel that supercedes TTM. Intel is currently targeting working Intel kernel modesetting driver on top of GEM by F10.

ATI recently released a kernel side atom parser to make radeon kernel modesetting (at least for r500 and higher) possible. Dave Airlie uses that parser to provide a GEM like api on top of the existing work that uses the TTM memory manager. We have kernel modesetting for most ATI hardware for F10.

The current plymouth sources can be found here: http://gitweb.freedesktop.org/?p=plymouth;a=summary . There are plymouth packages in rawhide already, though, some modesetting drivers, aren't, so a lot of people won't be able to see graphical boot up. Having said that, we enable the text plugin by default now. Anyone using rawhide will see it, although it's sort of ugly and flickery. Live images now also run plymouth in their initrd.

The new startup sequence (including quiet kernel, quiet grub, plymouth, smooth transition to the login screen) has been demonstrated at the Red Hat Summit and was shown informally to various people at FUDcon.

Scope

Requires changes to grub, mkinitrd, initscripts, gdm, X, possibly other packages. rhgb will be replaced by Plymouth. The extent of this project is getting a graphical boot sequence that is polished and professional looking.

Boot up could be made faster, too, but that issue is orthogonal and should be tracked separately .

Test Plan

  • Verify that holding a key during power-on gets you to the grub menu
  • Verify that boot without rhgb in the kernel cmdline gives a traditional text mode boot sequence
  • Verify that failure to set a mode in initrd falls back to a clean and simple text mode boot sequence
  • Verify that the graphical boot sequence contains only a single mode switch from blank text mode to graphical mode, and that there is a smooth transition from the startup animation to the login screen
  • Verify that entering encryption passwords works both in the graphical case and in the fallback case
  • Verify that specifying a mode in the kernel commandline works
  • Verify that failure messages from service startup can be inspected after boot
  • Verify that dropping to a shell on critical errors works
  • Verify that pressing Escape in plymouth brings you to the detailed mode showing boot messages
  • Verify that all of the above work with non-US keyboards

Dependencies

This feature depends on plymouth getting into F10. For other packages involved in realizing this feature, see Scope.

Details

For a smooth and shiny experience, we want

  • the mode should be changed early from text mode to the most optimal graphics mode available
  • the mode should not be changed more than once
  • there should be no other uncontrolled transitions
  • there should be no text messages, unless the user presses Escape to see them
  • there should be good, smooth transitions

The fallback if mode-setting fails or is unavailable is text mode.

Timeline of the current bootup

bios text
grub graphical
grub info 4>text
kernel boot
initrd drivers
init
rhgb graphical
text login text
gdm 3>graphical
gnome startup
user session

Plan for improving this

  • do away with mode switch for grub menu by default (ie, don't show the image unless "needed")
    • This is in rawhide now, but the default configuration isn't making use of it.
  • make kernel, nash and init obey the quiet option
    • There are patches for these, though the kernel keeps sneaking messages in.
  • switch to graphical mode in the initrd, draw an animation and keep it running until gdm starts up
    • We have an animation but need there are some changes we need to make to the X server and GDM to keep the transitions smooth
  • rhgb goes away
    • rhgb is already gone
  • make the X server started by gdm take over the existing vt, mode and framebuffer content
    • krh has a patch which adds a -nr ("no root") option which makes the root window keep the framebuffer contents that were around when X started
  • improve the transitions animation -> gdm -> session
  • firstboot runs on the gdm X server

This lets us start with a blank screen in text mode, then a single switch to graphics mode, then an animation, then the login screen fades in.

bios 3>text
grub
kernel boot
initrd drivers 5>graphical
init
gdm
gnome startup
user session

One complication is support for encrypted disks. This may require us to ask for a password in the initrd, before we have X or toolkits. The proposal for acceptable input-handling (at least as far as keyboard layouts are concerned) is to write an xkb-to-console-converter.

Tasks

  • Make grub not display a splash image unless the user holds down some key (such as ctrl) to get to a menu. Grub will have a near zero timeout, but users will be able to hold the key down at the bios before grub shows up.
  • Make grub not report which choice was selected if the user didn't pick a choice #239760
  • Make drm drivers/mode-setting happen in the upstream kernel (see http://www.ussg.iu.edu/hypermail/linux/kernel/0705.2/0893.html)
  • Put drm drivers in the initrd
  • If rhgb is in the kernel commandline, switch mode in initrd, use drmfb and then GDM on vt1
  • If rhgb is not in the kernel commandline, we still run plymouthd and it handles input but we just don't do the graphical plugins. This lets us consistently be able to count on plymouth being available
  • Put animation drawing app in the initrd, keep initrd mounted until that app exits
  • Open question: what about multihead ? answer for now: all heads painted in background color except one chosen randomly with animation
  • Display animation all the way from initrd until gdm comes up, keep initrd mounted until it exits
  • Redirect init output early on to a pseudo-terminal
  • Have something that buffers the output, can buffer it on the initrd
  • If something happens that drops us to a shell (filesystem errors), hook up a framebuffer console with the pseudo-terminal
  • If there are warnings in the saved bootup messages, show a "Show boot messages" button on the login screen and/or in the notification area
  • Need to start X on the existing vt, not set mode (unless we are still in text mode), preserve existing framebuffer content
  • Coordinate session startup. fade in ? might be able to do something nice if we have compositing

Post F10 TODO

  • Need to get intel modesetting drivers working.
  • Make sure grub patch works with efi, too. This would probably have to be either Peter or krh, since Peter knows about EFI, krh wrote the silent patch for legacy bioses, and both have efi hardware. Peter is planning on moving grub over to an efi library, so this should block on that.
  • Need to make an upstream webpage, and also do a write up that compares plymouth to other graphical boot splashes

Contingency Plan

If things wouldn't have worked out as expected, we could have brought back rhgb from the dead.

User Documentation

Plymouth's graphical boot plugins require kernel modesetting (KMS) support. KMS is currently supported on most ATI Radeon chips; anything from the Radeon 9500 and newer should work. Intel KMS support is in development, but is not yet supported. An early version of the graphical boot sequence looks like this.

For all other graphics hardware, the text plugin is used, and looks like this.

Plymouth's behaviour can be controlled through kernel command line options:

  • 'rhgb' on the command line will direct plymouth to run with defaults. Removing rhgb will force it to run in detailed mode.
  • 'nomodeset' on the command line will direct the kernel to not enable KMS support in the DRM driver. Use this option if you experience stability problems in X or if the graphical plugin hangs.
  • 'vga=0x318' on the command line will force the hardware into graphics mode without using KMS drivers. This will give 1024x768 resolution and will have weird interactions with X, so should only be used for testing.

Developer Documentation

We eventually need to have developer documentation for

  • communicating with plymouth from init scripts
  • writing plugins for plymouth

For now, all we have is the README in the plymouth git repository.

Release Notes

The release notes need to explain how to get to the grub menu by holding a key during power-on. Should also explain that the graphical mode of plymouth requires kernel modesetting and will only work on certain hardware (likely only intel for F10), or by forcing a vga mode on the kernel cmdline. Also, switching to detailed mode with Escape should be mentioned, along with the fact that boot warnings will be available via a statusicon on the login screen.

Comments and Discussion

See Talk:Features/BetterStartup