On Tue, Jun 03, 2014 at 01:26:07PM +0530, Hari Bathini wrote:
The current kdump infrastructure builds a separate initrd which then
gets loaded into memory by kexec-tools for use by kdump kernel. But
firmware assisted dump (FADUMP) does not use kexec-based approach.
After crash, firmware reboots the partition and loads grub loader
like the normal booting process does. Hence in the FADUMP approach,
the second kernel (after crash) will always use the default initrd
(OS built). So, to support FADUMP, change is required, as in to add
dump capturing steps, in default initrd.
The current kdumpctl script implementation already has the code to
build initrd using mkdumprd. This patch uses the new '--rebuild'
option introduced, in dracut, to incrementally build the initramfs
image. A backup of default initrd image is taken before rebuilding
default initrd image with fadump support so as to restore it if this
operation fails.
Before rebuilding, we may need to probe the default initrd image for
fadump support, to avoid rebuilding the initrd image multiple times
unnecessarily. This can be done using "lsinitrd" tool with the newly
proposed '--mod' option & inspecting the presence of "kdumpbase"
in
the list of modules of default initrd image. We rebuild the image if
only "kdumpbase" module is missing in the default initrd image.
Kexec-tools package in rhel7 is now enhanced to insert a out-of-tree
kdump module for dracut, which is responsible for adding vmcore
capture steps into initrd, if dracut is invoked with "IN_KDUMP"
environment variable set to 1. mkdumprd script exports "IN_KDUMP=1"
environment variable before invoking dracut to build kdump initrd.
This patch relies on this current mechanism of kdump init script.
Patch that adds "--mod" option to lsinitrd tool is posted upstream,
awaiting approval. Link for reference:
http://www.spinics.net/lists/linux-initramfs/msg03670.html
Signed-off-by: Mahesh Salgaonkar <mahesh(a)linux.vnet.ibm.com>
Signed-off-by: Hari Bathini <hbathini(a)linux.vnet.ibm.com>
---
kdumpctl | 51 +++++++++++++++++++++++++++++++++++++++++++++++----
1 file changed, 47 insertions(+), 4 deletions(-)
diff --git a/kdumpctl b/kdumpctl
index e57aeff..e5d6d8d 100755
--- a/kdumpctl
+++ b/kdumpctl
@@ -146,17 +146,46 @@ function save_core()
fi
}
-function rebuild_initrd()
+rebuild_fadump_initrd()
{
- if [ $DUMP_MODE == "fadump" ]; then
- backup_default_initrd
+ if [ ! -s "$default_initrd" ]; then
+ echo "No default initrd found to rebuild for fadump support!"
+ return 1
Aagain, let us not differentiate between two initrd. We can just use
the term "No initrd found to rebuild".
And in the beginning we can output a string which says "Dump Mode is
fadump" (in determine_dump_mode()).
That way user is very clear that all the message are coming in fadump
context.
fi
+ backup_default_initrd
We could just call it backup_initrd() and pass the file name as
argument. Or this function could use target_initrd. IOW, using a single
name target_initrd to represent both the intird should work.
+
+ echo "Rebuilding $default_initrd with fadump support"
I think there is no need to say "with fadump support". A common message
"Rebuilding $target_initrd" should be just fine.
+ $MKDUMPRD --rebuild $default_initrd --kver $kdump_kver
+ if [ $? != 0 ]; then
+ echo "mkdumprd: failed to make initrd with fadump support" >&2
+ restore_default_initrd
I think directly writing to default image is not a good idea. What if
image is being built and power cable is pulled. We might have a half
built initrd image and system is unbootable.
We should first build image in a separate copy and upon successful
operation replace it with new one.
We seem to have this issue with kdump initrd also but it is less severe
as we don't use that initrd for regular boot.
I think rename(2) is the right thing to do here. But we don't seem to
have equivalent bash command version. rename(1) seems to be different.
Thanks
Vivek