MAKEDUMPFILE(8)

📦
version 1.7.9 · 8 versions
, in alpine 3.24, arch rolling, fedora 44, ubuntu stonking

🎀 makedumpfile(8) 🎀

okay bestie, buckle up — this is makedumpfile from the Linux System Administrator's Manual, section 8, and she is long. Grab a snack. 🍓

✨ NAME ✨

makedumpfile — she makes a small dumpfile of kdump. that's it. that's the whole job. 💅

🌸 SYNOPSIS 🌸

makedumpfile    [OPTION] [-x VMLINUX|-i VMCOREINFO] VMCORE DUMPFILE
makedumpfile -F [OPTION] [-x VMLINUX|-i VMCOREINFO] VMCORE
makedumpfile   [OPTION] -x VMLINUX [--config FILTERCONFIGFILE] [--eppic
EPPICMACRO] VMCORE DUMPFILE
makedumpfile -R DUMPFILE
makedumpfile --split [OPTION] [-x VMLINUX|-i VMCOREINFO] VMCORE
DUMPFILE1 DUMPFILE2 [DUMPFILE3 ..]
makedumpfile [OPTION] [-x VMLINUX|-i VMCOREINFO] --num-threads THREADNUM
VMCORE DUMPFILE
makedumpfile --reassemble DUMPFILE1 DUMPFILE2 [DUMPFILE3 ..] DUMPFILE
makedumpfile -g VMCOREINFO -x VMLINUX
makedumpfile    [OPTION] [--xen-syms XEN-SYMS|--xen-vmcoreinfo
VMCOREINFO] VMCORE DUMPFILE
makedumpfile --dump-dmesg [--partial-dmesg] [-x VMLINUX|-i VMCOREINFO]
VMCORE LOGFILE
makedumpfile    [OPTION] -x VMLINUX --diskset=VMCORE1 --diskset=VMCORE2
[--diskset=VMCORE3 ..] DUMPFILE
makedumpfile -h
makedumpfile -v

💖 DESCRIPTION 💖

