--- title: "Kernel configuration and crash reports" --- # Kernel configuration and crash reports The kernel's Kconfig tree and .config in a form, changes previewed with the kernel's tools and written to a fragment in the product layer, kernel_configme and kernel_configcheck, and oopses and panics decoded with the build's vmlinux and modules. ## Kernel configuration **Open Kernel Configuration** runs `bitbake -e virtual/kernel` and reads the kernel recipe's Kconfig tree and the build's `.config` from the build host in one round trip. The **Kernel Configuration** editor names the recipe, its version and the source and build folders it read. **State:** modelled: the Kconfig reading and evaluation equal Kconfiglib 14.1 on all 17,248 compared symbols of linux-imx lf-6.6.52-2.2.0; a real BitBake 2.8.1 load (scarthgap, meta-freescale, i.MX 8M Plus) and a fragment write that BitBake merges; the preview with the kernel's own tools; the full flow in the running app over SSH. **`kernel_configcheck` and `kernel_configme` have never run**, so their reports are read only from files written in the manual's format. No real kernel was built. Not run on Windows or with Wind River's kernel-cache. `menuconfig` itself is not embedded. ### Find and change options - The menus show `[*]`, `[M]` and `[ ]` values. Search by name, prompt or help; **Only options that show** hides options whose dependencies are not met. - An option's panel shows its type, prompt, help, menu path, where it is defined, what it depends on, selects and is selected by, and why it is forced, hidden or limited to n or m. Visibility and allowed values are the editor's evaluation of the Kconfig expressions and are labelled "Not verified by Kconfig". - Lines of the recipe's fragments that did not reach the final `.config` are named at the top and in Problems. ### Write a fragment 1. Set options in the form. Changes are collected; **Discard Changes** drops them. 2. **Preview with Kconfig** runs the kernel's `merge_config.sh` and `make alldefconfig` in a temporary folder on the build host and says what Kconfig would keep. 3. **Write to Fragment...** writes them to a `.cfg` fragment in the product layer's kernel bbappend, after a confirmation that shows the exact lines. A new fragment also gets its `FILESEXTRAPATHS` and `SRC_URI += "file://....cfg"` lines. The build's `.config` is never written. ### Configure and check **Configure the Kernel (kernel_configme)** and **Check Kernel Configuration (kernel_configcheck)** run in a terminal on the build host. Problems on the fragment lines then show `mismatch.txt` and `invalid.txt` (only when newer than `.config`), the `merge_config.sh` log of kernel_configme, and the editor's own comparison with `.config`. `KERNEL_FEATURES` (kernel-cache) is named and not resolved. Agent tools: search, explain and preview are read-only; writing a fragment and running the check always ask first. ## Kernel oopses and panics **Decode Kernel Report (Oops, Panic, BUG, WARNING)...** asks where the report is: the editor's selection or file, a terminal's selection (the serial monitor or a board's shell), a serial monitor log, a log file or the clipboard. From the Targets view, **Decode Kernel Log of Target (dmesg)...** reads a board's `dmesg` over SSH, and **Read Crash Records of Target (pstore)...** reads its pstore and ramoops records after a crash reboot. ![The choice of where a kernel report is read from: the editor, a target's kernel log, its crash records, a serial monitor log, a log file or the clipboard.](https://neuralinverse.com/docs-images/modules/embedded-linux/kernel-oops-pick-source.webp) Every report kind is recognised: oops, panic, BUG, WARNING, KASAN, KFENCE, UBSAN, lockdep and RCU, sleeping in atomic context, and lockups. On the build host the module reads the kernel recipe with `bitbake -e`, finds the unstripped `vmlinux` and the modules' `.ko` and `.debug` files in the work, image and package folders, compares the build ID (or release and build number) the kernel printed and says when they differ, then runs the kernel's own `scripts/decode_stacktrace.sh` (with `decodecode` for the `Code:` line) and `faddr2line` with the recipe's cross binutils. The **Kernel Report** editor shows the facts (process, kernel, build ID, taint, hardware, access), every frame with function, file and line (inlined functions named, the culprit highlighted, source opened from the build host), the registers and the disassembled `Code:` bytes. Problems marks the faulting line with the calls that led there. **Export Kernel Report as Text** writes the defect record. Agent tools: decoding a report and listing crash records, both read-only. **State:** modelled with a Linux 6.8 arm64 kernel built with debug info, KASAN, lockdep, UBSAN, LKDTM, pstore and build IDs, booted in QEMU 8.2.2 with BusyBox and Dropbear: every report kind triggered for real and decoded with the real scripts; `dmesg` and pstore read over SSH after a crash reboot; a real `bitbake -e virtual/kernel` for qemuarm64; the running app end to end. Not run with a kernel built by BitBake, on a real i.MX board, on Windows, with x86 and arm32 frames, EFI pstore, `-dbg` package tarballs, the SDK fallback for the cross tools, or the serial monitor log path in the app. Next: [Device trees](https://neuralinverse.com/docs/modules/embedded-linux/device-trees/).