crash

Overview

crash is a Linux kernel crash analysis and debugging utility. It is used to inspect kernel memory, task state, stack traces, and other data from a live system or from a captured dump, depending on how it is invoked and which supporting files are available. The exact workflow depends on the kernel image, debug information, and the dump data that accompany the system under investigation. (crash-utility.github.io)

In a Linux distribution, this package exists to provide a packaged, reproducible build of the upstream crash analysis tool for administrators and engineers who need to debug kernel issues after a system crash or during low-level investigation. NiceOS maintainers should verify distro-specific integration details in the spec file and related packaging metadata.

Purpose and typical use cases

Typical uses of crash include:

• analyzing kernel crash dumps after a system panic or hard failure;
• inspecting kernel data structures when debugging a live system with the required support files;
• examining tasks, memory, files, sockets, and system state during incident response;
• helping reproduce or explain kernel behavior for developers and support engineers.

Typical users include:

• system administrators handling crash-dump triage;
• kernel and systems developers;
• support and incident-response engineers;
• security engineers investigating low-level system failures, when kernel debugging is part of the workflow;
• CI/CD or release engineers who validate that kernel-debugging tooling still builds and runs as expected.

Upstream project

The upstream project is the crash utility. Its own help pages document the available commands and the intended interactive workflow. The project is designed around postmortem analysis and kernel data inspection rather than general-purpose system monitoring. (crash-utility.github.io)

When updating this package, NiceOS maintainers should verify whether upstream has changed command behavior, supported kernel/debug-info expectations, or build requirements that affect packaging.

Dist-git repository contents

This dist-git repository is organized as follows:

• SPECS/ — RPM spec files and packaging logic.
• SOURCES/ — source metadata and manifests used by the build system.
• METADATA/ — repository metadata used by the packaging workflow.
• SBOM/ — software bill of materials files, if present for this package.

The repository is intended to hold packaging metadata, not the full upstream source tree.

Source storage and integrity policy

Large upstream source archives are intentionally not stored in this Git repository. Instead, source integrity is tracked through manifest files in SOURCES/. This keeps the repository small and makes source handling fit the dist-git workflow.

Before updating the package, maintainers should verify that:

• the manifest entries in SOURCES/ still match the upstream source being packaged;
• any source replacement or refresh is intentional and documented in the spec changelog or packaging notes;
• the build uses the expected upstream release artifact and not a locally modified copy;
• repository metadata still reflects the same upstream project and packaging intent.

If the package ships additional generated files, NiceOS maintainers should confirm whether they must be regenerated as part of the update process.

NiceOS maintenance notes

Before submitting or accepting an update, check the following:

• Review upstream changes for build system, command-line behavior, and dependency changes that may affect the RPM.
• Confirm whether the spec file needs refreshes in %prep, %build, %check, install paths, or file ownership lists.
• Check whether any generated files in SOURCES/, SBOM/, or other packaging metadata need regeneration.
• Verify that documentation references, licenses, and packaging macros still match the repository layout.
• Review whether the update changes the expected debug-info or kernel-image inputs used by crash.
• Consider whether the package can still be rebuilt in the target NiceOS branch without special overrides.
• If upstream changed command behavior or default paths, confirm that any packaging notes or helper scripts remain accurate.

Risks to consider:

• changes in upstream build tooling or supported compiler versions;
• differences in kernel/debug-info expectations between environments;
• packaging regressions caused by stale file lists or install paths;
• accidental source mismatches if manifests are not refreshed correctly.

Build and verification checklist

For RPM maintainers, a practical update check is:

• inspect the spec diff before building;
• verify that SOURCES/ still describes the intended upstream source;
• run a clean build in the target branch environment;
• check that all installed files are owned by the package and that no unintended files are shipped;
• confirm that licensing metadata is still correct;
• review build logs for warnings that indicate missing debug data, dependency drift, or packaging assumptions;
• if applicable, run any package-specific tests or smoke checks defined by the spec or CI.

For functional verification, a maintainer may also want to confirm that the binary starts, prints help correctly, and matches the expected upstream command set for the packaged build. Exact test coverage should follow the package spec and local QA policy.

References

• crash utility help pages
• crash utility help command
• crash utility white paper
• crash utility sys command

Russian documentation

See README_RU.md for the Russian version of this document.

Dist-git repository notes

• Package repository: rpms/crash
• NiceOS branch: niceos-5.2
• This README is intentionally stable and does not include EVR, source archive checksums or lock hashes.