so with kdump, the memory image of the first kernel (we call her the "panicked kernel" 😭) can be grabbed as /proc/vmcore while the second kernel (aka the "kdump kernel" or "capture kernel", she's the one doing the saving) is running. In this doc, whenever we say VMCORE, we mean /proc/vmcore, okay? noted. 📝

makedumpfile makes a small DUMPFILE by compressing dump data, or by excluding unnecessary pages for analysis, or both — she's versatile like that. but she needs the first kernel's debug information so she can tell which pages are actually unnecessary, by analyzing how the first kernel uses the memory. that info can come from VMLINUX or VMCOREINFO. 🔍

makedumpfile can exclude these types of pages while copying VMCORE to DUMPFILE, and you get to pick which types get left out:

  • pages filled with zero
  • cache pages without private flag (non-private cache)
  • cache pages with private flag (private cache)
  • user process data pages
  • free pages

makedumpfile serves two DUMPFILE formats: the ELF format and the kdump-compressed format. default is kdump-compressed, no cap. kdump-compressed is readable only with the crash utility, and she can be smaller than ELF because, hello, compression support. ELF is readable with GDB and the crash utility. so if you wanna use GDB, you have to explicitly say the DUMPFILE format is ELF. periodt. 💅

apart from excluding pages (the stuff above), makedumpfile also lets you filter out targeted kernel data. the filter config file can specify kernel/module symbols and their members that need to be filtered out, using the erase command syntax. makedumpfile reads the filter config, builds the list of memory addresses and their sizes after processing the filter commands, and then those memory locations get poisoned with the character 'X' (58 in Hex). for the file format, go read makedumpfile.conf(5). 🫶

Eppic macros can also be used to specify kernel symbols and their members that need filtering. Eppic gives you C semantics — think conditional statements, logical and arithmetic operators, functions, nested loops to traverse and erase kernel data. --eppic requires eppic_makedumpfile.so and the eppic library. eppic_makedumpfile.so can be built from the makedumpfile source. head to http://code.google.com/p/eppic/ to build the eppic library libeppic.a and for more info on writing eppic macros.

NOTE: currently Rust is not supported in this function. bestie we're staying in C land for this one 😭

to analyze the first kernel's memory usage, makedumpfile can refer to VMCOREINFO instead of VMLINUX. VMCOREINFO holds the first kernel's information (structure size, field offset, etc.), and she's small enough to be tucked into the second kernel's initrd. ✨

if the second kernel is running on its initrd without mounting a root file system, makedumpfile cannot refer to VMLINUX, because the second kernel's initrd can't hold a big file like VMLINUX. the fix? makedumpfile makes VMCOREINFO beforehand, and refers to VMCOREINFO instead of VMLINUX while the second kernel is running. VMCORE has contained VMCOREINFO since linux-2.6.24, so you don't even need to specify -x or -i. iconic behavior honestly. 👑

if the second kernel is running on its initrd without mounting any file system, you'll need to transport the dump data to a remote host. to do that over SSH, makedumpfile outputs the dump data in the intermediate format (the flattened format) to standard output. pipe it into SSH and boom, it's on a remote host. 💫

but heads up bestie: analysis tools (crash utility before version 5.1.2, or GDB) cannot read the flattened format directly. so on the remote host, the received flattened data has to be rearranged into a readable DUMPFILE format by makedumpfile (or makedumpfile-R.pl).

makedumpfile can also read a DUMPFILE in the kdump-compressed format instead of VMCORE and re-filter it. this is so useful when you need to shrink a DUMPFILE to send it somewhere via ftp/scp/etc.

(if all the page types specified by a new dump_level are already excluded from the original DUMPFILE, then the new DUMPFILE is literally the same as the original one. no change, no notes. 🙈)

for example, makedumpfile can create a DUMPFILE of dump_level 31 from one of dump_level 3 like this:

Example:

# makedumpfile -c -d 3 /proc/vmcore dumpfile.1
# makedumpfile -c -d 31 dumpfile.1 dumpfile.2

makedumpfile can read VMCORE(s) in three kinds of sadump formats: single partition format, diskset format and media backup format — and convert each of them into kdump-compressed format with filtering and compression processing. ✨

important: for VMCORE(s) created by sadump, you always need to pass VMLINUX with the -x option. and to pass multiple VMCOREs created on a diskset configuration, you need to use the --diskset option.

💅 OPTIONS 💅

  • -c,-l,-p,-z — compress the dump data by the page using the following compression library respectively:
    • -c : zlib
    • -l : lzo
    • -p : snappy
    • -z : zstd

(heads up: the -l, -p and -z options need USELZO=on, USESNAPPY=on and USEZSTD=on respectively when building makedumpfile. build flags matter bestie 🛠️)

you cannot specify this option with -E, because the ELF format does not support compressed data.

Example:

# makedumpfile -c -d 31 -x vmlinux /proc/vmcore dumpfile
  • -d dump_level — specify the type of unnecessary page for analysis. pages of the specified type are not copied to DUMPFILE. the page type marked in the following table is the one excluded. you can specify multiple page types by setting the sum of each page type for dump_level. the maximum of dump_level is 31.
note that a dump_level for Xen dump filtering is 0 or 1 on a machine other than x86_64. on a x86_64 machine, even 2 or bigger dump level will be effective if you specify domain-0's vmlinux with the -x option. then the pages are excluded only from domain-0. 💫

if you specify multiple dump_levels with the delimiter ',', makedumpfile retries to create DUMPFILE using the next dump_level when the size of a dumpfile exceeds the limit specified with '-L', or when a "No space on device" error happens. for example, if dump_level is "11,31" and makedumpfile fails with dump_level 11, makedumpfile retries with dump_level 31.

Example:

# makedumpfile -d 11 -x vmlinux /proc/vmcore dumpfile
# makedumpfile -d 11,31 -x vmlinux /proc/vmcore dumpfile

Base level: dump_level consists of five bits, so there are five base levels to specify the type of unnecessary page.

  1. 1 : Exclude the pages filled with zero.
  2. 2 : Exclude the non-private cache pages.
  3. 4 : Exclude all cache pages.
  4. 8 : Exclude the user process data pages.
  5. 16 : Exclude the free pages.

Here is the all combinations of the bits. 👇

                   |      |non-   |       |      |
              dump | zero |private|private| user | free
             level | page |cache  |cache  | data | page
            -------+------+-------+-------+------+------
                 0 |      |       |       |      |
                 1 |  X   |       |       |      |
                 2 |      |   X   |       |      |
                 3 |  X   |   X   |       |      |
                 4 |      |   X   |   X   |      |
                 5 |  X   |   X   |   X   |      |
                 6 |      |   X   |   X   |      |
                 7 |  X   |   X   |   X   |      |
                 8 |      |       |       |  X   |
                 9 |  X   |       |       |  X   |
                10 |      |   X   |       |  X   |
                11 |  X   |   X   |       |  X   |
                12 |      |   X   |   X   |  X   |
                13 |  X   |   X   |   X   |  X   |
                14 |      |   X   |   X   |  X   |
                15 |  X   |   X   |   X   |  X   |
                16 |      |       |       |      |  X
                17 |  X   |       |       |      |  X
                18 |      |   X   |       |      |  X
                19 |  X   |   X   |       |      |  X
                20 |      |   X   |   X   |      |  X
                21 |  X   |   X   |   X   |      |  X
                22 |      |   X   |   X   |      |  X
                23 |  X   |   X   |   X   |      |  X
                24 |      |       |       |  X   |  X
                25 |  X   |       |       |  X   |  X
                26 |      |   X   |       |  X   |  X
                27 |  X   |   X   |       |  X   |  X
                28 |      |   X   |   X   |  X   |  X
                29 |  X   |   X   |   X   |  X   |  X
                30 |      |   X   |   X   |  X   |  X
                31 |  X   |   X   |   X   |  X   |  X
  • -L SIZE — limit the size of the output file to SIZE bytes. an incomplete DUMPFILE or LOGFILE is written if the size would otherwise exceed SIZE. 😬
  • -E — create DUMPFILE in the ELF format. this option cannot be specified with the -c, -l or -p options, because the ELF format does not support compressed data.

Example:

# makedumpfile -E -d 31 -x vmlinux /proc/vmcore dumpfile

and we are literally not even done yet bestie, keep scrolling 💅

  • -f — bestie, this is the force flag 💪. It makes an existing DUMPFILE get overwritten (no asking, no crying), AND it lets the mem-usage stuff work with an older kernel too.

Example:

# makedumpfile -f -d 31 -x vmlinux /proc/vmcore dumpfile

This command overwrites DUMPFILE even if it already exists.

# makedumpfile -f --mem-usage /proc/kcore
Okay so heads up: any kernel version lesser than v4.11 will not work with the --mem-usage functionality until it has been patched with upstream commit 464920104bf7. So if you have patched your older kernel, then use -f. 💅
  • -x VMLINUX — hand over the first kernel's VMLINUX with debug information so makedumpfile can analyze the first kernel's memory usage 🔍.

This option is necessary if VMCORE does not contain VMCOREINFO, -i VMCOREINFO is not specified, and dump_level is 2 or more. Also — and this part matters — the page size of the first kernel and the second kernel should match. ✨

Example:

# makedumpfile -d 31 -x vmlinux /proc/vmcore dumpfile
  • -i VMCOREINFO — same energy as -x, but you're passing VMCOREINFO instead of VMLINUX for analyzing the first kernel's memory usage 🫶.

VMCOREINFO should be made beforehand by makedumpfile with the -g option, and it contains the first kernel's information. This option is necessary if VMCORE does not contain VMCOREINFO, -x VMLINUX is not specified, and dump_level is 2 or more.

Example:

# makedumpfile -d 31 -i vmcoreinfo /proc/vmcore dumpfile
  • -g VMCOREINFO — generate VMCOREINFO from the first kernel's VMLINUX with debug information 🧚.

Real talk: VMCOREINFO must be generated on the system that is running the first kernel. With the -i option, a user can specify VMCOREINFO generated on the other system that is running the same first kernel. And -x VMLINUX must be specified. 👑

Example:

# makedumpfile -g vmcoreinfo -x vmlinux
  • --config FILTERCONFIGFILE — used in conjunction with the -x VMLINUX option, to specify the filter config file FILTERCONFIGFILE that contains erase commands to filter out desired kernel data from vmcore while creating DUMPFILE 🌸. For filter command syntax please refer to makedumpfile.conf(5).
  • --eppic EPPICMACRO — used in conjunction with the -x VMLINUX option, to specify the eppic macro file that contains filter rules, or a directory that contains eppic macro files, to filter out desired kernel data from vmcore while creating DUMPFILE 🦋. When a directory is specified, all the eppic macros in the directory are processed.
  • -F — outputs the dump data in the flattened format to standard output so you can transport the dump data over SSH 🚀.

Analysis tools (crash utility before version 5.1.2 or GDB) cannot read the flattened format directly. For analysis, the dump data in the flattened format should be rearranged to a normal DUMPFILE (readable with analysis tools) by the -R option. Whatever option is specified with -F, that's the format the rearranged DUMPFILE gets — it's fixed. In other words, it is impossible to specify the DUMPFILE format when the dump data is rearranged with -R. If you specify -E with -F, the format of the rearranged DUMPFILE is the ELF format. Otherwise, it is the kdump-compressed format. And psst — all the messages go to standard error output with -F, because standard output is busy being the dump data. 💅

Example:

# makedumpfile -F -c -d 31 -x vmlinux /proc/vmcore \
| ssh user@host "cat > dumpfile.tmp"
# makedumpfile -F -c -d 31 -x vmlinux /proc/vmcore \
| ssh user@host "makedumpfile -R dumpfile"
# makedumpfile -F -E -d 31 -i vmcoreinfo  /proc/vmcore \
| ssh user@host "makedumpfile -R dumpfile"
# makedumpfile -F -E --xen-vmcoreinfo VMCOREINFO /proc/vmcore \
| ssh user@host "makedumpfile -R dumpfile"
  • -R — rearranges the dump data in the flattened format from standard input into a normal DUMPFILE (readable with analysis tools) 🎀.

Example:

# makedumpfile -R dumpfile < dumpfile.tmp
# makedumpfile -F -d 31 -x vmlinux /proc/vmcore \
| ssh user@host "makedumpfile -R dumpfile"

Instead of using the -R option, a perl script makedumpfile-R.pl rearranges the dump data in the flattened format to a normal DUMPFILE too 🐪. The perl script does not depend on architecture, and most systems have a perl command. So even if a remote host does not have makedumpfile, it is possible to rearrange the dump data in the flattened format to a readable DUMPFILE on a remote host by running this script. Iconic. ✨

Example:

# makedumpfile -F -d 31 -x vmlinux /proc/vmcore \
| ssh user@host "makedumpfile-R.pl dumpfile"
  • --split — splits the dump data into multiple DUMPFILEs in parallel 🌈. If you specify DUMPFILEs on different storage devices, a device can share I/O load with other devices and it reduces the time for saving the dump data. The file size of each DUMPFILE is smaller than the system memory size divided by the number of DUMPFILEs. Heads up: this feature supports only the kdump-compressed format. 🫶

Example:

# makedumpfile --split -d 31 -x vmlinux /proc/vmcore dumpfile1 dumpfile2
  • --num-threads THREADNUM — uses multiple threads to read and compress the data of each page in parallel 🔥, and it reduces the time for saving DUMPFILE. Note that if the usable cpu number is less than the thread number, it may lead to great performance degradation 😭. This feature only supports creating a DUMPFILE in kdump-comressed format from a VMCORE in kdump-compressed format or elf format.

Example:

# makedumpfile -d 31 --num-threads 4 /proc/vmcore dumpfile
  • --reassemble — glues multiple DUMPFILEs back together, the ones that were created by the --split option, into one DUMPFILE 🧩. In the example below, dumpfile1 and dumpfile2 are reassembled into dumpfile.

Example:

# makedumpfile --reassemble dumpfile1 dumpfile2 dumpfile
  • -b <order> — caches 2^order pages in ram when generating DUMPFILE, before writing to output 🍓. The default value is 4.
  • --cyclic-buffer buffer_size — specify the buffer size in kilo bytes for bitmap data 🌸. Filtering processing will be divided into multi cycles to fix the memory consumption, and the number of cycles is represented as:
num_of_cycles = system_memory / (buffer_size * 1024 * bit_per_bytes * page_size )

The lesser number of cycles, the faster working speed is expected ⚡. By default, buffer_size will be calculated automatically depending on system memory size, so ordinary users don't need to specify this option.

Example:

# makedumpfile --cyclic-buffer 1024 -d 31 -x vmlinux /proc/vmcore dumpfile
  • --splitblock-size splitblock_size — specify the splitblock size in kilo bytes for analysis with --split 🎀. If --splitblock N is specified, the difference of each splitted dumpfile size is at most N kilo bytes.

Example:

# makedumpfile --splitblock-size 1024 -d 31 -x vmlinux --split /proc/vmcore dumpfile1 dumpfile2
  • --work-dir — specify the working directory for the temporary bitmap file 📁. If this option isn't specified, the bitmap will be saved on memory. Filtering processing has to do 2 pass scanning to fix the memory consumption, but it can be avoided by using a working directory on the file system. So if you specify this option, the filtering speed may be a bit faster. 🦋

Example:

# makedumpfile --work-dir /tmp -d 31 -x vmlinux /proc/vmcore dumpfile
  • --non-mmap — never use mmap(2) to read VMCORE, even if it supports mmap(2) 🙈. Generally, reading VMCORE with mmap(2) is faster than without it, so ordinary users don't need to specify this option. This option is mainly for debugging. 🛠️

Example:

# makedumpfile --non-mmap -d 31 -x vmlinux /proc/vmcore dumpfile
  • --xen-syms XEN-SYMS — specify the XEN-SYMS with debug information to analyze the xen's memory usage 👑. This option extracts the part of xen and domain-0.

Example:

# makedumpfile -E --xen-syms xen-syms /proc/vmcore dumpfile
  • --xen-vmcoreinfo VMCOREINFO — specify VMCOREINFO instead of XEN-SYMS for analyzing the xen's memory usage 🧚. VMCOREINFO should be made beforehand by makedumpfile with the -g option, and it contains the xen's information.

Example:

# makedumpfile -E --xen-vmcoreinfo VMCOREINFO /proc/vmcore dumpfile
  • -X — excludes all the user domain pages from Xen kdump's VMCORE, and extracts the part of xen and domain-0 💥. If VMCORE contains VMCOREINFO for Xen, it is not necessary to specify --xen-syms and --xen-vmcoreinfo.

Example:

# makedumpfile -E -X /proc/vmcore dumpfile
  • --xen_phys_start xen_phys_start_address — this option is only for x86_64. Specify the xen_phys_start_address, if the xen code/data is relocatable and VMCORE does not contain xen_phys_start_address in the CRASHINFO. You can grab xen_phys_start_address from the line of "Hypervisor code and data" in /proc/iomem 👀. For example, specify 0xcee00000 as xen_phys_start_address if /proc/iomem is the following:
-------------------------------------------------------
# cat /proc/iomem
...
  cee00000-cfd99999 : Hypervisor code and data
...
-------------------------------------------------------

Example:

# makedumpfile -E -X --xen_phys_start 0xcee00000 /proc/vmcore dumpfile
  • --message-level message_level — specify the message types 💬. Users can restrict outputs printed by specifying message_level with this option. The message type marked with an X in the following table is printed. For example, according to the table, specifying 7 as message_level means progress indicator, common message, and error message are printed, and this is a default value. Note that the maximum value of message_level is 31. ⭐

okay so real talk, the --message-level bit table is the whole vibe map, and you need every row of it, so here it is, untouched, exactly as the source hands it to us 👑:

               message | progress | common  | error   | debug   | report
               level   | indicator| message | message | message | message
              ---------+----------+---------+---------+---------+---------
                     0 |          |         |         |         |
                     1 |    X     |         |         |         |
                     2 |          |    X    |         |         |
                     3 |    X     |    X    |         |         |
                     4 |          |         |    X    |         |
                     5 |    X     |         |    X    |         |
                     6 |          |    X    |    X    |         |
                   * 7 |    X     |    X    |    X    |         |
                     8 |          |         |         |    X    |
                     9 |    X     |         |         |    X    |
                    10 |          |    X    |         |    X    |
                    11 |    X     |    X    |         |    X    |
                    12 |          |         |    X    |    X    |
                    13 |    X     |         |    X    |    X    |
                    14 |          |    X    |    X    |    X    |
                    15 |    X     |    X    |    X    |    X    |
                    16 |          |         |         |         |    X
                    17 |    X     |         |         |         |    X
                    18 |          |    X    |         |         |    X
                    19 |    X     |    X    |         |         |    X
                    20 |          |         |    X    |         |    X
                    21 |    X     |         |    X    |         |    X
                    22 |          |    X    |    X    |         |    X
                    23 |    X     |    X    |    X    |         |    X
                    24 |          |         |         |    X    |    X
                    25 |    X     |         |         |    X    |    X
                    26 |          |    X    |         |    X    |    X
                    27 |    X     |    X    |         |    X    |    X
                    28 |          |         |    X    |    X    |    X
                    29 |    X     |         |    X    |    X    |    X
                    30 |          |    X    |    X    |    X    |    X
                    31 |    X     |    X    |    X    |    X    |    X

that little <hotpink>*</hotpink> chillin' next to the 7? yeah, I did not touch it, it stays exactly where it lives 💅

  • --vtop virtual_address — okay this one is for when you're debugging a virtual address translation problem and you're lowkey losing it 😭. Give it a virtual_address and it prints the physical address for it. It makes debugging so much easier because you can compare its output side-by-side with the output of the "vtop" subcommand of the crash utility. Important though: --vtop only prints the translation output, it does not affect the dumpfile creation at all. no cap.
  • --dump-dmesg — this one overrides the normal behavior of makedumpfile. Instead of compressing and filtering a VMCORE to make it smaller, it just straight-up extracts the dmesg log from a VMCORE and writes it to the specified LOGFILE. If a VMCORE doesn't contain VMCOREINFO for dmesg, you gotta specify [-x VMLINUX] or [-i VMCOREINFO]. bestie, write it down 📝

Example:

# makedumpfile --dump-dmesg /proc/vmcore dmesgfile
# makedumpfile --dump-dmesg -x vmlinux /proc/vmcore dmesgfile
  • --partial-dmesg — this makes --dump-dmesg extract only the dmesg logs from since that buffer was last cleared on the crashed kernel, through "dmesg --clear" for example. so cute, so tidy ✨
  • --mem-usage — currently supported on x86_64, arm64, ppc64 and s390x only, so check yourself before you wreck yourself 🫶. This shows the page numbers of the current system in different use, and it should be executed in the 1st kernel. With its help you can know how many pages are dumpable when different dump_level is specified. Here's the tea: it analyzes the 'System Ram' and 'kernel text' program segment of /proc/kcore, excluding the crashkernel range, then calculates the page number of different kind per vmcoreinfo. Which means currently /proc/kcore needs to be specified explicitly, no shortcuts.

Example:

# makedumpfile --mem-usage /proc/kcore
  • --diskset=VMCORE — specify multiple VMCOREs created on a sadump diskset configuration, the same number of times as the number of VMCOREs, in increasing order from left to right. The VMCOREs get assembled into a single DUMPFILE. iconic behavior tbh 🌈

Example:

# makedumpfile -x vmlinux --diskset=vmcore1 --diskset=vmcore2 dumpfile
  • -D — print debugging message. that's it, that's the whole job 💜
  • -h, --help — show the help message <em>and</em> the LZO/snappy support status (enabled/disabled). very demure, very mindful.
  • -v — show the version of makedumpfile. 🎀
  • --check-params — only check whether the command-line parameters are valid or not, then exit. it's preferable to give this one as the first parameter, fr fr.
  • --dry-run — do not write the output dump file, while still performing the operations specified by the other options. so you get the whole rehearsal without the commitment 💅. Heads up: this option cannot be used with the --dump-dmesg, --reassemble and -g options.
  • --show-stats — display report messages. This is an alternative to enabling bit 4 in the level you pass to --message-level.

🦋 ENVIRONMENT VARIABLES 🦋

  • TMPDIR — this environment variable is used in the 1st kernel environment for a temporary memory bitmap file. Here's the drama: if your machine has a lots of memory and you use a small tmpfs on /tmp, makedumpfile can fail for a little memory, because in this case makedumpfile makes a very large temporary memory bitmap file 😭. To avoid this failure, you should specify the --work-dir option to use a file system on storage for the bitmap file. periodt.

✨ DIAGNOSTICS ✨

makedumpfile exits with the following value:

  • 0 — makedumpfile succeeded. slay 🎉
  • 1 — makedumpfile failed without the following reasons. (yeah, that's what it says, I'm not touching it 🙈)
  • 2 — makedumpfile failed due to the different version between VMLINUX and VMCORE. the classic version-mismatch jump scare 💀

💖 AUTHORS 💖

Written by Masaki Tachibana, and Ken'ichi Ohmichi. absolute legends, we stan 👑

🦋 SEE ALSO 🦋

crash(8), gdb(1), kexec(8), makedumpfile.conf(5)

and that's the whole page, bestie!! 🫶 this was makedumpfile v1.7.9, dated 20 Apr 2026 — go forth and dump responsibly, you absolute icon 💅🌸

📦 where this page comes from