This really is not an option - it can definately lead to a system with lurking
disasters waiting to happen.

Bad media just happens :(

Lots of present options also can lead to messed up systems -- the 'proceed
without satisfying dependencies' options during resolution phase in TUI and GUI
installs; the decision NOT to make a recovery floppy; ... I mentioned this on
testers list but had not appended it in here ...

PLEASE reconsider ... there is just NO good recovery option available for a 
failure mid-upgrade as things are now with media discovered to be defective 
mid-process:

Date: Thu, 12 Jul 2001 00:10:07 -0400 (EDT)
From: R P Herrold <herrold@owlriver.com>
Cc: Red Hat Beta Team <testers-list@redhat.com>
Subject: [testers] My first beta install failed

David L. Gehrt wrote

> The pause while awaiting the "running anaconda" seem excessively wrong
>       not to have a progress indicator.
> XFree86-libs-4.0.3 failed due to missing file,bad package..." hit return
>       and it succeeded
> XFree86-100dpi-fonts-4.0.3 failed due to missing file,bad package..." hit
>       return twice and it succeeded

See: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=30029

which was closed 'WONT"  from the last test cycle -- Also on
well -used 7.1 'official' CD's today, I got a media error.
the ONLY options is 'retry' -- there just HAS to be a 'skip'
option to get PAST defective media.

> These last two comments SOUND like the CD problems I am reading about as
> I catch up on my testers-list email.  The first CD booted OK, but then
> these two transient CD reading  problems were not particularly serious.

but thre is no graceful recovery option to allow getting PAST
this in a 3/4 complete upgrade or install situation ...

I'll reopen 30029 and post this in that Bugzilla

-- Russ

I'm not sure what type of graceful recovery is possible when you have errors
mid-way through an install/upgrade.

I'm guessing you mean there should be a button to push to shutdown the machine
cleanly?

Well, yes, but why not make it more useful?
 
Undestand that, particularly in the case of an upgrade, a partial
update, and also a non-graceful shutdown is very painful to recover
from ... almost without exception (glibc package failure), it is
better to limp through to the end, and then audit with rpm -Va and
patch.

Suggestions:
====================

1.   Offer to SKIP the unreadible package, and dump a note in the
install/upgrade log -- This alerts the sysadm that there was a problem, which
may need manual intervention.

2.   At a minimum, in the case of INSTALLS only, offer a shutdown which properly
umounts the (then currrently mounted) installation partitions.  At this point,
sometimes, an ''upgrade'' can be used to 'complete the install.  AGAIN, log the
fact to the install/upgrade log -- so that one can do a port-mortem and figure
out what went wrong.

[This actually provokes an idea on my part -- Why not 'tee' in all instances
anaconda tracebacks, in the case of install failures, into
/tmp/anaconda-traceback.txt, and/or the install/upgrade log, so that beta
testers, and indeed customers finding errors, can give better reports, even if a
proper floppy, with proper vfat modules, is not at hand. -- will RFE separately]

I think Suggestion #1 is a bad idea, because we don't have a way of knowing the
importance of a given package at that time.  What if that package is the kernel
or glibc?  If you skip that package, the system is hosed, and you've wasted your
time with the rest of the install.  I mean, knowing that the install media has
some corruptions and wanting to go on with the install anyway seems pretty crazy
to me.

We get a fair number of requests for this, and I don't really understand why
it's such a big deal.  It's *much* easier to verify that your install media is
good before you start the install than it is to catch the countless number of
ways the installer can fail on bad media.  If the user wants to go through the
trouble of downloading and burning their own cd, then I think they bear some
responsibility to make sure the download is good before they start the install.
 If there are defects with the retail cd's, the right thing to do is to take it
back to the store and exchange it, not go on installing with bad media.

Re-opened after 7.2 release (taking out of Deferred state)
============================
The point is being missed:  

I had this occur in an ISP environment doing an upgrade; the upgrade, from 
Official RH CD's failed half way through an UC -- GLIBC had overwritten the 
prior version, but the new keneeernel (required by that glibc) was not yet in 
place.  The ypbind which was aprt of the BASE in the upgrade was destined to 
be removed just as soon as the install was complete.

Sure -- I can envision failure modes which are not recoverable -- but if any 
but about 5 or 6 packages fail, it is not fatal, just possibly uncomfortable --

Why increase teh pain by omitting a Skip. or even a graceful shutdown;

Isn't the pain of a powerswitch shutdown much more thn a possibly missing 
package dependency?

Just got bitten again on my personal workstation with an AIC-7xxx and SCSI CD
drive combo  -- with CD's which work consistently on IDE drives.

It's not the hardware; it's not the disks; it is SCSI controller resets this
time--

and because there is no graceful umount option, or skip option, I'm screwed.

If the MBR changes had happened, but 'not enough' to be able to get booted with
a new kernel, I'd REALLY be in hot water.

This (error recovery) _is_ a big deal, if one wants to be taken seriously in a
marketplace.  The Adaptec SCSI driver issues are most likely not going away.

Uggh ... actually, as it turned out, in trying to go from RH 7.1 to RH 7.2 and
choosing to convert to ext3, it editt4ed teh fstab and send to a
LABEL=/mountpoint change in the partition information on the HD in question.

Also, it changed the fs type to ext3 and committed the change to the /etc/fstab

and the remaining RH 7.1 kernel, NOT having been updated yet, was unable to
mount ext3 FS type ...  Took about 45 minutes to recover it.

(attchment in a second)

Created attachment 37663 [details]
snapshot of fstab and fdisk as alluded to ...

Deferred to future release.

Honest, I had nothing to do with this -- this guy is in the local LUG

=============================================================

Date: Fri, 10 May 2002 14:03:50 -0400 (EDT)
From: Scott Merrill <skippy@skippy.net>
Reply-To: colug@colug.net
To: colug@colug.net
Subject: [COLUG] RH 7.3 installation

I upgraded a 7.2 system, and elected to add a few extra packages.  Since I
only used the first two CDs for my 7.2 installation, I foolishly assumed I
could get by with just the first two discs from 7.3.
What a mistake that was.

I ended up rebooting since the installer did not provide a convenient way
to stop, and my CD burner was in the system I was upgrading!  Thankfully
the system rebooted successfully, and everything appears to be in order
(sans those packages from disc 3).

Who would I talk to in order to suggest that the Red Hat installer
indicate which CD a particular package is on?  Barring that, I'd like to
suggest a way to cleanly abort the request for the next CD, if possible.

_______________________________________________
colug mailing list
colug@colug.net

=========================

Re-opening for the next cycle.

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

new datapoint FYI -- Upgrade scenario: with post-limbo (Psyche boxed set image)
CD's passing mediachacek, disk 2 on current production IDE based Dell hardware
came up not reading.

I infer the read pattern of mediacheck is sustained and linear; the read pattern
of an install is sporadic with spindowns and random media location seeks, and by
definition cannot be fully tested with all the possible custom install
combinations; Upgrades would be even MORE random.

and so another piece of media needed to be pulled and burned on a different
burner (which worked, the host being offline for several hours during the process)

A clean umount 'Abandon' option alone for a graceful shutdown when errors are
detected (if not both the Skip and Abandon) sure makes sense.

*** This bug has been marked as a duplicate of 68376 ***

Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.