Bug 233407 - Badblocks check is not working on kick start installation
Badblocks check is not working on kick start installation
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: anaconda (Show other bugs)
4.3
All Linux
medium Severity urgent
: ---
: ---
Assigned To: Anaconda Maintenance Team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-03-22 02:44 EDT by Balaji.S
Modified: 2009-12-06 07:53 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-03-23 15:07:14 EDT
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 Balaji.S 2007-03-22 02:44:48 EDT
Description of problem:

  In Redhat 7.2 kick start installation,badblocks check for HDD is working
  on creating partition.

  But in RHEL4 Update 3 badblocks check is not working on kick start installation.

   Badblocks check command in kickstart file

   part / --fstype ext3 --badblocks --size 1000
   part /home --fstype ext3 --badblocks --size 12000
   part /usr --fstype ext3 --badblocks --size 9000
   part  swap --size 1000
   part /backup --fstype ext3 --badblocks --size 12000 --grow


   Please send me a solution for badblocks check command for RHEL4 Update 3
linux and please help me. 


Version-Release number of selected component (if applicable):
Red Hat Enterprise Linux ES release 4 (Nahant Update 3)

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Jeremy Katz 2007-03-23 15:07:14 EDT
badblocks is no longer supported; often, it actually does nothing at all given
that drives remap blocks underneath the OS without telling you 
Comment 2 Mike A. Harris 2009-12-06 07:50:28 EST
(In reply to comment #1)
> badblocks is no longer supported; often, it actually does nothing at all given
> that drives remap blocks underneath the OS without telling you   

If the drive is in a state where there are no OS visible bad blocks, that may be correct.  However if the number of bad blocks a drive has sustained is larger than the extra blocks available for remapping, then bad blocks start to show up visibly to the OS, and the badblocks command should find them.  Removing the option gives nobody a way to test for bad blocks except by manually testing the drive separately, or booting up a separate tool just to test for bad blocks.

Perhaps a better solution for the future, would be to integrate smartctl/smartmonutils into anaconda and have it check the smart status of any disks that you've told it to touch prior to doing anything with the disks.  That would theoretically not only prevent installation to disks with bad blocks, but it would also prevent installation to disks that have any other failure modes.

I have to admit that while I just thought of this idea, I did not do my homework to see if anaconda already has such a feature.  ;o)  If not, I'll file a RFE for smartctl/smartmonutils integration into anaconda if someone thinks it worthwhile.
Comment 3 Mike A. Harris 2009-12-06 07:53:47 EST
I should add that if SMART integration gets added to anaconda, the user should still be given the final decision as to whether or not to enable it or not and/or the ability to allow installation to proceed anyway even if a drive has bad SMART status.  (Bad hard disks can still be useful to some people even if they have bad blocks, in particular for completely unimportant temporary data storage of things that are easily replaceable.  Not enterprise-worthy, but Fedora and EL are used in all sorts of situations including hobby/etc.)

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