Red Hat Bugzilla – Bug 153957
diskdump partition got re-initilized during machine boot up if /var/crash does not have enough space to store vmcore
Last modified: 2007-11-30 17:07:06 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
Description of problem:
diskdump partition got re-initilized during machine boot up if /var/crash does not have enough space to store vmcore. As a result, the most recent kernel coredump stored in the diskdump partition is lost.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Symbolic link /var/crash to a file system with less than 100MB free space
2. Cause the kernel to panic (e.g. insmod ./crash.o as illustrated in
3. After the incore image has been dumped to pre-defined diskdump partition,
restart the machine.
Actual Results: During bootup, error message would indicate not enough
space has been detected in /var/crash and yet the diskdump partition still got re-initialized right afterwards
Expected Results: If /var/crash does not have enough space, it should report error and skip the re-initialization step. This way, system administrator can clean up /var/crash and use "savecore" to save vmcore into /var/crash afterwards. Or else, the core from the most recent kernel panic is lost forever.
This is not a bug. This is a deliberate action that device is reformatted even
if savecore fails. This means that diskdump is always available because
diskdump formats a device when diskdump starts. Please use a script file
called diskdump-nospace in order to avoid the problem mentioned above.
A description of diskdump-nospace is here:
The script file itself is here:
The usage is shown in the above script file. diskdump-nospace can clean
up "/var/crash" by customizing.