"Fixes the dmi_attachment failure bug by "eating" the bad exit code. There's some shell magic to ensure that if the top directory is unreadable, it *does* exit with an error code.

If run as a normal user, it fails to read some files. If run as root, there's one special file that it also fails to read.

The list of files it can't read is in the bug report. I checked and the exit code is indeed 2 (errors). So grep is behaving correctly; it's telling us it couldn't read some of the files. The fact that the output is suppressed means this was expected; previously we relied on checkbox "eating" the exit code for resource jobs to keep that from showing up in the test reports.

We care about grep's output, consisting of lines like:

/sys/class/dmi/id/chassis_version:0.1
/sys/class/dmi/id/bios_date:12/11/2013
/sys/class/dmi/id/bios_version:A02
/sys/class/dmi/id/sys_vendor:Dell Inc.

The bug mentioned that this information might be unnecessary now, as we have the full dmidecode_attachment and we shouldn't need this rather primitive dmi output. That could use a bit more research. For instance we could do a run with dmi_attachment and one without, and run the submissions through the parser, if they don't produce different output then we conceivably don't need dmi_attachment. [r=zkrynicki][bug=1238009][author=roadmr]"