Bug 233407

Summary:	Badblocks check is not working on kick start installation
Product:	Red Hat Enterprise Linux 4	Reporter:	Balaji.S <balajisundar>
Component:	anaconda	Assignee:	Anaconda Maintenance Team <anaconda-maint-list>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	urgent	Docs Contact:
Priority:	medium
Version:	4.3	CC:	mharris
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2007-03-23 19:07:14 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:

Description Balaji.S 2007-03-22 06:44:48 UTC

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 19:07:14 UTC

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 12:50:28 UTC

(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 12:53:47 UTC

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.)