Bug 246158

It seems with CLI you mean command line interface.

Such a fallback has been discussed often in the past. I'll attach an email by Egbert with a proposal.

Yes, that's what I meant. BTW, one does not even have to mess up xorg.conf, but e.g. buy a new graphics-card or update the kernel without having the binary driver's update-source in YaST.

Although there are some graphical-installers for binary-drivers, e.g. the Ati one, it is of no use, if there is no X running. So if X would at least come up in 640x480 after a kernel-update, the user could start the graphical-installer to install the driver.

Although it never happened to me, some people claimed that some online-update broke their xorg.conf, which would be a lot less severe, if the user would get a working X anyway in order to use a non-cli editor to have a look at the config-files or logs.

*** Bug 254051 has been marked as a duplicate of this bug. ***

Ok, what is my proposal.

First (simple):

1) add /etc/X11/xorg.conf.default with default failsafe configuration.
2) add some code to startx (or x, I don't know exactly) script, which will check if Xorg started (for example, with tail /var/log/Xorg.0.log | grep "no screens found") and, if not, starts X with /etc/X11/xorg.conf.default automatically.

Second (not so simple):

Write down a new application, which will catch when the Xorg fails, and ask user about 2 things: 1. Start GUI with failsafe mode (still /ect/X11/xorg.conf.default) or 2. Start GUI with last known good config (which will create automatically somewhere when Xorg starts normally).

Any progress on this issue? Does the "Failsafe" grub-entry use a failsafe xorg.conf which enables the user to use X?

No.

Would it be possible to have Failsafe from the boot-menu use a failsafe xorg.conf then?, as a minimal implementation.

Could you please attach the email mentioned in comment #2?

(In reply to comment #9)
> Could you please attach the email mentioned in comment #2?
No. This is only for internal discussion. 

Sorry if this sounds rude, but if there is no progress within 4 months and apparently not result either, what kind of discussion is going on internally? 

Where did it get stuck? Whether this is neccessary or not, or which way to go?

To the user it is not really important how this works, just that there is a working X no matter whether the issue was caused by changing the graphics-board, some online-update or a self-compiled kernel-module. I know that people, including me, do not like the argument, but Windows has been able to handle this issue for years and it really should not take another 8 months to get this into opensuse.

This is not a bug report but a feature request. More than a single component is involved, it is difficult to make this fail-safe, there are more pressing issues, and all developers are pretty much working on real bug reports right now.

That's why you don't see any progress here.

This is indeed a feature request and we should treat it as such. 
A generic failsave config file which uses fbdev and whatever vesa mode is set should be easy to provide and satisfy the vast majority of users - in fact all those who use a fbdev mode instead of vga console (thus all ia64 users would be excluded).
As a minimal first step this config could be shipped and a script could be provided that allowed the user to switch between this file and the original version.
This would require the user to briefly log in on the text console and run the script.
An automated setup which will switch to a failsave config file would most likely involve modifications to 3 different display managers.
The most obvious solution would be to select another line in the /etc/X11/xdm/Xservers file (along the lines of what kdm already does to support multiple concurrent sessions).
startx is not the preferred method of starting X any more. Thus hacking this script would only satisfy a small subset of users.

Well, we could use /etc/X11/xorg.conf.install for failsafe. This is the one, which has also been used for installation and is therefore supposed to work.

There's already a failsafe entry generated for grub. But this one explicitely disables framebuffer, so changing this behaviour would be fundamental.

Grepping for an extra grub "x11failsafe" option in /proc/cmdline  and copying /etc/X11/xorg.conf.install to /etc/X11/xorg.conf-4 in /etc/init.d/xdm
shouldn't be that hard. Of course /etc/X11/xorg.conf-4 should be removed if this option is *not* set.

> This would require the user to briefly log in on the text console and run the
script.

Red Hat have a feature that automatically starts a config utility if Xorg fails. I think we don't need to ask user to start this script, too.

How do you define "Xorg fails"? How do you want to detect a black screen? The easiest and IMHO most reliable solution would be to provide a failsafe boot option, which usese the X driver, which has been used for installation as well. In most cases this will be the fbdev driver.

I agree with comment #16. As long as the average user will be capable to browse around the internet for a proper solution, such fallback is fine. w3m would be a hard browser to use for problem solution.

Strategically why not having a "whitelist" type of X11 drivers table? Left column: chip type, right column default driver, where sax2 without "-m" switch would look first. The latest version of this table could be put into GM after RC and we would spare more users from sax2 type user unfriendly stuff. It should also be part of online update then.

Proposal
--------

--- xdm.orig    2007-12-28 16:01:48.000000000 +0100
+++ xdm 2007-12-28 17:08:19.000000000 +0100
@@ -140,6 +140,22 @@
                 "$DISPLAYMANAGER_STARTS_XSERVER" = "no" ]; then
                XDMOPTIONS="--no-console"
        fi
+       # Graphical failsafe mode (Bug #246158).
+       #
+       # Needs changes in kernel commandline of "Failsafe" entry in
+       # /boot/grub/menu.lst.
+       #
+       #  * use the same "vga" option value as in the non-"Failsafe" entry
+       #  * remove "3" option (runlevel)
+       #  * add "x11failsafe" option
+       if cat /proc/cmdline | grep -q x11failsafe; then
+            if [ -f /etc/X11/xorg.conf.install ]; then
+               export XORGCONFIG=xorg.conf.install
+            else
+                rc_status -u
+                rc_exit
+            fi
+       fi
        startproc -p $PIDFILE $DISPLAYMANAGER $XDMOPTIONS || rc_failed
        # After a crash or a kill signal we may have
        # a wrong owner ship of /dev/xconsole

Created attachment 188872 [details]
xdm.diff

Patch again as attachment.

> # Needs changes in kernel commandline of "Failsafe" entry in
> # /boot/grub/menu.lst.
> #
> #  * use the same "vga" option value as in the non-"Failsafe" entry
> #  * remove "3" option (runlevel)
> #  * add "x11failsafe" option

Coolo, this would require changes in our bootloader and our failsafe mode
will change to a grahical one. Not sure if this would be appreciated. Please comment.

I am not certain what the fallback driver choice is, but i would like to take one driver out of the equation.

VGA is the most horrible fallback you can name. Compatibility is a lie, nothing less. The only way to reliably use VGA is to not touch the mode at all.

All one should do is find out the current mode (usually 640x400 - 80x25) alter the way the framebuffer is used (from text to graphics), and not touch anything else.

Change the mode, and you risk not setting up the mode fully and correctly for all active heads and all active outputs. While on radeonhd a modechange will be emulated fully and correctly, devices like the unichrome will mess up rather horribly.

Whenever i have time, i should alter the vga driver (generic.c) to work as described, unless it gets fed a special option to allow all modes possible with 256kB. 

Using the installation Xserver is probably the very best solution. If that one failed, the user wouldn't have been able to install at all. If the user is proficient enough to install in text mode, he is able to boot into runlevel 3 all by himself as well.

As long as we do not remove the ability to add boot options (again).
Any automatism is critical here. Maybe one could grep the log for segfaults or some error lines - but also then nobody will tell you whether the driver has already borked up the display and fbdev will work, or not.

Luc, since the vga driver is never used for installation, we don't consider to use it as fallback driver. The drivers used for installation are either

- fbdev (in most cases)
- vesa (only in some rare cases)
- the native driver (only on IA64 - due to missing VBIOS IIRC)

Matthias, thanks for the supportive comment.

I guess that's a good change. For the bootloader change, you need to create a new bug for yast2-bootloader.

(In reply to comment #24 from Stephan Kulow)
> I guess that's a good change. 
Thanks.

> For the bootloader change, you need to create a new bug for yast2-bootloader.
done (Bug #352020). It's marked as enhancement. Jozef, any chance to get this implemented still for openSUSE 11.0?
 

(In reply to comment #25 from Stefan Dirsch)
> > For the bootloader change, you need to create a new bug for
> > yast2-bootloader.
> done (Bug #352020). It's marked as enhancement. Jozef, any chance to get
> this implemented still for openSUSE 11.0?

I attached a patch proposal to Bug #352020.

Jozef, could you comment?

The patch attached to bug #352020 sounds OK, but how are we going to handle problems with framebuffer? Wouldn't it be better to set framebuffer to a safe mode instead of the standard one?

I'm not the expert there. 

Well, what do you think which mode would be safe here? 640x480@16bpp? In this mode many X applications (like YaST2/SaX2) won't show their Ok button any more, though are becoming useless in failsafe mode.

I assume the installation fbdev mode *is* safe. Otherwise the graphical installation would not have been possible at all. Makes sense?

The installation xserver configuration is the safest thing we can ever come to. If it doesn't work, we do have other more prominent problems that this little thing.

OK, agreed.

Jozef, I think you can apply the suggested patch.

Jozef? I think that Jiri set NEEDINFO to you, because he wanted here from you if you agree as well and plan to integrate the patch to yast2-bootloader.

Stefan, Jiri is my teamleader. If he agrees I have to do it. ;-)

I agree too and I will ask you about details via IRC or mails.

Sounds good. :-)

I've added the patch of comment #19 now to xdm init script.

This feature should be in place now since openSUSE 11.0 Alpha 2. Anybody, who verfified that it works as expected?

This feature does not work since the failsafe contains again "vga=normal" and "3" and is missing "x11failsafe". :-( I need to reopen Bug #352020.

reopen this one as well.

The issue has been fixed now in perl-Bootloader - yast2-bootloader was the wrong package with dead code I patched. I keep this bugreport open until I tested it with Beta2.

Finally this feature works - with openSUSE 11.0 Beta2.

*** Bug 407735 has been marked as a duplicate of this bug. ***