← Documents Documentation/admin-guide/kdump/kdump.rst GitHub 원문 ↗

Linux 6.18.37 · Administration / Crash Dumping

Documentation for Kdump - The kexec-based Crash Dumping Solution

Kdump의 메모리 예약 원리부터 커널 구성, crashkernel 문법, 덤프 캡처 커널 적재, vmcore 저장·분석과 암호화 볼륨 지원까지 설명합니다.

Source pathDocumentation/admin-guide/kdump/kdump.rst
Source versionLinux v6.18.37
TranslationDUJINLABS 전문 번역 + 해설

요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.

1. 요약·해설

원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.

동작 원리

kdump.rst:1-59

kexec로 덤프 커널을 시작하고 예약 메모리와 ELF vmcore를 보존하는 흐름을 설명합니다.

설치와 커널 구성

kdump.rst:60-247

kexec-tools 설치와 시스템·덤프 캡처 커널의 공통 및 아키텍처별 설정을 정리합니다.

메모리 예약

kdump.rst:248-358

crashkernel의 고정·범위·high/low·CMA 문법과 부트 로더 설정을 설명합니다.

커널 적재

kdump.rst:359-487

아키텍처별 이미지, kexec 명령줄과 ELF·CPU·장치 관련 주의 사항을 안내합니다.

수집과 분석

kdump.rst:488-570

크래시 유발 조건, vmcore 저장, GDB·Crash 분석과 WARN·taint 트리거를 설명합니다.

암호화 볼륨

kdump.rst:571-612

암호화 디스크의 키 보존·복원 절차와 연락처, GDB 매크로 포함 관계를 정리합니다.

2. 영어 원문 전체

번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.

