Bug 6236

Summary: Non-existant error handling
Product: [Retired] Red Hat Linux Reporter: David Woodhouse <dwmw2>
Component: installerAssignee: Matt Wilson <msw>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6.1   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2000-09-19 23:01:43 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description David Woodhouse 1999-10-22 11:36:05 UTC
When the install script crashes, which happens quite
frequently, the error is not handled correctly, or indeed at
all. The python output is found on /dev/tty1, and the user
interface on the X server just locks up.

The python script ought to have a small wrapper which
invokes it, and then brings up a dialog box on the X server
with its output if/when it crashes.

Likewise, if the X server fails to start, the machine just
dies. It ought to be fairly simple to detect this situation
and fall back to the text-based installation instead.
Forcing the user to reboot with the 'text' option is
unnecessary. In fact, the 'experttext' option isn't listed
in the SYSLINUX startup screens, and I only found it by
trial and error.

The X server approach is surprising. For reliability, the
installer probably ought to use the framebuffer directly, as
there are too many things that can go wrong with X. If it's
absolutely necessary to use X, in the absence of a version
of GDK which runs on a framebuffer target, then it ought to
use XF86_FBDev, and a kernel framebuffer device.

By setting the kernel to use a vesafb device, but to
silently default to a text mode if VESA 2.0 isn't present,
you could have a fairly simple auto-detect of graphics
capability, falling back cleanly to the text mode when
appropriate.

However, as VESA 2.0 isn't as common as one might hope,
perhaps it's best to use the vga16fb kernel driver instead
(or as well) of the vesafb. Either way, the handling of
various text/graphic modes could be better thought out than
it is at the moment.

Comment 1 Jay Turner 1999-10-22 15:40:59 UTC
This issue has been assigned to a developer for further action.

Comment 2 Michael Fulbright 2000-09-19 23:01:40 UTC
Fixed in Pinstripe beta release.