This service will be undergoing maintenance at 20:00 UTC, 2017-04-03. It is expected to last about 30 minutes
Bug 6236 - Non-existant error handling
Non-existant error handling
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: installer (Show other bugs)
6.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Matt Wilson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-10-22 07:36 EDT by David Woodhouse
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-09-19 19:01:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Woodhouse 1999-10-22 07:36:05 EDT
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 11:40:59 EDT
This issue has been assigned to a developer for further action.
Comment 2 Michael Fulbright 2000-09-19 19:01:40 EDT
Fixed in Pinstripe beta release.

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