원문 전체 펼치기
1 ================================================================
2 Documentation for Kdump - The kexec-based Crash Dumping Solution
3 ================================================================
4
5 This document includes overview, setup, installation, and analysis
6 information.
7
8 Overview
9 ========
10
11 Kdump uses kexec to quickly boot to a dump-capture kernel whenever a
12 dump of the system kernel's memory needs to be taken (for example, when
13 the system panics). The system kernel's memory image is preserved across
14 the reboot and is accessible to the dump-capture kernel.
15
16 You can use common commands, such as cp, scp or makedumpfile to copy
17 the memory image to a dump file on the local disk, or across the network
18 to a remote system.
19
20 Kdump and kexec are currently supported on the x86, x86_64, ppc64,
21 s390x, arm and arm64 architectures.
22
23 When the system kernel boots, it reserves a small section of memory for
24 the dump-capture kernel. This ensures that ongoing Direct Memory Access
25 (DMA) from the system kernel does not corrupt the dump-capture kernel.
26 The kexec -p command loads the dump-capture kernel into this reserved
27 memory.
28
29 On x86 machines, the first 640 KB of physical memory is needed for boot,
30 regardless of where the kernel loads. For simpler handling, the whole
31 low 1M is reserved to avoid any later kernel or device driver writing
32 data into this area. Like this, the low 1M can be reused as system RAM
33 by kdump kernel without extra handling.
34
35 On PPC64 machines first 32KB of physical memory is needed for booting
36 regardless of where the kernel is loaded and to support 64K page size
37 kexec backs up the first 64KB memory.
38
39 For s390x, when kdump is triggered, the crashkernel region is exchanged
40 with the region [0, crashkernel region size] and then the kdump kernel
41 runs in [0, crashkernel region size]. Therefore no relocatable kernel is
42 needed for s390x.
43
44 All of the necessary information about the system kernel's core image is
45 encoded in the ELF format, and stored in a reserved area of memory
46 before a crash. The physical address of the start of the ELF header is
47 passed to the dump-capture kernel through the elfcorehdr= boot
48 parameter. Optionally the size of the ELF header can also be passed
49 when using the elfcorehdr=[size[KMG]@]offset[KMG] syntax.
50
51 With the dump-capture kernel, you can access the memory image through
52 /proc/vmcore. This exports the dump as an ELF-format file that you can
53 write out using file copy commands such as cp or scp. You can also use
54 makedumpfile utility to analyze and write out filtered contents with
55 options, e.g with '-d 31' it will only write out kernel data. Further,
56 you can use analysis tools such as the GNU Debugger (GDB) and the Crash
57 tool to debug the dump file. This method ensures that the dump pages are
58 correctly ordered.
59
60 Setup and Installation
61 ======================
62
63 Install kexec-tools
64 -------------------
65
66 1) Login as the root user.
67
68 2) Download the kexec-tools user-space package from the following URL:
69
70 http://kernel.org/pub/linux/utils/kernel/kexec/kexec-tools.tar.gz
71
72 This is a symlink to the latest version.
73
74 The latest kexec-tools git tree is available at:
75
76 - git://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git
77 - http://www.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git
78
79 There is also a gitweb interface available at
80 http://www.kernel.org/git/?p=utils/kernel/kexec/kexec-tools.git
81
82 More information about kexec-tools can be found at
83 http://horms.net/projects/kexec/
84
85 3) Unpack the tarball with the tar command, as follows::
86
87 tar xvpzf kexec-tools.tar.gz
88
89 4) Change to the kexec-tools directory, as follows::
90
91 cd kexec-tools-VERSION
92
93 5) Configure the package, as follows::
94
95 ./configure
96
97 6) Compile the package, as follows::
98
99 make
100
101 7) Install the package, as follows::
102
103 make install
104
105
106 Build the system and dump-capture kernels
107 -----------------------------------------
108 There are two possible methods of using Kdump.
109
110 1) Build a separate custom dump-capture kernel for capturing the
111 kernel core dump.
112
113 2) Or use the system kernel binary itself as dump-capture kernel and there is
114 no need to build a separate dump-capture kernel. This is possible
115 only with the architectures which support a relocatable kernel. As
116 of today, i386, x86_64, ppc64, arm and arm64 architectures support
117 relocatable kernel.
118
119 Building a relocatable kernel is advantageous from the point of view that
120 one does not have to build a second kernel for capturing the dump. But
121 at the same time one might want to build a custom dump capture kernel
122 suitable to his needs.
123
124 Following are the configuration setting required for system and
125 dump-capture kernels for enabling kdump support.
126
127 System kernel config options
128 ----------------------------
129
130 1) Enable "kexec system call" or "kexec file based system call" in
131 "Processor type and features."::
132
133 CONFIG_KEXEC=y or CONFIG_KEXEC_FILE=y
134
135 And both of them will select KEXEC_CORE::
136
137 CONFIG_KEXEC_CORE=y
138
139 2) Enable "sysfs file system support" in "Filesystem" -> "Pseudo
140 filesystems." This is usually enabled by default::
141
142 CONFIG_SYSFS=y
143
144 Note that "sysfs file system support" might not appear in the "Pseudo
145 filesystems" menu if "Configure standard kernel features (expert users)"
146 is not enabled in "General Setup." In this case, check the .config file
147 itself to ensure that sysfs is turned on, as follows::
148
149 grep 'CONFIG_SYSFS' .config
150
151 3) Enable "Compile the kernel with debug info" in "Kernel hacking."::
152
153 CONFIG_DEBUG_INFO=Y
154
155 This causes the kernel to be built with debug symbols. The dump
156 analysis tools require a vmlinux with debug symbols in order to read
157 and analyze a dump file.
158
159 Dump-capture kernel config options (Arch Independent)
160 -----------------------------------------------------
161
162 1) Enable "kernel crash dumps" support under "Processor type and
163 features"::
164
165 CONFIG_CRASH_DUMP=y
166
167 And this will select VMCORE_INFO and CRASH_RESERVE::
168 CONFIG_VMCORE_INFO=y
169 CONFIG_CRASH_RESERVE=y
170
171 2) Enable "/proc/vmcore support" under "Filesystems" -> "Pseudo filesystems"::
172
173 CONFIG_PROC_VMCORE=y
174
175 (CONFIG_PROC_VMCORE is set by default when CONFIG_CRASH_DUMP is selected.)
176
177 Dump-capture kernel config options (Arch Dependent, i386 and x86_64)
178 --------------------------------------------------------------------
179
180 1) On i386, enable high memory support under "Processor type and
181 features"::
182
183 CONFIG_HIGHMEM4G
184
185 2) With CONFIG_SMP=y, usually nr_cpus=1 need specified on the kernel
186 command line when loading the dump-capture kernel because one
187 CPU is enough for kdump kernel to dump vmcore on most of systems.
188
189 However, you can also specify nr_cpus=X to enable multiple processors
190 in kdump kernel.
191
192 With CONFIG_SMP=n, the above things are not related.
193
194 3) A relocatable kernel is suggested to be built by default. If not yet,
195 enable "Build a relocatable kernel" support under "Processor type and
196 features"::
197
198 CONFIG_RELOCATABLE=y
199
200 4) Use a suitable value for "Physical address where the kernel is
201 loaded" (under "Processor type and features"). This only appears when
202 "kernel crash dumps" is enabled. A suitable value depends upon
203 whether kernel is relocatable or not.
204
205 If you are using a relocatable kernel use CONFIG_PHYSICAL_START=0x100000
206 This will compile the kernel for physical address 1MB, but given the fact
207 kernel is relocatable, it can be run from any physical address hence
208 kexec boot loader will load it in memory region reserved for dump-capture
209 kernel.
210
211 Otherwise it should be the start of memory region reserved for
212 second kernel using boot parameter "crashkernel=Y@X". Here X is
213 start of memory region reserved for dump-capture kernel.
214 Generally X is 16MB (0x1000000). So you can set
215 CONFIG_PHYSICAL_START=0x1000000
216
217 5) Make and install the kernel and its modules. DO NOT add this kernel
218 to the boot loader configuration files.
219
220 Dump-capture kernel config options (Arch Dependent, ppc64)
221 ----------------------------------------------------------
222
223 1) Enable "Build a kdump crash kernel" support under "Kernel" options::
224
225 CONFIG_CRASH_DUMP=y
226
227 2) Enable "Build a relocatable kernel" support::
228
229 CONFIG_RELOCATABLE=y
230
231 Make and install the kernel and its modules.
232
233 Dump-capture kernel config options (Arch Dependent, arm)
234 ----------------------------------------------------------
235
236 - To use a relocatable kernel,
237 Enable "AUTO_ZRELADDR" support under "Boot" options::
238
239 AUTO_ZRELADDR=y
240
241 Dump-capture kernel config options (Arch Dependent, arm64)
242 ----------------------------------------------------------
243
244 - Please note that kvm of the dump-capture kernel will not be enabled
245 on non-VHE systems even if it is configured. This is because the CPU
246 will not be reset to EL2 on panic.
247
248 crashkernel syntax
249 ===========================
250 1) crashkernel=size@offset
251
252 Here 'size' specifies how much memory to reserve for the dump-capture kernel
253 and 'offset' specifies the beginning of this reserved memory. For example,
254 "crashkernel=64M@16M" tells the system kernel to reserve 64 MB of memory
255 starting at physical address 0x01000000 (16MB) for the dump-capture kernel.
256
257 The crashkernel region can be automatically placed by the system
258 kernel at run time. This is done by specifying the base address as 0,
259 or omitting it all together::
260
261 crashkernel=256M@0
262
263 or::
264
265 crashkernel=256M
266
267 If the start address is specified, note that the start address of the
268 kernel will be aligned to a value (which is Arch dependent), so if the
269 start address is not then any space below the alignment point will be
270 wasted.
271
272 2) range1:size1[,range2:size2,...][@offset]
273
274 While the "crashkernel=size[@offset]" syntax is sufficient for most
275 configurations, sometimes it's handy to have the reserved memory dependent
276 on the value of System RAM -- that's mostly for distributors that pre-setup
277 the kernel command line to avoid a unbootable system after some memory has
278 been removed from the machine.
279
280 The syntax is::
281
282 crashkernel=<range1>:<size1>[,<range2>:<size2>,...][@offset]
283 range=start-[end]
284
285 For example::
286
287 crashkernel=512M-2G:64M,2G-:128M
288
289 This would mean:
290
291 1) if the RAM is smaller than 512M, then don't reserve anything
292 (this is the "rescue" case)
293 2) if the RAM size is between 512M and 2G (exclusive), then reserve 64M
294 3) if the RAM size is larger than 2G, then reserve 128M
295
296 3) crashkernel=size,high and crashkernel=size,low
297
298 If memory above 4G is preferred, crashkernel=size,high can be used to
299 fulfill that. With it, physical memory is allowed to be allocated from top,
300 so could be above 4G if system has more than 4G RAM installed. Otherwise,
301 memory region will be allocated below 4G if available.
302
303 When crashkernel=X,high is passed, kernel could allocate physical memory
304 region above 4G, low memory under 4G is needed in this case. There are
305 three ways to get low memory:
306
307 1) Kernel will allocate at least 256M memory below 4G automatically
308 if crashkernel=Y,low is not specified.
309 2) Let user specify low memory size instead.
310 3) Specified value 0 will disable low memory allocation::
311
312 crashkernel=0,low
313
314 4) crashkernel=size,cma
315
316 Reserve additional crash kernel memory from CMA. This reservation is
317 usable by the first system's userspace memory and kernel movable
318 allocations (memory balloon, zswap). Pages allocated from this memory
319 range will not be included in the vmcore so this should not be used if
320 dumping of userspace memory is intended and it has to be expected that
321 some movable kernel pages may be missing from the dump.
322
323 A standard crashkernel reservation, as described above, is still needed
324 to hold the crash kernel and initrd.
325
326 This option increases the risk of a kdump failure: DMA transfers
327 configured by the first kernel may end up corrupting the second
328 kernel's memory.
329
330 This reservation method is intended for systems that can't afford to
331 sacrifice enough memory for standard crashkernel reservation and where
332 less reliable and possibly incomplete kdump is preferable to no kdump at
333 all.
334
335 Boot into System Kernel
336 -----------------------
337 1) Update the boot loader (such as grub, yaboot, or lilo) configuration
338 files as necessary.
339
340 2) Boot the system kernel with the boot parameter "crashkernel=Y@X".
341
342 On x86 and x86_64, use "crashkernel=Y[@X]". Most of the time, the
343 start address 'X' is not necessary, kernel will search a suitable
344 area. Unless an explicit start address is expected.
345
346 On ppc64, use "crashkernel=128M@32M".
347
348 On s390x, typically use "crashkernel=xxM". The value of xx is dependent
349 on the memory consumption of the kdump system. In general this is not
350 dependent on the memory size of the production system.
351
352 On arm, the use of "crashkernel=Y@X" is no longer necessary; the
353 kernel will automatically locate the crash kernel image within the
354 first 512MB of RAM if X is not given.
355
356 On arm64, use "crashkernel=Y[@X]". Note that the start address of
357 the kernel, X if explicitly specified, must be aligned to 2MiB (0x200000).
358
359 Load the Dump-capture Kernel
360 ============================
361
362 After booting to the system kernel, dump-capture kernel needs to be
363 loaded.
364
365 Based on the architecture and type of image (relocatable or not), one
366 can choose to load the uncompressed vmlinux or compressed bzImage/vmlinuz
367 of dump-capture kernel. Following is the summary.
368
369 For i386 and x86_64:
370
371 - Use bzImage/vmlinuz if kernel is relocatable.
372 - Use vmlinux if kernel is not relocatable.
373
374 For ppc64:
375
376 - Use vmlinux
377
378 For s390x:
379
380 - Use image or bzImage
381
382 For arm:
383
384 - Use zImage
385
386 For arm64:
387
388 - Use vmlinux or Image
389
390 If you are using an uncompressed vmlinux image then use following command
391 to load dump-capture kernel::
392
393 kexec -p <dump-capture-kernel-vmlinux-image> \
394 --initrd=<initrd-for-dump-capture-kernel> --args-linux \
395 --append="root=<root-dev> <arch-specific-options>"
396
397 If you are using a compressed bzImage/vmlinuz, then use following command
398 to load dump-capture kernel::
399
400 kexec -p <dump-capture-kernel-bzImage> \
401 --initrd=<initrd-for-dump-capture-kernel> \
402 --append="root=<root-dev> <arch-specific-options>"
403
404 If you are using a compressed zImage, then use following command
405 to load dump-capture kernel::
406
407 kexec --type zImage -p <dump-capture-kernel-bzImage> \
408 --initrd=<initrd-for-dump-capture-kernel> \
409 --dtb=<dtb-for-dump-capture-kernel> \
410 --append="root=<root-dev> <arch-specific-options>"
411
412 If you are using an uncompressed Image, then use following command
413 to load dump-capture kernel::
414
415 kexec -p <dump-capture-kernel-Image> \
416 --initrd=<initrd-for-dump-capture-kernel> \
417 --append="root=<root-dev> <arch-specific-options>"
418
419 Following are the arch specific command line options to be used while
420 loading dump-capture kernel.
421
422 For i386 and x86_64:
423
424 "1 irqpoll nr_cpus=1 reset_devices"
425
426 For ppc64:
427
428 "1 maxcpus=1 noirqdistrib reset_devices"
429
430 For s390x:
431
432 "1 nr_cpus=1 cgroup_disable=memory"
433
434 For arm:
435
436 "1 maxcpus=1 reset_devices"
437
438 For arm64:
439
440 "1 nr_cpus=1 reset_devices"
441
442 Notes on loading the dump-capture kernel:
443
444 * By default, the ELF headers are stored in ELF64 format to support
445 systems with more than 4GB memory. On i386, kexec automatically checks if
446 the physical RAM size exceeds the 4 GB limit and if not, uses ELF32.
447 So, on non-PAE systems, ELF32 is always used.
448
449 The --elf32-core-headers option can be used to force the generation of ELF32
450 headers. This is necessary because GDB currently cannot open vmcore files
451 with ELF64 headers on 32-bit systems.
452
453 * The "irqpoll" boot parameter reduces driver initialization failures
454 due to shared interrupts in the dump-capture kernel.
455
456 * You must specify <root-dev> in the format corresponding to the root
457 device name in the output of mount command.
458
459 * Boot parameter "1" boots the dump-capture kernel into single-user
460 mode without networking. If you want networking, use "3".
461
462 * We generally don't have to bring up a SMP kernel just to capture the
463 dump. Hence generally it is useful either to build a UP dump-capture
464 kernel or specify maxcpus=1 option while loading dump-capture kernel.
465 Note, though maxcpus always works, you had better replace it with
466 nr_cpus to save memory if supported by the current ARCH, such as x86.
467
468 * You should enable multi-cpu support in dump-capture kernel if you intend
469 to use multi-thread programs with it, such as parallel dump feature of
470 makedumpfile. Otherwise, the multi-thread program may have a great
471 performance degradation. To enable multi-cpu support, you should bring up an
472 SMP dump-capture kernel and specify maxcpus/nr_cpus options while loading it.
473
474 * For s390x there are two kdump modes: If an ELF header is specified with
475 the elfcorehdr= kernel parameter, it is used by the kdump kernel as it
476 is done on all other architectures. If no elfcorehdr= kernel parameter is
477 specified, the s390x kdump kernel dynamically creates the header. The
478 second mode has the advantage that for CPU and memory hotplug, kdump has
479 not to be reloaded with kexec_load().
480
481 * For s390x systems with many attached devices the "cio_ignore" kernel
482 parameter should be used for the kdump kernel in order to prevent allocation
483 of kernel memory for devices that are not relevant for kdump. The same
484 applies to systems that use SCSI/FCP devices. In that case the
485 "allow_lun_scan" zfcp module parameter should be set to zero before
486 setting FCP devices online.
487
488 Kernel Panic
489 ============
490
491 After successfully loading the dump-capture kernel as previously
492 described, the system will reboot into the dump-capture kernel if a
493 system crash is triggered. Trigger points are located in panic(),
494 die(), die_nmi() and in the sysrq handler (ALT-SysRq-c).
495
496 The following conditions will execute a crash trigger point:
497
498 If a hard lockup is detected and "NMI watchdog" is configured, the system
499 will boot into the dump-capture kernel ( die_nmi() ).
500
501 If die() is called, and it happens to be a thread with pid 0 or 1, or die()
502 is called inside interrupt context or die() is called and panic_on_oops is set,
503 the system will boot into the dump-capture kernel.
504
505 On powerpc systems when a soft-reset is generated, die() is called by all cpus
506 and the system will boot into the dump-capture kernel.
507
508 For testing purposes, you can trigger a crash by using "ALT-SysRq-c",
509 "echo c > /proc/sysrq-trigger" or write a module to force the panic.
510
511 Write Out the Dump File
512 =======================
513
514 After the dump-capture kernel is booted, write out the dump file with
515 the following command::
516
517 cp /proc/vmcore <dump-file>
518
519 or use scp to write out the dump file between hosts on a network, e.g::
520
521 scp /proc/vmcore remote_username@remote_ip:<dump-file>
522
523 You can also use makedumpfile utility to write out the dump file
524 with specified options to filter out unwanted contents, e.g::
525
526 makedumpfile -l --message-level 1 -d 31 /proc/vmcore <dump-file>
527
528 Analysis
529 ========
530
531 Before analyzing the dump image, you should reboot into a stable kernel.
532
533 You can do limited analysis using GDB on the dump file copied out of
534 /proc/vmcore. Use the debug vmlinux built with -g and run the following
535 command::
536
537 gdb vmlinux <dump-file>
538
539 Stack trace for the task on processor 0, register display, and memory
540 display work fine.
541
542 Note: GDB cannot analyze core files generated in ELF64 format for x86.
543 On systems with a maximum of 4GB of memory, you can generate
544 ELF32-format headers using the --elf32-core-headers kernel option on the
545 dump kernel.
546
547 You can also use the Crash utility to analyze dump files in Kdump
548 format. Crash is available at the following URL:
549
550 https://github.com/crash-utility/crash
551
552 Crash document can be found at:
553 https://crash-utility.github.io/
554
555 Trigger Kdump on WARN()
556 =======================
557
558 The kernel parameter, panic_on_warn, calls panic() in all WARN() paths. This
559 will cause a kdump to occur at the panic() call. In cases where a user wants
560 to specify this during runtime, /proc/sys/kernel/panic_on_warn can be set to 1
561 to achieve the same behaviour.
562
563 Trigger Kdump on add_taint()
564 ============================
565
566 The kernel parameter panic_on_taint facilitates a conditional call to panic()
567 from within add_taint() whenever the value set in this bitmask matches with the
568 bit flag being set by add_taint().
569 This will cause a kdump to occur at the add_taint()->panic() call.
570
571 Write the dump file to encrypted disk volume
572 ============================================
573
574 CONFIG_CRASH_DM_CRYPT can be enabled to support saving the dump file to an
575 encrypted disk volume (only x86_64 supported for now). User space can interact
576 with /sys/kernel/config/crash_dm_crypt_keys for setup,
577
578 1. Tell the first kernel what logon keys are needed to unlock the disk volumes,
579 # Add key #1
580 mkdir /sys/kernel/config/crash_dm_crypt_keys/7d26b7b4-e342-4d2d-b660-7426b0996720
581 # Add key #1's description
582 echo cryptsetup:7d26b7b4-e342-4d2d-b660-7426b0996720 > /sys/kernel/config/crash_dm_crypt_keys/description
583
584 # how many keys do we have now?
585 cat /sys/kernel/config/crash_dm_crypt_keys/count
586 1
587
588 # Add key #2 in the same way
589
590 # how many keys do we have now?
591 cat /sys/kernel/config/crash_dm_crypt_keys/count
592 2
593
594 # To support CPU/memory hot-plugging, re-use keys already saved to reserved
595 # memory
596 echo true > /sys/kernel/config/crash_dm_crypt_key/reuse
597
598 2. Load the dump-capture kernel
599
600 3. After the dump-capture kerne get booted, restore the keys to user keyring
601 echo yes > /sys/kernel/crash_dm_crypt_keys/restore
602
603 Contact
604 =======
605
606 - kexec@lists.infradead.org
607
608 GDB macros
609 ==========
610
611 .. include:: gdbmacros.txt
612 :literal:
613

