Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

SCO Unix badtrk on IDE/SATA drives

Status
Not open for further replies.

Chwychomp

Technical User
Sep 13, 2007
2
US
I am looking for a way to check an entire IDE/SATA drive in SCO Openserver 5.0.6 for potential bad sectors. The requirements for this check are:

(1) Must be able to be run remotely -- do not have access to the console on this machine.
(2) Must be able to run at run-level 2 or higher, non-destructively.
(3) Must provide good/bad output to a pollable file.

I have tried badtrk several times with several different options and cannot get it to write an output file with the bad information. I have run badtrk on drives that are known to be bad, and when run interactively, I get the error messages. When I run it remotely via script, it returns nothing on the same machines. If anyone can help with the proper command structure to get output, I would greatly appreciate it, or if anyone knows of another way to check these sectors, that would be great, too. I have tried using a dd seek on each block of the drive, but I run into problems with MAXINT which keeps me from testing anything larger than a 2G drive with this method.
 
A starting point:
echo "4\nq" | badtrk

Hope This Helps, PH.
FAQ219-2884
FAQ181-2886
 
PHV,

I can run badtrk from command line and get it to perform the drive check...I just can't get it to write output to a file. When badtrk is run on a SCSI drive, it outputs the type of drive and whether or not any bad sectors were found. For IDE/SATA, I get no such output, except for what shows on the console screen when I run it interactively, so I don't know if it is actually doing or finding anything. The only way I have found a way to produce output is to run badtrk -v (verbose) and redirect stderr to a file, which ends up being a several-meg-sized file that technically only contains one uber-long line of undecipherable information!
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top