Fix ROCm detection false-negative in Harbor doctor due to pipeline exit code 141

[zackbcom]

Summary

This change fixes a false ROCm warning in Harbor doctor caused by the amdgpu module check using a pipeline with grep -q.

The previous check could surface a broken-pipe style exit status (141) during harbor doctor, which caused the ROCm detection path to behave incorrectly even though the underlying module check itself was fine.

System

Running on Debian 13 VM

What changed

• Replaced the pipeline-based module check with a non-pipelined implementation that captures lsmod output first and then checks it in-memory.
• This preserves the intended logic:
  • kfd exists
  • render nodes exist
  • amdgpu is loaded

Why this was happening

The old pattern effectively used:

lsmod 2>/dev/null | grep -q "^amdgpu " || return 1

That can return a non-zero status like 141 in some shell/pipeline cases, which is interpreted as a failed check even when amdgpu is present.

Examples of how it fails

Example 1: normal module present, but pipeline exits with 141

$ lsmod 2>/dev/null | grep -q "^amdgpu "
$ echo $?
141

This is the behavior that was surfacing in harbor doctor.

Example 2: direct check works, but pipeline-based check looks broken

$ lsmod 2>/dev/null | grep "^amdgpu "
amdgpu              14479360  0
$ echo $?
0

The module is clearly present, but the -q pipeline form can still trip a broken-pipe style failure depending on shell behavior.

Example 3: false warning in doctor

Before the fix, the doctor output could show:

[WARN] AMD GPU hardware found (/dev/kfd) but ROCm support is incomplete.

Even though the system actually had the amdgpu module loaded.

Result

harbor doctor now evaluates the ROCm module check reliably and no longer misreports ROCm support as incomplete due to pipeline exit code issues.