3. 한국어 전문 번역

영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.

Kdump 개요와 메모리 보존 방식

1-59

Kdump: kexec 기반 크래시 덤프 솔루션

이 문서는 Kdump의 개요, 설정, 설치와 분석 정보를 제공합니다. Kdump는 시스템 커널의 메모리를 덤프해야 할 때, 예를 들어 시스템이 panic했을 때 `kexec`를 사용해 덤프 캡처 커널로 빠르게 부팅합니다. 재부팅하는 동안 시스템 커널의 메모리 이미지가 보존되며 덤프 캡처 커널에서 접근할 수 있습니다.

`cp`, `scp`, `makedumpfile` 같은 일반 명령으로 메모리 이미지를 로컬 디스크의 덤프 파일에 복사하거나 네트워크를 통해 원격 시스템으로 전송할 수 있습니다. Kdump와 kexec는 현재 x86, x86_64, ppc64, s390x, arm, arm64 아키텍처를 지원합니다.

시스템 커널은 부팅할 때 덤프 캡처 커널을 위한 작은 메모리 구간을 예약합니다. 이렇게 하면 시스템 커널에서 계속되는 DMA(Direct Memory Access)가 덤프 캡처 커널을 손상시키지 않습니다. `kexec -p` 명령은 이 예약 메모리에 덤프 캡처 커널을 적재합니다.

