From: 'Rick Moen' <email@example.com>
To: Jason Lade <firstname.lastname@example.org>
Subject: Re: Linux PC Burn-in Software?
X-Mas: Bah humbug.
Quoting Jason Lade (email@example.com):
> Quoting Rick Moen (firstname.lastname@example.org):
> > Quoting Jason Lade (email@example.com):
> > > I'm just wondering if anybody knows of any good software that I
> > > could use to burn-in PC's before they go out.
> > ftp://ftp.californiadigital.com/pub/cerberus/
RM adds: no longer accessible, but the California Digital Corporation version of CTCS aka Cerberus is now mirrored at "http://linuxmafia.com/pub/hardware/, along with a recent version from the upstream project, http://sourceforge.net/projects/va-ctcs/.
2010 update: Damon Chitsaz and Jim Belton have resumed Cerberus maintenance at new project name "CTCS2": http://sourceforge.net/projects/ctcs2/. Original maintainers Jason T. Collins and Sam Flory's apparently final release of the original "va-ctcs" project codebase was version 1.3.1-pre1 in August 2005, though that code remains (as of 2010) eminently usable.> >
> > http://linuxmafia.com/faq/Legacy_Microsoft/windows-rescue-disk.html#Memory_Test_CPU_Test_Disk_Test
> Thanks very much for those URLs. I appreciate that. And will give
> them a try right now.
Cerberus aka ctcs (Cerberus Test Control System) is both (1) a little rough-edged and (2) weird in its user interface. It works best with an installed and fairly full featured set of Linux server packages on the HD: Specifically, you must have gcc and other compile toolchain packages sufficient to compile a Linux kernel. You should also have the distribution's own full kernel source tree (not just kernel headers), unpacked somewhere. There must be a symlink /usr/src/linux pointing to that unpacked source tree. (This is necessary because one of Cerberus's many tests is an iterative kernel compile.) Also, /home must be writeable; therefore, you must stop network automounters such as "autofs".
Given all of that, what you do is this:
- cd to /tmp
- Unpack the Cerberus tarball. cd into it.
- "make". Wait for the compile to finish.
Cerberus will then run, bogging down the machine frightfully, and you'll see a rather minimal display on the console showing time elapsed — except for colourful messages if/when something major has an error. When you want to stop the testing, e.g., to check results, type Ctrl-C and wait ~30 seconds, because Cerberus really does take that long to notice your keystroke. You'll exit back to the shell.
At this point, you'll want to cd into the logging directory. This will be under "log" and have a directory name of the form .newburn.tcf.log.NNNN, where NNNN is a number generated randomly the first time you do "./newburn".
You'll now see in that directory a logfile for each test. Easiest way to do a quick check is this: "grep FAILED *". If that retuns null, then you have 100% clean results. If not, then you have to look more closely at the logfile that purported to yield non-clean results. Some interpretation is sometimes required to determine what really happened. E.g., I've seen people get basically spurious errors on the kernel-compile test because they used a slightly incompatible kernel source tree that is not the one provided by the distribution, or because they plugged and unplugged a USB flash drive (adding a phantom drive to those Cerberus will try to surface-test), or because they forgot to create a /usr/src/linux symlink.
To restart the test where you left off, do "cd ../.." to exit the logfile directory and then do "./newburn" again. Note that the elapsed-time indicator resumes where it left off. That is because it's still logging to the same .newburn.tcf.log.NNNN directory as before.
To start a completely new test run, i.e., to start Cerberus with a .newburn.tcf.log.NNNN directory for some new value of NNNN, do "./burnreset" before the next "./newburn".
The most common question I get is "Do I have to have a Linux distribution installed? Can I use it to test my Windows machines if I boot from a Knoppix disk?" The answer is: Sort of, but not easily. Cerberus is designed to test and "burn in" Linux systems — having been originally developed testing of machines being manufactured by VA Linux Systems, Inc., as part of the factory QA process, preparatory to sale.
The main obstacle to running Cerberus from Knoppix or similar is that it expects /usr/src/linux to exist and point to a full kernel tree. Knoppix doesn't provide this, and /usr/src is on the CD itself when you boot, i.e., you cannot edit its contents. (The filesystem is not writeable.)
However, you can edit, with some work, the tests that comprise Cerberus. (Cerberus is controlled entirely by interpreted scripts and editable configuration files.) Find and change the references to /usr/src/linux to point (instead) to somewhere you can write to on a Knoppix system, e.g., /tmp/kerneltree (and, of course, make sure Cerberus finds a suitable full kernel tree there). Also, you may find that you need to disable the portions of Cerberus that test the hard disk (using "iozone"), as they expect to see Linux-native, writeable filesystems — not MS-stuff like "FAT", "NTFS", etc.
The other question I get is: "Is Cerberus safe to use on a production machine, i.e., is there any chance it will hurt my files or partitions?" If you read the Cerberus docs, the developers warn that they're making absolutely no guarantees — and neither will I. However, I've used it on many production systems, without harm. One of the disk-testing routines does sometimes leave one or two garbage files behind in the root directory of each filesystem if you exit Cerberus abnormally, e.g., by hard-rebooting. Otherwise, I find that it creates only logfiles, and only underneath the runtime directory in which you started it.
And it's important to know that you must be the root user to successfully run Cerberus. (E.g., on Knoppix, do "sudo bash" first.)
In case you were wondering: I'm somewhat overdoing this explanation in order to add it to my Linux online knowledgebase. ;-)
-- Cheers, "He who hesitates is frost." Rick Moen -- Inuit proverb firstname.lastname@example.org