|Summary:||Change order of installation details !!|
|Product:||[Fedora] Fedora||Reporter:||Georg Wrede <rh-fedora-bugzilla-georg>|
|Component:||anaconda||Assignee:||Anaconda Maintenance Team <anaconda-maint-list>|
|Status:||CLOSED WONTFIX||QA Contact:||Mike McLean <mikem>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2005-03-29 09:09:13 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Georg Wrede 2005-02-24 00:35:29 UTC
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 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): FC-3 How reproducible: Always 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. Additional info: 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.
Comment 1 Georg Wrede 2005-02-24 00:53:38 UTC
Please, consider for a moment the background and context of the above -- what it means to the Fedora project, and to the customers. 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.
Comment 2 Georg Wrede 2005-02-24 22:53:26 UTC
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 dependencies.) HINT: flexibility, resilience, utility.
Comment 3 Georg Wrede 2005-02-26 16:16:27 UTC
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.))
Comment 4 Sitsofe Wheeler 2005-02-27 12:50:42 UTC
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 finish properly... 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.
Comment 5 Georg Wrede 2005-02-27 13:37:46 UTC
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.
Comment 6 Sitsofe Wheeler 2005-02-27 18:55:45 UTC
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.
Comment 7 Georg Wrede 2005-02-27 22:40:43 UTC
My mistake. 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.
Comment 8 Warren Togami 2005-03-29 09:09:13 UTC
Sitsofe thank you for your well phrased reasoning. 1) This is NOT EasyFix! In fact what you are asking for is not even remotely feasible. 2) "From a programmer perspective, recovering "half done" things is an absolute nightmare." 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).