x86에서는 커널의 적재 위치와 관계없이 부팅에 물리 메모리의 첫 640 KB가 필요합니다. 처리를 단순하게 하고 이후 커널이나 장치 드라이버가 이 영역에 쓰는 일을 막기 위해 하위 1M 전체를 예약합니다. 그러면 Kdump 커널은 별도 처리 없이 하위 1M을 시스템 RAM으로 다시 사용할 수 있습니다.

PPC64에서는 커널 적재 위치와 관계없이 첫 32KB가 부팅에 필요하며, 64K 페이지 크기를 지원하기 위해 kexec가 첫 64KB 메모리를 백업합니다. s390x에서는 Kdump가 발동하면 crashkernel 영역을 `[0, crashkernel region size]` 구간과 교환하고 Kdump 커널이 그 구간에서 실행되므로 재배치 가능 커널이 필요하지 않습니다.

시스템 커널의 코어 이미지에 필요한 모든 정보는 ELF 형식으로 인코딩되어 크래시 전에 예약 메모리에 저장됩니다. ELF 헤더의 시작 물리 주소는 `elfcorehdr=` 부팅 매개변수로 덤프 캡처 커널에 전달합니다. `elfcorehdr=[size[KMG]@]offset[KMG]` 문법을 사용하면 ELF 헤더 크기도 선택적으로 전달할 수 있습니다.

