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:
badblocks is no longer supported; often, it actually does nothing at all given that drives remap blocks underneath the OS without telling you
(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.
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.)