1KDUMP.CONF(5) File Formats Manual KDUMP.CONF(5)
2
6 kdump.conf - configuration file for kdump kernel.
7
10 kdump.conf is a configuration file for the kdump kernel crash collec‐
11 tion service.
12 kdump.conf provides post-kexec instructions to the kdump kernel. It is
14 stored in the initrd file managed by the kdump service. If you change
15 this file and do not want to reboot in order for the changes to take
16 effect, restart the kdump service to rebuild the initrd.
17 For most configurations, you can simply review the examples provided in
19 the stock /etc/kdump.conf.
20 NOTE: For filesystem dumps the dump target must be mounted before
22 building kdump initramfs.
23 kdump.conf only affects the behavior of the initramfs. Please read the
25 kdump operational flow section of kexec-kdump-howto.txt in the docs to
26 better understand how this configuration file affects the behavior of
27 kdump.
28
31 raw <partition>
32 Will dd /proc/vmcore into <partition>. Use persistent device
33 names for partition devices, such as /dev/vg/<devname>.
34 nfs <nfs mount>
36 Will mount nfs to <mnt>, and copy /proc/vmcore to
37 <mnt>/<path>/%HOST-%DATE/, supports DNS. Note that a fqdn should
38 be used as the server name in the mount point.
39 ssh <user@server>
41 Will scp /proc/vmcore to <user@server>:<path>/%HOST-%DATE/, sup‐
42 ports DNS. NOTE: make sure user has necessary write permissions
43 on server and that a fqdn is used as the server name.
44 sshkey <path>
46 Specify the path of the ssh key to use when dumping via ssh.
47 The default value is /root/.ssh/kdump_id_rsa.
48 <fs type> <partition>
50 Will mount -t <fs type> <partition> <mnt>, and copy /proc/vmcore
51 to <mnt>/<path>/%DATE/. NOTE: <partition> can be a device node,
52 label or uuid. It's recommended to use persistent device names
53 such as /dev/vg/<devname>. Otherwise it's suggested to use
54 label or uuid.
55 path <path>
57 "path" represents the file system path in which vmcore will be
58 saved. If a dump target is specified in kdump.conf, then "path"
59 is relative to the specified dump target.
60 Interpretation of "path" changes a bit if the user didn't spec‐
62 ify any dump target explicitly in kdump.conf. In this case,
63 "path" represents the absolute path from root. The dump target
64 and adjusted path are arrived at automatically depending on
65 what's mounted in the current system.
66 Ignored for raw device dumps. If unset, will use the default
68 "/var/crash".
69 core_collector <command> <options>
71 This allows you to specify the command to copy the vmcore. The
72 default is makedumpfile, which on some architectures can drasti‐
73 cally reduce core file size. See /sbin/makedumpfile --help for a
74 list of options. Note that the -i and -g options are not needed
75 here, as the initrd will automatically be populated with a con‐
76 fig file appropriate for the running kernel.
77 Note 1: About default core collector: The default core_collector
79 for raw/ssh dump is: "makedumpfile -F -l --message-level 1 -d
80 31". The default core_collector for other targets is: "make‐
81 dumpfile -l --message-level 1 -d 31". Even if core_collector
82 option is commented out in kdump.conf, makedumpfile is the
83 default core collector and kdump uses it internally. If one
84 does not want makedumpfile as default core_collector, then they
85 need to specify one using core_collector option to change the
86 behavior.
87 Note 2: If "makedumpfile -F" is used then you will get a flat‐
89 tened format vmcore.flat, you will need to use "makedumpfile -R"
90 to rearrange the dump data from standard input to a normal dump‐
91 file (readable with analysis tools). ie. "makedumpfile -R
92 vmcore < vmcore.flat"
93 kdump_post <binary | script>
96 This directive allows you to run a specified executable just
97 after the vmcore dump process terminates. The exit status of
98 the current dump process is fed to the kdump_post executable as
99 its first argument($1). Executable can modify it to indicate
100 the new exit status of succeeding dump process,
101 Note that scripts written for use with this directive must use
103 the /bin/bash interpreter.
104 kdump_pre <binary | script>
106 Works just like the "kdump_post" directive, but instead of run‐
107 ning after the dump process, runs immediately before. Exit sta‐
108 tus of this binary is interpreted as follows:
109 0 - continue with dump process as usual
111 non 0 - reboot the system
113 Note that scripts written for this directive must use the
115 /bin/bash interpreter.
116 extra_bins <binaries | shell scripts>
118 This directive allows you to specify additional binaries or
119 shell scripts you'd like to include in your kdump initrd. Gener‐
120 ally only useful in conjunction with a kdump_post binary or
121 script that relies on other binaries or scripts.
122 extra_modules <module(s)>
124 This directive allows you to specify extra kernel modules that
125 you want to be loaded in the kdump initrd, typically used to set
126 up access to non-boot-path dump targets that might otherwise not
127 be accessible in the kdump environment. Multiple modules can be
128 listed, separated by spaces, and any dependent modules will
129 automatically be included.
130 default <reboot | halt | poweroff | shell | dump_to_rootfs>
132 Action to perform in case dumping to the intended target fails.
133 The default is "reboot". reboot: Reboot the system (this is
134 what most people will want, as it returns the system to a normal
135 state). halt: Halt the system and lose the vmcore. poweroff:
136 The system will be powered down. shell: Drop to a shell session
137 inside the initramfs, from which you can manually perform addi‐
138 tional recovery actions. Exiting this shell reboots the system.
139 Note: kdump uses bash as the default shell. dump_to_rootfs: If
140 non-root dump target is specified, the default action can be set
141 as dump_to_rootfs. That means when dumping to target fails,
142 dump vmcore to rootfs from initramfs context and reboot.
143 force_rebuild <0 | 1>
145 By default, kdump initrd will only be rebuilt when necessary.
146 Specify 1 to force rebuilding kdump initrd every time when kdump
147 service starts.
148 force_no_rebuild <0 | 1>
150 By default, kdump initrd will be rebuilt when necessary. Spec‐
151 ify 1 to bypass rebuilding of kdump initrd.
152 force_no_rebuild and force_rebuild options are mutually exclu‐
155 sive and they should not be set to 1 simultaneously.
156 override_resettable <0 | 1>
158 Usually an unresettable block device can't be a dump target.
159 Specifying 1 means that even though the block target is unreset‐
160 table, the user wants to try dumping anyway. By default, it's
161 set to 0, which will not try something destined to fail.
162 dracut_args <arg(s)>
165 Kdump uses dracut to generate initramfs for second kernel. This
166 option allows a user to pass arguments to dracut directly.
167 fence_kdump_args <arg(s)>
170 Command line arguments for fence_kdump_send (it can contain all
171 valid arguments except hosts to send notification to).
172 fence_kdump_nodes <node(s)>
175 List of cluster node(s) except localhost, separated by spaces,
176 to send fence_kdump notification to (this option is mandatory to
177 enable fence_kdump).
178
182 net <nfs mount>|<user@server>
183 net option is replaced by nfs and ssh options. Use nfs or ssh
184 options directly.
185 options <module> <option list>
187 Use KDUMP_COMMANDLINE_APPEND in /etc/sysconfig/kdump to add mod‐
188 ule options as kernel command line parameters. For example,
189 specify 'loop.max_loop=1' to limit maximum loop devices to 1.
190 link_delay <seconds>
192 link_delay was used to wait for a network device to initialize
193 before using it. Now dracut network module takes care of this
194 issue automatically.
195 disk_timeout <seconds>
197 Similar to link_delay, dracut ensures disks are ready before
198 kdump uses them.
199 debug_mem_level <0-3>
201 Turn on verbose debug output of kdump scripts regarding
202 free/used memory at various points of execution. This feature
203 has been moved to dracut now. Use KDUMP_COMMANDLINE_APPEND in
204 /etc/sysconfig/kdump and append dracut cmdline param rd.memde‐
205 bug=[0-3] to enable the debug output.
206 Higher level means more debugging output.
208 0 - no output
210 1 - partial /proc/meminfo
212 2 - /proc/meminfo
214 3 - /proc/meminfo + /proc/slabinfo
216 blacklist <list of kernel modules>
218 blacklist option was recently being used to prevent loading mod‐
219 ules in initramfs. General terminology for blacklist has been
220 that module is present in initramfs but it is not actually
221 loaded in kernel. Hence retaining blacklist option creates more
222 confusing behavior. It has been deprecated.
223 Instead, use rd.driver.blacklist option on second kernel to
225 blacklist a certain module. One can edit /etc/syscon‐
226 fig/kdump.conf and edit KDUMP_COMMANDLINE_APPEND to pass kernel
227 command line options. Refer to dracut.cmdline man page for more
228 details on module blacklist option.
229
233 Here are some examples for core_collector option:
234 Core collector command format depends on dump target type. Typically
236 for filesystem (local/remote), core_collector should accept two argu‐
237 ments. First one is source file and second one is target file. For ex.
238 ex1. core_collector "cp --sparse=always"
240 Above will effectively be translated to:
242 cp --sparse=always /proc/vmcore <dest-path>/vmcore
244 ex2. core_collector "makedumpfile -l --message-level 1 -d 31"
246 Above will effectively be translated to:
248 makedumpfile -l --message-level 1 -d 31 /proc/vmcore <dest-
250 path>/vmcore
251 For dump targets like raw and ssh, in general, core collector should
253 expect one argument (source file) and should output the processed core
254 on standard output (There is one exception of "scp", discussed later).
255 This standard output will be saved to destination using appropriate
256 commands.
257 raw dumps examples:
259 ex3. core_collector "cat"
261 Above will effectively be translated to.
263 cat /proc/vmcore | dd of=<target-device>
265 ex4. core_collector "makedumpfile -F -l --message-level 1 -d 31"
267 Above will effectively be translated to.
269 makedumpfile -F -l --message-level 1 -d 31 | dd of=<target-
271 device>
272 ssh dumps examples
274 ex5. core_collector "cat"
276 Above will effectively be translated to.
278 cat /proc/vmcore | ssh <options> <remote-location> "dd
280 of=path/vmcore"
281 ex6. core_collector "makedumpfile -F -l --message-level 1 -d 31"
283 Above will effectively be translated to.
285 makedumpfile -F -l --message-level 1 -d 31 | ssh <options>
287 <remote-location> "dd of=path/vmcore"
288 There is one exception to standard output rule for ssh dumps.
290 And that is scp. As scp can handle ssh destinations for file
291 transfers, one can specify "scp" as core collector for ssh tar‐
292 gets (no output on stdout).
293 ex7. core_collector "scp"
295 Above will effectively be translated to.
297 scp /proc/vmcore <user@host>:path/vmcore
299 examples for other options please see /etc/kdump.conf
302
305 kexec(8) mkdumprd(8) dracut.cmdline(7)
306kexec-tools 07/23/2008 KDUMP.CONF(5)