덤프 캡처 커널에서는 `/proc/vmcore`를 통해 메모리 이미지에 접근합니다. 이 인터페이스는 덤프를 ELF 파일로 내보내므로 `cp`나 `scp`로 저장할 수 있습니다. `makedumpfile`은 내용을 분석하고 필터링해 저장할 수 있으며, 예를 들어 `-d 31`은 커널 데이터만 기록합니다. GNU Debugger(GDB)와 Crash 도구로 덤프 파일을 디버깅할 수도 있습니다. 이 방식은 덤프 페이지의 올바른 순서를 보장합니다.

kexec-tools 설치

60-105

다음 순서로 `kexec-tools` 사용자 공간 패키지를 설치합니다.

1. `root` 사용자로 로그인합니다.

2. 아래 URL에서 패키지를 내려받습니다. tarball URL은 최신 버전을 가리키는 심볼릭 링크입니다. 최신 Git 트리, gitweb 인터페이스와 프로젝트 정보도 아래 링크에서 확인할 수 있습니다.

3. tarball의 압축을 풉니다.

	tar xvpzf kexec-tools.tar.gz

4. `kexec-tools` 디렉터리로 이동합니다.

	cd kexec-tools-VERSION

5. 패키지를 구성합니다.

	./configure

6. 패키지를 컴파일합니다.

	make

7. 패키지를 설치합니다.

	make install

시스템 커널 빌드와 공통 설정

106-158

Kdump를 사용하는 방법은 두 가지입니다. 코어 덤프 수집 전용 커널을 별도로 빌드하거나, 시스템 커널 바이너리 자체를 덤프 캡처 커널로 사용합니다. 후자는 재배치 가능 커널을 지원하는 아키텍처에서만 가능하며 i386, x86_64, ppc64, arm, arm64가 이에 해당합니다.

재배치 가능 커널은 두 번째 커널을 따로 빌드하지 않아도 된다는 장점이 있습니다. 반면 필요한 기능만 넣은 맞춤형 덤프 캡처 커널을 원하는 경우에는 별도 빌드가 적합합니다.

1. `Processor type and features`에서 `kexec system call` 또는 `kexec file based system call`을 활성화합니다.

	CONFIG_KEXEC=y or CONFIG_KEXEC_FILE=y

두 옵션 모두 `KEXEC_CORE`를 선택합니다.

	CONFIG_KEXEC_CORE=y

2. `Filesystem` → `Pseudo filesystems`에서 보통 기본 활성화되는 `sysfs file system support`를 켭니다.

	CONFIG_SYSFS=y

`General Setup`의 `Configure standard kernel features (expert users)`가 꺼져 있으면 이 항목이 메뉴에 나타나지 않을 수 있습니다. 이 경우 `.config`를 직접 확인합니다.

	grep 'CONFIG_SYSFS' .config

