Bug 63449 - anaconda blows up after two CDs
Summary: anaconda blows up after two CDs
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anaconda   
(Show other bugs)
Version: 7.3
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Michael Fulbright
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2002-04-14 04:24 UTC by Michal Jaegermann
Modified: 2007-04-18 16:41 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-04-15 18:18:49 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Michal Jaegermann 2002-04-14 04:24:07 UTC
Description of Problem:

During an installation from scratch anaconda blows up suddenly
after finishing two disks.

The only trace I have from that is the following from syslog:
<4>hdc: tray open
<4>end_request: I/O error, dev 16:00 (hdc), sector 1300864

If you cannot be bothered to write backtrace to logs then I cannot
be bothered with paying attention to these.  Floppies written
by anaconda are unreadable.

Comment 1 Jeremy Katz 2002-04-14 06:03:13 UTC
Do the cds pass the media check?

Comment 2 Michal Jaegermann 2002-04-15 05:38:04 UTC
Yes, they do.  Sorry, should have mentioned that immediately but error
logging and reporting in anaconda is driving me up the wall.  Yes, I realize
that this is not for everybody but keep in mind that for quite a big chunk
of time a disk on which one is installing is already available as a place
to save copies of logs and often are other options.  Floppies in the
context are _extremely_ frustrating and unreliable.  And do not even think
about propositions to copy Python backtraces from a screen by hand.

As a matter of fact the same CD set was already used previously to install
on another machine and I also used it to finish the whole installation
without any further problems or incidents but also without anaconda.
So I have now a test system roughly like it was originally intended
but I had to finish the whole process more or less manually.

Comment 3 Jeremy Katz 2002-04-15 15:58:48 UTC
That doesn't answer the question of if mediacheck was used on the machine in
question.  There's a lot of variance in CD-ROM drives on reading CDs and if they
don't pass the media check, I'm not putting money on being able to stream
packages off the CD for long enough to do an install.

As for saving tracebacks, it's entirely too late in the game to go about
changing things there, but adding more complication to that code is *not* an
ideal case.  This is last ditch code for if we run into problems.  Does it now
need to analyze the problem to decide if writing a traceback to a hard drive is
"safe"?  It's very similar to the whole problem of "what do you do when the
kernel crashes".  Sure it might be safe to write to the disk sometimes, but how
do you tell which times those are?

Comment 4 Michal Jaegermann 2002-04-15 18:18:43 UTC
> That doesn't answer the question of if mediacheck was used on the machine in
> question.

Yes, it was.  As well as further readings.  Which does not exclude a possiblity
of "temporary difficulties" for whatever reasons but even if so this is pretty
poor excuse for anaconda to blow up; especially that late in the whole
process after a significant expenditure of time on a part of an installing

Comment 5 Michael Fulbright 2002-04-15 18:59:45 UTC
We appreciate the time you have spent beta testing this codebase. However w/o
further information we cannot reproduce the issue.  We have not seen this
failure     in all of all install testing, which usually indicates a hardware
problem versus a programming error in the vast majority of the time.

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