From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5)
Description of problem:
DO HOMEWORK: Buy distribution CDs. Test CDs at office. Goto customer.
INSTALL: End of disk 4 fails. Install aborted, no obvious way to fix.
RESULT: Major embarrasment. Hours wasted. Me & Fedora get bad rap.
FIX: Have installation do essentials at first. Leave info&fix about
half-way installation in rc.local! Do the rest, if successful, redo
rc.local to final. Anything optional should be installed only after
_all_ obligatories. !!
MOTIVATION: border-line CDs, unstable network connections, etc. can
cause installation to fail, even near end. Result: frustration and
shame -- bad-will.
(MICROSOFT-STYLE: do it all, or redo it all. LINUX-STYLE: no obstacle
is show-stopper -- continue automatically where last failed.)
TRIED: Re-install. No avail. "MBR not rewritten: no changes needed."
Have to redo it all. Takes unreasonable time unless client got a
screamer. Not all do. Not even in America. Customer can have 100
more machines -- "Can't do here, can't do overall, sorry: Get OUT!"
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Take border-line distro. Check distro on non-installation drive.
2. Need "bad luck".
3. Choose partition instead of mbr for grub.
Actual Results: No boot. No improvement with Upgrade option. (See above.)
Expected Results: Reinstall should check more thoroughly if an
aborted install exists.
1. Check if current/older runnable system found. 2. Check if half-
way current version installed. 3. Check bootability. 4. Check which
RPMs installed. 5. Check which left uninstalled. 6. Offer (_BY
DEFAULT_) 1. to fix boot, 2. to reinstall missing RPMs.
1000 reasons for aborted install. (Bad distros, static on net,
electric outage, bad karma enters, kid presses Eject, wife/boss
assaults room.) No reason ever should force to redo everything.
Linux Rescue Choice should automatically start by checking if HD is
bootable, is there a sane linux there -- else offer to fix that.
Only _after_ that other "rescue" operations become relevant.
(Most installs are on home/SOHO grade IDE regular PCs. Take care
of them. The hairy configurations are maintained by Gurus anyhow,
and most of them use RH anyway, not Fedora.)
Designers of Install Disks (actually their Bosses) should consider
each Total Reinstall made by customer (whether savvy or newbie)
-- a total shame and loss.
Total Reinstall should Never Happen. That is a Microsoft thing.
Please, consider for a moment the background and context of the
above -- what it means to the Fedora project, and to the
Fedora installers are inferior to RH customers, we all know.
They, however, are the ones who carry the word. Also they are
the future prospects to RH, and thus should be taken care of.
The media, the connections, you cant't -- and shouldn't -- try
to rectify. But the installation procedure can be enhanced with
minor effort, so that the end result makes a huge difference.
ADDED LATER: actually CD-check should make a note of which RPMs are
bad. These would be non-available during package selection.
MOTIVATION: when you install from CDs, you're out of Internet, often
in the bushes. You can't afford to skip the whole thing just because
_something_ is bad.
COROLLARY: Any failure during RPM install should offer to eject and
reinsert CD. Also to skip package in question. (And take care of
HINT: flexibility, resilience, utility.
The dependency graph of all the applications in the distribution
should be precompiled. If the install UI loads this graph, then it
is a matter of microseconds to sort out what "non-chosen" RPMs have
to be installed too!
Currently it takes quite a while before installation begins. This is
especially bad if the user has chosen "everything".
HOW THIS RELATES TO THIS BUG REPORT: With the dependency graph, the
install software could instantly know what choices become unavailable
if a particular RPM is unreadable.
Also, (of course the install does the dependees first, right?) then
if an RPM fails install, then those depending on it could be just
skipped, and the user would be informed on them, and given a choice
to (retry, go on without the skipped ones, or even go back to choosing
packages. ((This sounds like too much choice, but if you are in
the bushes at the customer, then you probably just have this set of
CDs. Something missing may lead to a total rethink of the particular
install's purpose (e.g. some other RPMs becoming useless too for the
intended purpose of the computer, etc.). Most often time is limited,
choices are interdependent and so on. Hard disk space, and even the
time spent on the install, may be at a premium.))
Phew, well that was a lot to take in. Looking at this I have the following comments:
There was nothing stopping your from selecting a minimal install (enough to get
GNOME?) then adding anything else afterwards. That way if something went wrong
you would have not wasted so much time and if something is wrong on a later CD
not initially used you still have a working system.
From a programmer perspective, recovering "half done" things is an absolute
nightmare. It's hard enough taking one thing from a known state to another known
state (versus starting from scratch) compared to trying to trying to patch up a
half installed glibc so that it won't interfere with what you are going to add
later. I'm not saying it's impossible - I'm just saying the programming time of
trying to recover from every possible problem compared to forcing people to go
from scratch is vast in comparison to the number of people who would actually
make use of such a thing (most people just give up if *anything* goes wrong).
Thirdly, doing coporate roll outs of stock Fedora sounds inherently risky. What
about that 1Gbyte+ of updates that fix a number of problems? Too much has
changed/been fixed to not apply them. Were these CDs with a rebuilt anaconda
with the updates on them? Obviously you may have had a plan to deal with that
and just not mentioned it.
Corralating bad sectors on a CD to files while not too difficult seems again a
lot of work for little benefit. I guess I'm saying it's a false economy - you
are better off chucking the CD and getting a new one. For all you know the
damage may continue to detoriate, plus you start needing writeable media to
store which bits were bad and more code to recover when something that HAD to be
installed was bad... Not easy.
If you technical enough you can always force grub to install to a partition from
teh rescue CD by dropping to a prompt and entering the necessary commands by
hand. Of course if you are capable of doing that you are probably capable of
patching up any other mess waiting for you due to the installer failing to
Lastly, sticking grub on partitions is a non default thing to do. It's there to
allow you to use other boot loaders but each time you take a step away from the
defaults you increase the risk of bumping into problems. I haven't seen any case
where it was better to put grub on the partition rather than the MBR other than
personal preference ("I want to use the Windows boot menu") but that doesn't
mean the option shouldn't be there.
I think what you have here are many points of discussion rather than a single
bug (if you had only said something like "Rescue CD should be able to repair
half installed distro" and absolutely nothing else then I suspect you would have
made a better "bug report"). I think you are better off discussing this on
something like fedora-list (http://www.redhat.com/mailman/listinfo/fedora-list )
rather than trying to cram it into bugzilla.
Alternatively if what you were saying was:
"I have a bunch of tested patches to Anaconda implementing this" then please
disgard this entire comment.
I presented real world scenarios, and a recipe to fix them.
Sorry for wasting your time. And mine.
Was just my $.02 anyway.
No need to fix anything, just forget this thread.
Hey, I never said you were wasting my time (I'm not a Fedora developer, I don't
develop Anaconda). I just thought you had posted your ideas to the wrong forum
(ideas for _discussion_ shouldn't be in bugzilla they should be on a mailing
list) and was genuinely unclear as to whether you had already written code to do
all this stuff (I'm not psychic! How do I know unless you say?). You had some
ideas, I had some comments but that's not to say that someone else wouldn't have
said something different on a more open forum. I'm sorry you reacted so
negatively, I was trying to ascertain what you had done and point you in the
right direction so your time *wasn't* wasted.
I thought you were the FC engineer responsible for doing something,
just trying to weasel his way out of chores!
Probably was the first phrase "Phew, well that was a lot to take in."
No hard feelings!
As to the issue, all I think is needed is, a couple of lines more in
the makefile that gets run each time a distro is "finalised", a short
Perl script that gets run from it: building the depencency tree, and
finally some minor tweaking in (Anaconda? anyway the) UI handler.
Sitsofe thank you for your well phrased reasoning.
1) This is NOT EasyFix! In fact what you are asking for is not even remotely
2) "From a programmer perspective, recovering "half done" things is an absolute
You certainly don't expect to be able to recover from a half-installation due to
a bad Windows XP or Solaris CD. Why should Fedora be any different?
3) "I just thought you had posted your ideas to the wrong forum"
Bugzilla is NOT the place for this. This belongs on a mailing list, but you
will be ignored or flamed there (with a few crazy people agreeing with you).