3. `Kernel hacking`에서 `Compile the kernel with debug info`를 활성화합니다. 디버그 심벌을 포함한 `vmlinux`는 덤프 분석 도구가 덤프 파일을 읽고 분석하는 데 필요합니다.

	CONFIG_DEBUG_INFO=Y

덤프 캡처 커널 설정

159-219

아키텍처 공통 설정으로 `Processor type and features`의 `kernel crash dumps`를 활성화합니다.

	CONFIG_CRASH_DUMP=y

이 옵션은 `VMCORE_INFO`와 `CRASH_RESERVE`를 선택합니다.

	CONFIG_VMCORE_INFO=y
	CONFIG_CRASH_RESERVE=y

`Filesystems` → `Pseudo filesystems`에서 `/proc/vmcore support`를 활성화합니다. `CONFIG_CRASH_DUMP`를 선택하면 기본으로 설정됩니다.

	CONFIG_PROC_VMCORE=y

i386에서는 `Processor type and features`의 high memory 지원을 활성화합니다.

	CONFIG_HIGHMEM4G

`CONFIG_SMP=y`이면 대부분의 시스템에서 vmcore 덤프에 CPU 하나로 충분하므로 덤프 캡처 커널 명령줄에 보통 `nr_cpus=1`을 지정합니다. 여러 프로세서를 사용하려면 `nr_cpus=X`를 지정할 수 있습니다. `CONFIG_SMP=n`에는 해당하지 않습니다.

재배치 가능 커널을 기본으로 권장합니다. 아직 활성화하지 않았다면 `Processor type and features`에서 `Build a relocatable kernel`을 켭니다.

	CONFIG_RELOCATABLE=y

`Physical address where the kernel is loaded` 값은 커널의 재배치 가능 여부에 맞춰 정합니다. 재배치 가능 커널은 물리 주소 1MB용으로 컴파일해도 kexec가 덤프 캡처 예약 영역 어디든 적재할 수 있습니다.

   If you are using a relocatable kernel use CONFIG_PHYSICAL_START=0x100000

재배치할 수 없는 커널은 `crashkernel=Y@X`로 예약한 두 번째 커널 메모리의 시작 주소 X를 사용해야 합니다. X는 일반적으로 16MB(`0x1000000`)입니다.

   CONFIG_PHYSICAL_START=0x1000000

마지막으로 커널과 모듈을 빌드해 설치합니다. 이 커널은 부트 로더 구성 파일에 추가하지 마십시오.

PPC64, arm과 arm64 설정

220-247

PPC64에서는 `Kernel` 옵션의 `Build a kdump crash kernel`을 활성화합니다.

	CONFIG_CRASH_DUMP=y

이어서 `Build a relocatable kernel`을 활성화하고 커널과 모듈을 빌드해 설치합니다.

	CONFIG_RELOCATABLE=y

arm에서 재배치 가능 커널을 사용하려면 `Boot` 옵션의 `AUTO_ZRELADDR`을 활성화합니다.

	AUTO_ZRELADDR=y

arm64의 non-VHE 시스템에서는 덤프 캡처 커널에 KVM을 구성했더라도 활성화되지 않습니다. panic 시 CPU가 EL2로 재설정되지 않기 때문입니다.

crashkernel=size@offset 문법

248-271

`crashkernel=size@offset`에서 `size`는 덤프 캡처 커널을 위해 예약할 메모리 크기이고 `offset`은 예약 메모리의 시작입니다. 예를 들어 `crashkernel=64M@16M`은 물리 주소 `0x01000000`(16MB)부터 64 MB를 예약합니다.

기본 주소를 0으로 지정하거나 생략하면 시스템 커널이 런타임에 crashkernel 영역을 자동 배치합니다.

         crashkernel=256M@0
         crashkernel=256M

시작 주소를 명시하면 커널 시작 주소는 아키텍처별 정렬값에 맞춰집니다. 주소가 정렬되어 있지 않으면 다음 정렬 지점 아래의 공간은 낭비됩니다.

RAM 범위와 high/low 예약

272-313

`crashkernel=size[@offset]`은 대부분의 구성에 충분하지만, 배포판처럼 시스템 RAM 크기에 따라 예약량을 정해야 할 때는 범위 문법을 사용합니다. 메모리 제거 뒤 부팅 불능 상태를 피하도록 미리 커널 명령줄을 구성할 때 특히 유용합니다.

       crashkernel=<range1>:<size1>[,<range2>:<size2>,...][@offset]
       range=start-[end]

예시는 다음과 같습니다.

       crashkernel=512M-2G:64M,2G-:128M
시스템 RAM예약량
512M 미만아무것도 예약하지 않습니다. 복구(rescue) 경우입니다.
512M 이상 2G 미만64M을 예약합니다.
2G 이상128M을 예약합니다.

4G 위 메모리를 우선 사용하려면 `crashkernel=size,high`를 지정합니다. 물리 메모리를 위쪽부터 할당할 수 있어 RAM이 4G보다 많으면 4G 위에 놓일 수 있습니다. 이 옵션이 없으면 가능한 경우 4G 아래에 할당합니다.

`crashkernel=X,high`로 4G 위에 영역을 배치하면 4G 아래의 저메모리도 필요합니다. `crashkernel=Y,low`를 생략하면 커널이 4G 아래에 최소 256M을 자동 할당하며, 사용자가 크기를 지정할 수도 있습니다. 0을 지정하면 저메모리 할당을 끕니다.

            crashkernel=0,low

CMA 기반 추가 예약

314-334

`crashkernel=size,cma`는 CMA에서 추가 crash kernel 메모리를 예약합니다. 첫 번째 시스템의 사용자 공간과 커널의 이동 가능한 할당(memory balloon, zswap)이 이 영역을 사용할 수 있습니다.

이 메모리 범위에서 할당된 페이지는 vmcore에 포함되지 않습니다. 사용자 공간 메모리를 덤프해야 할 때는 사용하지 않아야 하며, 이동 가능한 일부 커널 페이지가 덤프에서 빠질 수 있음을 예상해야 합니다. crash kernel과 initrd를 담기 위한 표준 crashkernel 예약도 별도로 필요합니다.

