Bug 102711
| Summary: | installation fails due to bad blocks found, but it is an apparently incorrect finding | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Dennis Calhoun <dcalhoun> |
| Component: | anaconda | Assignee: | Michael Fulbright <msf> |
| Status: | CLOSED RAWHIDE | QA Contact: | Mike McLean <mikem> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 9 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2003-08-22 19:25:56 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Not to trivialize your experience, as I can tell it was frustrating, but we've removed the bad blocks option from future releases. It has been our experience it causes many more problems than it solves, and modern hard drives do some bad block detection of their own when you format the drive. |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Description of problem: My first installation of Red Hat Linux 9 (RHL9) SEEMED to go ok, but, being a complete green horn at it, I had not set it to "check for bad blocks" before formatting the partitions I'd established. I later found that OpenOffice.org would not run right, not at all. It barely gave me more than the frame of a window that X windows opened for it to run in. Further investigation and discussion in an openoffice mailing list drew my suspicions to the posibility of a failing hard drive.... bad blocks. Upon my second attenpt at installing RHL9 I DID set it to check for bad blocks before formatting the partitions. It reported that it had found some and recommended that I not use that drive. This is just a 2 year old Dell with a Maxtor 40GB drive that has been running Windows ME just fine, so I began trying to be SURE of the condition of the drive. Eventually I learned about running the command "badblocks" at the shell promt. I booted from the CD, mounted NO partitions, ran "badblocks" on the root partition and when it had finished it made NO report of any bad blokcs having been found. I tried Anaconda again and then the badblocks command again, just as before. All in all I did these things 3 to 5 times each and NEVER got any report of bad blocks having been found by the running of "badblocks" command, but 3 of 5 times Anaconda DID terminate installation because it SAID it found bad blocks. Since then I decided to ignore Anaconda's bad blocks report and run the installation without that check. I SEEM to now have a solid installation. It seems relatively obvious to me that there is a problem of some sort with Anaconda. I've heard that it something in the kernel of Anaconda and that this has been reported a number of times since version 7.2, but I don't see any bugzilla reports that seem to relate to it at this time. Version-Release number of selected component (if applicable): How reproducible: Sometimes Steps to Reproduce: 1. run anaconda installer in graphical mode 2. set it to "check for bad blocks" 3. set back and wait to see if it kicks about bad blocks when it finishes Actual Results: 3 of 5 times, anaconda reported having found bad blocks in the root partition. 0 of 3 or 4 times, the "badblocks" command, ran from the shell prompt in Linux Rescue mode (booted from the CD and with no partitions mounted) found NO bad blocks. Expected Results: If it DID find bad blocks, TELL me sometihng useful, like how many, which ones, where, something I can use. Maybe even recommend that I buy something like Spinrite to REALLY evaluate my drive. Additional info: This bug is a particularly painful one for those of us that are COMPLETELY new to Linux.