BulletProofX

Differences between revisions 1 and 19 (spanning 18 versions)
Revision 1 as of 2006-11-09 20:04:52
Size: 618
Editor: 65
Comment:
Revision 19 as of 2007-01-31 10:42:51
Size: 8311
Editor: 82-69-40-219
Comment: update LP URLs; fix for 59618 uploaded
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
## Register at https://launchpad.net/distros/ubuntu/+specs
 * '''Launchpad entry''': https://features.launchpad.net/distros/ubuntu/+spec/bullet-proof-x
 * '''Packages affected''': 
## Register at https://launchpad.net/ubuntu/+specs
 * '''Launchpad entry''': https://blueprints.launchpad.net/ubuntu/+spec/bullet-proof-x
 * '''Packages affected''':
Line 8: Line 8:
The goal of the bullet proof X specification is to ensure that there is always a way to load the X server, by falling back, automatically or manually, on a working video mode if the default one failed.
Line 10: Line 11:
A lot of people are capable of configuring their systems (or getting help to do so) via a graphical interface but don't have a clue when it comes to the command line interface.
Line 16: Line 18:
=== How things works, before this spec ===
==== At Grub level ====
"Start Ubuntu in safe graphics mode" option of the LiveCD, make '''xforcevesa''' added to the kernel boot parameters, which is fine for manually choosing safe mode, but not for automatically detecting bad X configuration. The debconf script of xserver-xorg, when executed, sees that "xforcevesa" flag is in use and sets vesa as the default driver.
==== On installing the system ====
==== At each configuration of the server ====
Debconf of xserver-xorg, seems to call dexconf (from x11-common package), to make a new /etc/X11/xorg.conf. In high priority, questions about video modes are asked. Seems like dexconf works quite differently than X -configure in the sense that X -configure need to try to start the X server while dexconf not. Also, dexconf put video modes info in xorg.conf, where X -configure does not. In fact on my computer X -configure make an xorg.conf that fails to find PS/2 mouse, while dexconf do. Yet, I have no idea how dexconf works yet. --Paul Dufresne
==== When Gnome starts ====
[http://www.icims.csl.uiuc.edu/~lheal/doc/gdm/x155.html Some GDM doc]
GDM try to call X. If it fails, FailsafeXServer of gdm.conf is called.
If even that failed, then XKeepsCrashing (by default etc/gdm/XKeepsCrashing) is called.
XKeepsCrashing script will try to use the XKeepsCrashingConfigurators (first of /usr/bin/X11/XF86Setup /usr/bin/X11/Xconfigurator that will works).
==== When Kubuntu starts ====
I can't find an equivalent of gdm's FailsafeXServer for kdm. --Paul Dufresne
==== Each time X is started ====
==== Some applets to change video mode? ====
==== When logging off from a user in GNOME ====
Normally, the X server is reinitialised, but if AlwaysRestartServer=true then gdm will just kill the existing server and start over. See UnresolvedIssues down, to why we may want to set it true.
==== When logging off from a user in Kubuntu ====
The [X-*-Core] section class of kdmrc have the option TerminateServer (false by default),
which if set to true make kdm restart the local X-Server after session exit instead of resetting it. Use this if the X-Server leaks memory or crashes the system on reset attempts.

=== High-Level Design ===
VESA mode 800x600x256 is hereafter called safeMode1.
'Safe Mode' is written on safeMode1 screen.

safeMode1 is triggered in any of the following circumstances:
 * gdm detects that the X server is failing to start (FailsafeXServer)
 * grub have been booted with option safe mode boot (rather than normal boot)

=== Low-Level Design ===

=== Design discussion ===
The configuration fall back process should be:
 * safeMode1, which is sane given the current state of hardware out there, and Windows XP and above also use 800x600 in their safe mode.
   * run dpkg-reconfigure by passing an environment variable
   * xserver-xorg.config should check for an environment variable which behaves the same as xforcevesa
 * If that fails, provide an error on the console.
     * We discussed falling back to vga (safeMode2) instead of just provide an error to the console, but that would introduce another mode switch and delay before the error is shown, and vesa is very well established nowadays.

UI should offer the following options:
  * attempt automatic reconfiguration of video settings
    * can we do this first, and only prompt the user to accept/reject if the auto-config is different from their existing configuration? If yes, they should be prompted to restart in test mode, if no, continue in safe mode.
  * dpkg-reconfigure
  * if that produces a different configuration, allow the sure to test by logging them out and allowing the display manager to restart X
 * give up and use this mode: 'Use these video settings for your normal use'?

 * display diagnostics of what failed - for giving to technical support/showing their local 'computer expert.'

Because it is quite unclear if kdm have some equivalent of gdm's FailsafeXServer script, I say that it is not a good design choice to set safeMode1 by there. I think '''UpStart''' should have a startx event trying to start normally the X server. If X fail to start, then make the XServerFailed event start the safeScreenMode1 job. Later, when the session is started, it would be easy to ask Upstart if safeScreenMode1 job is active, and pop up a window to the user saying that X have not been able to start normally. It is unclear if Upstart is ready for this, but seems like a good test for it. Moreover, it is already one of the goal of [https://blueprints.launchpad.net/ubuntu/+spec/replacement-initscripts replacement-initscripts spec] to be controlled by Upstart ideally for feisty. --Paul Dufresne

I suggest to do like Windows, that is when xserver is reconfigure or configured, the first boot after that, ask the user if he/she should continue to use that video mode, or fallback on safeMode1. (The "Can you read this?" question on Windows) [ System/Preferences/ScreenResolution(translating) already does that, but the new twist is to do it on first boot after xserver-xorg (re)configuration] --Paul Dufresne
Line 18: Line 71:
[This section should show how the implementation is different than the design section]
Line 24: Line 79:
Until [https://launchpad.net/ubuntu/+source/xorg/+bug/59618 bug #59618] patch is not released, then grub 'Safe mode' won't work. '''[done 2007-01-31]'''

From Forum topic [http://ubuntuforums.org/showthread.php?t=318142]
...sometimes logging out results in a black screen and a system freeze. None of the exit shortcut keys work, and I can't restart X.

I found a very reliable fix to this issue was changing the following line (line 96) in the /etc/gdm/gdm.conf file to this:

   AlwaysRestartServer=true

This forces GDM to restart X completely before returning to the login screen...

The [X-*-Core] section class of kdmrc have the option TerminateServer for this. (Paul Dufresne)

I propose to make this into the default configuration in Feisty Fawn.

I now think that previous problem should not be fixed by making AlwaysRestartServer true, but rather by using Upstart to monitor that resetting X server is completed within a reasonable delay (which should depend on the speed of the CPU), and failing to do so, should restart X instead. This would means that the server is broken, and a bug submission should ideally be made if that happens. But up to now, it would have to wait each time we log out, for the reasonable delay, making it worst than AlwaysRestartServer for that broken X server. So that a better design would emit a x-server-broken event with argument watchdog for this. On that event, a always-restart-server-watchdog upstart's job would be started, that would replace the algorithm of this to make the reset-x job to now over do a restart-x job, until the x-server be fixed and send a x-server-been-fixed event :-). Also, it would be good for the reset-x job to compare the memory space occupied from the X-server before and after the script, and emit a x-server-broken event with argument x-memory-leaks that would trigger always-restart-server-memoryleaks job, which would be identical to always-restart-server-watchdog, except offering to send a different bug report. --Paul Dufresne

Future work:
 * Fall back for thin clients
 * Kubuntu

Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.

Summary

The goal of the bullet proof X specification is to ensure that there is always a way to load the X server, by falling back, automatically or manually, on a working video mode if the default one failed.

Rationale

A lot of people are capable of configuring their systems (or getting help to do so) via a graphical interface but don't have a clue when it comes to the command line interface.

Use cases

Scope

Design

How things works, before this spec

At Grub level

"Start Ubuntu in safe graphics mode" option of the LiveCD, make xforcevesa added to the kernel boot parameters, which is fine for manually choosing safe mode, but not for automatically detecting bad X configuration. The debconf script of xserver-xorg, when executed, sees that "xforcevesa" flag is in use and sets vesa as the default driver.

On installing the system

At each configuration of the server

Debconf of xserver-xorg, seems to call dexconf (from x11-common package), to make a new /etc/X11/xorg.conf. In high priority, questions about video modes are asked. Seems like dexconf works quite differently than X -configure in the sense that X -configure need to try to start the X server while dexconf not. Also, dexconf put video modes info in xorg.conf, where X -configure does not. In fact on my computer X -configure make an xorg.conf that fails to find PS/2 mouse, while dexconf do. Yet, I have no idea how dexconf works yet. --Paul Dufresne

When Gnome starts

[http://www.icims.csl.uiuc.edu/~lheal/doc/gdm/x155.html Some GDM doc] GDM try to call X. If it fails, FailsafeXServer of gdm.conf is called. If even that failed, then XKeepsCrashing (by default etc/gdm/XKeepsCrashing) is called. XKeepsCrashing script will try to use the XKeepsCrashingConfigurators (first of /usr/bin/X11/XF86Setup /usr/bin/X11/Xconfigurator that will works).

When Kubuntu starts

I can't find an equivalent of gdm's FailsafeXServer for kdm. --Paul Dufresne

Each time X is started

Some applets to change video mode?

When logging off from a user in GNOME

Normally, the X server is reinitialised, but if AlwaysRestartServer=true then gdm will just kill the existing server and start over. See UnresolvedIssues down, to why we may want to set it true.

When logging off from a user in Kubuntu

The [X-*-Core] section class of kdmrc have the option TerminateServer (false by default), which if set to true make kdm restart the local X-Server after session exit instead of resetting it. Use this if the X-Server leaks memory or crashes the system on reset attempts.

High-Level Design

VESA mode 800x600x256 is hereafter called safeMode1. 'Safe Mode' is written on safeMode1 screen.

safeMode1 is triggered in any of the following circumstances:

  • gdm detects that the X server is failing to start (FailsafeXServer)
  • grub have been booted with option safe mode boot (rather than normal boot)

Low-Level Design

Design discussion

The configuration fall back process should be:

  • safeMode1, which is sane given the current state of hardware out there, and Windows XP and above also use 800x600 in their safe mode.
    • run dpkg-reconfigure by passing an environment variable
    • xserver-xorg.config should check for an environment variable which behaves the same as xforcevesa
  • If that fails, provide an error on the console.
    • We discussed falling back to vga (safeMode2) instead of just provide an error to the console, but that would introduce another mode switch and delay before the error is shown, and vesa is very well established nowadays.

UI should offer the following options:

  • attempt automatic reconfiguration of video settings
    • can we do this first, and only prompt the user to accept/reject if the auto-config is different from their existing configuration? If yes, they should be prompted to restart in test mode, if no, continue in safe mode.
  • dpkg-reconfigure
  • if that produces a different configuration, allow the sure to test by logging them out and allowing the display manager to restart X
  • give up and use this mode: 'Use these video settings for your normal use'?
  • display diagnostics of what failed - for giving to technical support/showing their local 'computer expert.'

Because it is quite unclear if kdm have some equivalent of gdm's FailsafeXServer script, I say that it is not a good design choice to set safeMode1 by there. I think UpStart should have a startx event trying to start normally the X server. If X fail to start, then make the XServerFailed event start the safeScreenMode1 job. Later, when the session is started, it would be easy to ask Upstart if safeScreenMode1 job is active, and pop up a window to the user saying that X have not been able to start normally. It is unclear if Upstart is ready for this, but seems like a good test for it. Moreover, it is already one of the goal of [https://blueprints.launchpad.net/ubuntu/+spec/replacement-initscripts replacement-initscripts spec] to be controlled by Upstart ideally for feisty. --Paul Dufresne

I suggest to do like Windows, that is when xserver is reconfigure or configured, the first boot after that, ask the user if he/she should continue to use that video mode, or fallback on safeMode1. (The "Can you read this?" question on Windows) [ System/Preferences/ScreenResolution(translating) already does that, but the new twist is to do it on first boot after xserver-xorg (re)configuration] --Paul Dufresne

Implementation

[This section should show how the implementation is different than the design section]

Code

Data preservation and migration

Unresolved issues

Until [https://launchpad.net/ubuntu/+source/xorg/+bug/59618 bug #59618] patch is not released, then grub 'Safe mode' won't work. [done 2007-01-31]

From Forum topic [http://ubuntuforums.org/showthread.php?t=318142] ...sometimes logging out results in a black screen and a system freeze. None of the exit shortcut keys work, and I can't restart X.

I found a very reliable fix to this issue was changing the following line (line 96) in the /etc/gdm/gdm.conf file to this:

This forces GDM to restart X completely before returning to the login screen...

The [X-*-Core] section class of kdmrc have the option TerminateServer for this. (Paul Dufresne)

I propose to make this into the default configuration in Feisty Fawn.

I now think that previous problem should not be fixed by making AlwaysRestartServer true, but rather by using Upstart to monitor that resetting X server is completed within a reasonable delay (which should depend on the speed of the CPU), and failing to do so, should restart X instead. This would means that the server is broken, and a bug submission should ideally be made if that happens. But up to now, it would have to wait each time we log out, for the reasonable delay, making it worst than AlwaysRestartServer for that broken X server. So that a better design would emit a x-server-broken event with argument watchdog for this. On that event, a always-restart-server-watchdog upstart's job would be started, that would replace the algorithm of this to make the reset-x job to now over do a restart-x job, until the x-server be fixed and send a x-server-been-fixed event :-). Also, it would be good for the reset-x job to compare the memory space occupied from the X-server before and after the script, and emit a x-server-broken event with argument x-memory-leaks that would trigger always-restart-server-memoryleaks job, which would be identical to always-restart-server-watchdog, except offering to send a different bug report. --Paul Dufresne

Future work:

  • Fall back for thin clients
  • Kubuntu

BoF agenda and discussion


CategorySpec

BulletProofX (last edited 2008-08-06 16:35:43 by localhost)