첫 번째 커널이 설정한 DMA 전송이 두 번째 커널의 메모리를 손상시킬 수 있으므로 Kdump 실패 위험도 커집니다. 충분한 표준 예약 메모리를 희생할 수 없고, 신뢰성이 낮거나 불완전하더라도 덤프가 전혀 없는 것보다는 나은 시스템을 위한 방식입니다.

시스템 커널로 부팅

335-358

1. 필요에 따라 grub, yaboot, lilo 같은 부트 로더 구성 파일을 갱신합니다.

2. 시스템 커널을 `crashkernel=Y@X` 부팅 매개변수와 함께 시작합니다. x86과 x86_64에서는 `crashkernel=Y[@X]`를 사용하며, 명시적인 시작 주소가 꼭 필요한 경우가 아니면 커널이 적절한 영역을 찾으므로 X를 보통 생략합니다.

아키텍처권장 형식과 제약
ppc64`crashkernel=128M@32M`
s390x일반적으로 `crashkernel=xxM`을 사용합니다. xx는 운영 시스템 RAM 크기보다 Kdump 시스템의 메모리 소비량에 따라 정합니다.
armX를 생략하면 커널이 RAM의 첫 512MB 안에서 crash kernel 이미지를 자동 배치하므로 `crashkernel=Y@X`가 더는 필수가 아닙니다.
arm64`crashkernel=Y[@X]`를 사용합니다. X를 명시할 경우 2MiB(`0x200000`)에 맞춰 정렬해야 합니다.

덤프 캡처 커널 적재

359-440

시스템 커널로 부팅한 뒤 덤프 캡처 커널을 적재합니다. 아키텍처와 이미지의 재배치 가능 여부에 따라 압축하지 않은 `vmlinux` 또는 압축한 `bzImage`·`vmlinuz`를 선택합니다.

아키텍처이미지
i386, x86_64재배치 가능 커널은 `bzImage`/`vmlinuz`, 그렇지 않으면 `vmlinux`
ppc64`vmlinux`
s390x`image` 또는 `bzImage`
arm`zImage`
arm64`vmlinux` 또는 `Image`

압축하지 않은 `vmlinux` 이미지는 다음과 같이 적재합니다.

   kexec -p <dump-capture-kernel-vmlinux-image> \
   --initrd=<initrd-for-dump-capture-kernel> --args-linux \
   --append="root=<root-dev> <arch-specific-options>"

압축한 `bzImage` 또는 `vmlinuz`는 다음과 같이 적재합니다.

   kexec -p <dump-capture-kernel-bzImage> \
   --initrd=<initrd-for-dump-capture-kernel> \
   --append="root=<root-dev> <arch-specific-options>"

압축한 `zImage`는 다음과 같이 적재합니다.

   kexec --type zImage -p <dump-capture-kernel-bzImage> \
   --initrd=<initrd-for-dump-capture-kernel> \
   --dtb=<dtb-for-dump-capture-kernel> \
   --append="root=<root-dev> <arch-specific-options>"

압축하지 않은 `Image`는 다음과 같이 적재합니다.

   kexec -p <dump-capture-kernel-Image> \
   --initrd=<initrd-for-dump-capture-kernel> \
   --append="root=<root-dev> <arch-specific-options>"

덤프 캡처 커널을 적재할 때 사용할 아키텍처별 명령줄 옵션은 다음과 같습니다.

아키텍처명령줄 옵션
i386, x86_64`1 irqpoll nr_cpus=1 reset_devices`
ppc64`1 maxcpus=1 noirqdistrib reset_devices`
s390x`1 nr_cpus=1 cgroup_disable=memory`
arm`1 maxcpus=1 reset_devices`
arm64`1 nr_cpus=1 reset_devices`
	"1 irqpoll nr_cpus=1 reset_devices"
	"1 maxcpus=1 noirqdistrib reset_devices"
	"1 nr_cpus=1 cgroup_disable=memory"
	"1 maxcpus=1 reset_devices"
	"1 nr_cpus=1 reset_devices"

적재 시 주의 사항

441-487

기본적으로 4GB보다 큰 시스템을 지원하기 위해 ELF 헤더는 ELF64로 저장됩니다. i386의 kexec는 물리 RAM이 4GB를 넘는지 자동 확인하고, 넘지 않으면 ELF32를 사용합니다. 따라서 non-PAE 시스템은 항상 ELF32를 사용합니다.

`--elf32-core-headers`로 ELF32 헤더 생성을 강제할 수 있습니다. 현재 GDB가 32비트 시스템에서 ELF64 헤더의 vmcore를 열 수 없으므로 필요합니다.

`irqpoll` 부팅 매개변수는 덤프 캡처 커널의 공유 인터럽트 때문에 생기는 드라이버 초기화 실패를 줄입니다. `<root-dev>`는 `mount` 명령 출력의 루트 장치 이름과 같은 형식으로 지정해야 합니다.

부팅 매개변수 `1`은 네트워크 없이 단일 사용자 모드로 덤프 캡처 커널을 시작합니다. 네트워크가 필요하면 `3`을 사용합니다.

덤프 수집만을 위해 SMP 커널을 시작할 필요는 대개 없습니다. UP 덤프 캡처 커널을 빌드하거나 적재 시 `maxcpus=1`을 지정하는 것이 보통 유용합니다. `maxcpus`는 항상 동작하지만 x86처럼 현재 아키텍처가 지원한다면 메모리를 절약하도록 `nr_cpus`로 바꾸는 편이 낫습니다.

`makedumpfile`의 병렬 덤프처럼 다중 스레드 프로그램을 사용할 계획이라면 덤프 캡처 커널에서 다중 CPU 지원을 활성화해야 합니다. 그렇지 않으면 성능이 크게 저하될 수 있습니다. SMP 덤프 캡처 커널을 시작하고 적재할 때 `maxcpus`/`nr_cpus` 옵션을 지정합니다.

