Bug 81727 - checking for bad blocks doesnt give option to continue installation
checking for bad blocks doesnt give option to continue installation
Status: CLOSED WONTFIX
Product: Red Hat Public Beta
Classification: Retired
Component: anaconda (Show other bugs)
phoebe
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Michael Fulbright
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-01-13 10:23 EST by Paul Pianta
Modified: 2007-04-18 12:49 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-01-29 17:06:56 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Paul Pianta 2003-01-13 10:23:03 EST
Description of problem:
when creating partitions and checking for bad blocks - if bad blocks are found
then clicking "ok" is the only option and the installation quits. I haven't
tested with other redhat installations (yet) but according to the earlier
installation manuals it looks like the badblocks program should be called and
any badblocks are skipped and never written to. I assume with earlier versions
that you could continue an installation even if bad blocks were detected.

Version-Release number of selected component (if applicable):
8.1 beta (phoebe)

How reproducible:
everytime

Steps to Reproduce:
1. have a disk with bad blocks
2. try to install ext3 on a partition that contains bad blocks and check the
"check for bad blocks" option
3. during the actual checking for bad blocks a dialog will display saying "bad
blocks were found! we do not recommend that you install on this disk" and the
only option is to click "ok" - which reboots the system and you are back to
square 1.
    
Actual results:
i click ok and i am trapped in a vicious circle of checking and failing and
clicking ok!

Expected results:
when bad blocks are found - the badblocks tool is used to add the bad blocks to
the bad blocks list and these blocks are tagged to never be used again - but the
installation continues on the rest of the disk that is good.

Additional info:
Comment 1 Michael Fulbright 2003-01-13 15:05:39 EST
In early versions badblocks was run and then ignored when creating filesystems.

We changed the behavior so at least you would not continue as before with a bad
drive.

I do not think we're going to add code to support formatting drives with bad
sectors.
Comment 2 Paul Pianta 2003-01-15 15:36:23 EST
but dont you think it would be a good idea to give the user the option of
whether or not they want to continue the installation. Give some very serious
warning about the chance of data being lost etc. but have a button for "continue
anyway". if the user chooses to continue - run badblocks like in previous
versions of redhat linux and allow the installation to continue (with the
badblocks now being hidden).

not sure if this interests redhat or not but i didnt realise that i had
badblocks on my disk until i tried to install phoebe. As i couldnt continue with
the installation it left me with limited choices - 
1. buy a new disk (which i cant afford, and if many people are installing on old
hardware then they dont want to buy new disks either) 
2. reinstall a previous version of redhat linux that will install on a disk with
badblocks anyway

anyway - i reinstalled redhat linux 8.0 right after my phoebe install failed and
i have no problems with corrupted data - even though i know now my disk has bad
blocks. even though i am aware of my dodgy disk - i am prepared to take the risk
and have the installation complete - at least the option to continue would be nice.
Comment 3 Jeremy Katz 2003-01-29 17:06:56 EST
The option to continue will just lead to people filing bug reports with random
crashes and the like and they may or may not remember saying "go ahead and
install on my dodgy disk".

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