Bug 6236 - Non-existant error handling
Summary: Non-existant error handling
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: installer
Version: 6.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Matt Wilson
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 1999-10-22 11:36 UTC by David Woodhouse
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2000-09-19 23:01:43 UTC

Attachments (Terms of Use)

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

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.

Note You need to log in before you can comment on or make changes to this bug.