s390x에는 두 가지 Kdump 모드가 있습니다. `elfcorehdr=`를 지정하면 다른 아키텍처처럼 제공된 ELF 헤더를 사용합니다. 지정하지 않으면 s390x Kdump 커널이 헤더를 동적으로 만듭니다. 후자는 CPU나 메모리를 hotplug할 때 `kexec_load()`로 Kdump를 다시 적재하지 않아도 되는 장점이 있습니다.

장치가 많이 연결된 s390x에서는 Kdump와 무관한 장치에 커널 메모리를 할당하지 않도록 Kdump 커널에 `cio_ignore` 매개변수를 사용해야 합니다. SCSI/FCP 장치를 쓰는 시스템도 마찬가지이며, 이 경우 FCP 장치를 온라인으로 전환하기 전에 zfcp 모듈의 `allow_lun_scan`을 0으로 설정해야 합니다.

크래시 유발과 덤프 커널 재부팅

488-510

덤프 캡처 커널을 성공적으로 적재한 뒤 시스템 크래시가 발생하면 시스템이 그 커널로 재부팅됩니다. 트리거 지점은 `panic()`, `die()`, `die_nmi()`와 sysrq 처리기(`ALT-SysRq-c`)에 있습니다.

NMI watchdog이 구성된 상태에서 hard lockup을 탐지하면 `die_nmi()`를 통해 덤프 캡처 커널로 부팅합니다. `die()`가 PID 0 또는 1인 스레드에서 호출되거나 인터럽트 문맥에서 호출되거나 `panic_on_oops`가 설정된 상태에서 호출되어도 같은 동작을 합니다.

powerpc에서 soft-reset을 생성하면 모든 CPU가 `die()`를 호출하고 덤프 캡처 커널로 부팅합니다. 테스트할 때는 `ALT-SysRq-c`, `echo c > /proc/sysrq-trigger` 또는 panic을 강제하는 모듈로 크래시를 유발할 수 있습니다.

덤프 파일 저장

511-527

덤프 캡처 커널이 부팅된 뒤 다음 명령으로 덤프 파일을 저장합니다.

   cp /proc/vmcore <dump-file>

네트워크의 다른 호스트로 저장하려면 `scp`를 사용할 수 있습니다.

   scp /proc/vmcore remote_username@remote_ip:<dump-file>

`makedumpfile` 옵션으로 원하지 않는 내용을 필터링하면서 저장할 수도 있습니다.

   makedumpfile -l --message-level 1 -d 31 /proc/vmcore <dump-file>

덤프 분석

528-554

덤프 이미지를 분석하기 전에 안정적인 커널로 재부팅해야 합니다. `-g`로 빌드한 디버그용 `vmlinux`와 `/proc/vmcore`에서 복사한 덤프 파일을 사용하면 GDB로 제한적인 분석을 할 수 있습니다.

   gdb vmlinux <dump-file>

프로세서 0에서 실행되던 태스크의 스택 추적, 레지스터와 메모리 표시는 정상 동작합니다.

GDB는 x86에서 ELF64 형식으로 생성된 코어 파일을 분석할 수 없습니다. 메모리가 최대 4GB인 시스템은 덤프 커널의 `--elf32-core-headers` 옵션으로 ELF32 헤더를 만들 수 있습니다.

Crash 유틸리티도 Kdump 형식의 덤프 파일을 분석할 수 있습니다.

WARN과 taint에서 Kdump 유발

555-570

`panic_on_warn` 커널 매개변수는 모든 `WARN()` 경로에서 `panic()`을 호출하므로 그 지점에서 Kdump가 실행됩니다. 런타임에는 `/proc/sys/kernel/panic_on_warn`을 1로 설정해 같은 동작을 얻을 수 있습니다.

`panic_on_taint` 커널 매개변수는 설정한 비트마스크가 `add_taint()`가 설정하려는 비트 플래그와 일치할 때 `add_taint()` 내부에서 조건부로 `panic()`을 호출합니다. 따라서 `add_taint()->panic()` 지점에서 Kdump가 실행됩니다.

암호화 디스크 볼륨에 덤프 저장

571-602

`CONFIG_CRASH_DM_CRYPT`를 활성화하면 암호화 디스크 볼륨에 덤프 파일을 저장할 수 있습니다. 현재는 x86_64만 지원합니다. 사용자 공간은 `/sys/kernel/config/crash_dm_crypt_keys`를 통해 설정합니다.

1. 첫 번째 커널에 디스크 볼륨 잠금을 해제하는 데 필요한 logon key를 알립니다. 아래 예시는 두 키를 추가하고 현재 키 수를 확인한 뒤, CPU·메모리 hotplug를 지원하도록 예약 메모리에 이미 저장된 키를 재사용하게 합니다.

    # Add key #1
    mkdir /sys/kernel/config/crash_dm_crypt_keys/7d26b7b4-e342-4d2d-b660-7426b0996720
    # Add key #1's description
    echo cryptsetup:7d26b7b4-e342-4d2d-b660-7426b0996720 > /sys/kernel/config/crash_dm_crypt_keys/description

    # how many keys do we have now?
    cat /sys/kernel/config/crash_dm_crypt_keys/count
    1

    # Add key #2 in the same way

    # how many keys do we have now?
    cat /sys/kernel/config/crash_dm_crypt_keys/count
    2

    # To support CPU/memory hot-plugging, re-use keys already saved to reserved
    # memory
    echo true > /sys/kernel/config/crash_dm_crypt_key/reuse

2. 덤프 캡처 커널을 적재합니다.

3. 덤프 캡처 커널이 부팅되면 다음 명령으로 키를 사용자 keyring에 복원합니다.

   echo yes > /sys/kernel/crash_dm_crypt_keys/restore

연락처와 GDB 매크로

603-612

Kdump 관련 연락처는 `kexec@lists.infradead.org`입니다.

문서 끝에는 `gdbmacros.txt`를 literal 형식으로 포함합니다. 해당 파일은 별도 페이지에서 원문 전체와 한국어 해설을 제공합니다.

.. include:: gdbmacros.txt
   :literal: