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): diskdumputils-0.4.0-1 How reproducible: Always Steps to Reproduce: 1. Symbolic link /var/crash to a file system with less than 100MB free space left 2. Cause the kernel to panic (e.g. insmod ./crash.o as illustrated in /usr/share/doc/diskdump*/README.*) 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. Additional info:
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: /usr/share/doc/diskdumputils-0.4.0/README The script file itself is here: /usr/share/doc/diskdumputils-0.4.0/example_scripts/diskdump-nospace The usage is shown in the above script file. diskdump-nospace can clean up "/var/crash" by customizing. Thanks, Akira