Description

Description

`nemoclaw debug --quick` runs to completion and produces a useful
report, but the "Kernel Messages" section is rendered as:

  ═══ Kernel Messages ═══

  dmesg: read kernel buffer failed: Operation not permitted

That single raw error line is the only thing in the section. A user
filing a bug who reads this will reasonably worry that:
  - the diagnostic tool itself is broken, or
  - something in the system is preventing `nemoclaw debug` from
    collecting kernel state at all (which would invalidate the rest
    of the report).

In reality this is just a Linux kernel.dmesg_restrict / capabilities
behaviour: unprivileged users cannot read the kernel ring buffer.
The fix is to run `sudo dmesg` or, on recent Linux, grant
CAP_SYSLOG to the user — but neither is mentioned anywhere in the
debug output or in commands.md.

This becomes a triage burden when the debug bundle is attached to a
real bug report: maintainers see an "Operation not permitted" line
near the top and have to ask the reporter whether they had sudo
available, what kernel.dmesg_restrict is set to, etc.

Note also that the OpenShell section of the same `debug --quick` run
emits four lines of "(openshell not found, skipping)" even though the
openshell binary is clearly installed and on PATH for the parent
process. That is a separate runtime bug — `nemoclaw` child processes
do not inherit PATH correctly, which also breaks
`nemoclaw  config get` (`spawnSync openshell ENOENT`). That part
should be filed/tracked separately; calling it out here so the
reviewer understands the section is "underweight" for two unrelated
reasons.

Device:        ipp2-1558 (10.176.178.100), x86_64 server, 32 vCPU / 125 GB RAM, NVIDIA A100 80GB PCIe
OS:            Ubuntu 24.04.4 LTS (Linux 6.17.0-23-generic)
Architecture:  x86_64
Docker:        29.5.0
OpenShell CLI: 0.0.39
NemoClaw:      v0.0.44
OpenClaw:      v2026.4.24
kernel.dmesg_restrict: 1 (default on this Ubuntu)

1. As a regular (non-root) user on a host where kernel.dmesg_restrict
   is 1 (the default on modern Ubuntu / Debian / Fedora):

     nemoclaw debug --quick

2. Scroll to the bottom of the output and find the "Kernel Messages"
   section.

One of:

  (a) The section is omitted entirely when dmesg is not readable, with
      a one-line explanation in the section heading itself, e.g.:

        ═══ Kernel Messages ═══

        (skipped — `dmesg` is not readable as a non-root user;
         run `sudo dmesg` separately if a kernel trace is needed)

  (b) `nemoclaw debug` tries `sudo -n dmesg` first when stdin is a
      tty, falls back to the user-level dmesg, and labels which one
      ran.

  (c) The section is wrapped in a "[info] dmesg not readable as this
      user" hint so a triager reading the bundle is not confused.

═══ Kernel Messages ═══

dmesg: read kernel buffer failed: Operation not permitted

[debug] Done. If filing a bug, run with --output and attach the
tarball to your issue:
[debug]   nemoclaw debug --output /tmp/nemoclaw-debug.tar.gz
[exit 0]

$ cat /proc/sys/kernel/dmesg_restrict
1

$ dmesg | head -3
dmesg: read kernel buffer failed: Operation not permitted

$ sudo dmesg | head -3
[    0.000000] Linux version 6.17.0-23-generic ...
[    0.000000] Command line: BOOT_IMAGE=...
[    0.000000] KERNEL supported cpus: ...

In the debug collector that emits the "Kernel Messages" section:

  - Before invoking dmesg, check whether the current process has
    CAP_SYSLOG (or, equivalently, whether /proc/sys/kernel/dmesg_restrict
    is 1 AND euid != 0).
  - If yes, run dmesg as today.
  - If no, replace the section body with:

      (skipped — `dmesg` is not readable as a non-root user
       (kernel.dmesg_restrict=1). Re-run as `sudo nemoclaw debug
       --quick` if you need kernel messages in this report.)

This matches the way the same collector already handles other
unavailable sources (e.g. "openshell not found, skipping").

Bug Details

[NVB#6186966]