Preparing embedded and IoT logs

Preparing embedded and IoT logs

Use this guide if you’re debugging an embedded Linux device: Yocto/Buildroot/OpenWRT-based systems, single-board computers, gateways, set-top boxes, medical devices, industrial controllers, or fleet-deployed sensors.

Accepted log types

  • dmesg: kernel ring buffer for boot failures, driver probe issues, watchdog resets, thermal events.
  • Custom kernel logs: vendor or board-specific kernel output, as long as it’s text.
  • syslog / journalctl exports: system daemon logs, service failures, OOM kills, watchdog activity.
  • Application stdout/stderr: text logs from services and daemons running on the device.
  • Android bugreports: for AOSP-based embedded devices (set-top boxes, kiosks, wearables); use the Android guide.

Multi-architecture support: ARM (32/64-bit), x86, MIPS, RISC-V.

For the full accepted/rejected list, see Supported file types.

Capturing logs

Kernel ring buffer

# Full kernel buffer with timestamps
dmesg -T > dmesg.txt

# Persistent kernel log if your distro keeps one
cat /var/log/kern.log > kern.log.txt

systemd journals

# Full journal in plain text
journalctl --no-pager > journal.txt

# Since the last boot only
journalctl --no-pager -b > journal-current-boot.txt

# A specific service
journalctl --no-pager -u myservice.service > myservice.log

Syslog (non-systemd distros)

# OpenWRT, Buildroot, Yocto
logread > syslog.txt

# Traditional syslog
cat /var/log/messages > messages.txt
cat /var/log/syslog > syslog.txt

Custom application logs

If your service writes to its own log file or stdout, redirect the text output to a file and upload directly. No conversion is needed as long as the file is plaintext.

What’s not accepted

The standard restrictions apply. See Supported file types for the full list. Specifically for embedded:

  • Multi-file archives: .tar, .tar.gz, .tar.xz, .tar.zst, .zip, and .7z are ingested directly as bundles, so upload them as-is (no need to untar first). A single-file .gz (e.g. .log.gz) uploads directly too; the platform decompresses it for you.
  • Core dumps: these are binary, not accepted.
  • Hardware capture binaries (logic-analyzer, JTAG dumps): not accepted.

Example questions to ask

Ask from the Research tab once the file is analyzed. Reach for Quick Search when you already know what you’re after, Deep Research when you need the root cause.

Quick Search for fast, cited lookups:

  • “Did any driver fail to probe on this kernel build?”
  • “Show all OOM kills with the offending process and RSS at the time.”
  • “Show kernel panics and oopses.”
  • “Show watchdog resets.”

Deep Research for multi-step root-cause investigations:

  • “Why is the device rebooting after 7 days of uptime?”
  • “Find watchdog resets and correlate with thermal events.”
  • “What killed myservice repeatedly between 03:00 and 04:00?”
  • “Why did the device fail to boot?”
  • “Trace the driver init failure.”

See Quick Search and Deep Research for how the two modes differ.

Next

  • Deep Research: multi-step kernel investigation across subsystems and time windows.
  • Delta Comparison: compare a known-good firmware against a regression.
  • Quick Search: fast lookups when you know the symptom or driver name.