Hide Forgot
Currently, V7 just reported it as a warning when it detected this issue. In local test, lacking of enough space will fail the dump. How about raise it to an error? Belowing is a sample for currently log, you can find the whole log in https://hardware.redhat.com/results.cgi?cert_id=812425&id=249395: <snip> Rebuilding /boot/initrd-2.6.32-220.el6.x86_64kdump.img Warning: There is not enough space to save a vmcore. The size of /dev/sdb3 should be much greater than 396748852 kilo bytes. ..... reboot took 00:08:00 method: panic kernel: 2.6.32-220.el6.x86_64 Apr 13 09:41:00 sut40 kernel: Linux version 2.6.32-220.el6.x86_64 (mockbuild@x86-004.build.bos.redhat.com) (gcc version 4.4.5 20110214 (Red Hat 4.4.5-6) (GCC) ) #1 SMP Wed Nov 9 08:03:13 EST 2011 Apr 13 09:46:24 sut40 kernel: Linux version 2.6.32-220.el6.x86_64 (mockbuild@x86-004.build.bos.redhat.com) (gcc version 4.4.5 20110214 (Red Hat 4.4.5-6) (GCC) ) #1 SMP Wed Nov 9 08:03:13 EST 2011 Error: system rebooted 2 times Looking for vmcore image directories under /var/crash Error: could not locate vmcore file </snip>
This warning is from the kdump service when v7 restarts it after configuration changes. v7 would report this as an error if "service kdump start" returned non-zero. Also, it's a bit odd that 400 GB isn't enough for the image, unless kdump is mis-reporting the issue. The local kdump test successfully saved the image.
from kdump side, it's difficult to guess how much space would it take to save a compressed vmcore (using -d 31 option in makedumpfile), so kudmp just give a warning if the free disk space is not enough for saving a full, uncompressed vmcore. This means, saving vmcore still could be successful even if kdump gives this warning. In this case, vmcore not saved was unlikely due to no enough space, it's because "system rebooted 2 times" -- vmcore capture itself went wrong, it enters userspace. So, we need vendor to provide serial console log to dig into why kdump enters userspace. (grabbing this bug to my list since it's all about kdump + v7)
*** This bug has been marked as a duplicate of bug 815608 ***