Re: Firmware assisted dump support in dracut

[Mahesh Jagannath Salgaonkar <mahesh-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>]

On 05/30/2013 12:19 PM, Harald Hoyer wrote:
> On 05/30/2013 07:17 AM, Mahesh Jagannath Salgaonkar wrote:
>> On 12/06/2012 11:51 AM, Mahesh Jagannath Salgaonkar wrote:
>>> On 11/29/2012 03:44 PM, Harald Hoyer wrote:
>>>> Am 28.11.2012 17:12, schrieb Mahesh J Salgaonkar:
>>>>> Hi Harald,
>>>>>
>>>>> Last year I worked on adding Firmware assisted dump (fadump) support in
>>>>> PowerLinux (ppc64). This feature is now accepted upstream Linux kernel and the
>>>>> documentation is available at http://lwn.net/Articles/488132/
>>>>>
>>>>> Like kdump, fadump also exports the memory dump through /proc/vmcore in ELF
>>>>> format. This enables us to reuse the existing kdump infrastructure for dump
>>>>> capture and filtering. However, unlike kdump, fadump does not use kexec-based
>>>>> approach, instead it depends on Power firmware to preserve the memory dump and
>>>>> reboot into new kernel. This is what happens in fadump after crash:
>>>>>
>>>>> 1. At the crash, kernel informs power firmware that kernel has crashed.
>>>>> 2. Firmware takes the control and reboots the entire system preserving only the
>>>>> memory (resets all other devices).
>>>>> 3. The reboot follows the normal booting process (non-kexec).
>>>>> 4. The boot loader loads the default kernel and initrd from /boot
>>>>>
>>>>> I am working on integrating fadump with existing kdump infrastructure. The
>>>>> current kdump infrastructure builds a separate initrd (whenever there is a
>>>>> change detected in kdump config file /etc/kdump.conf) which then gets loaded
>>>>> into memory by kexec tool for use by kdump kernel. But, in the fadump approach,
>>>>> the second kernel (after crash) always use the default (OS built) initramfs.
>>>>> Hence, to support fadump, change is required to introduce dump capturing steps
>>>>> in default initramfs itself. Hence the possible approaches I am looking into
>>>>> are:
>>>>>
>>>>> 1. Rebuild the default initramfs every time when there is a change detected in
>>>>> kdump config file (/etc/kdump.conf)
>>>>>    This approach would modify existing initramfs in place. I did work on this
>>>>>    approach by enhancing mkdumprd (tool from kexec-tools package) to extract
>>>>>    and rebuild default initramfs with dump capturing steps.  After discussing
>>>>>    with Vivek Goyal, he suggested that better approach to add code to dracut
>>>>>    for rebuilding boot initramfs instead of enhancing mkdumprd.  This means
>>>>>    introducing a new dracut module that will be responsible for introducing
>>>>>    dump capture steps inside the rebuilt initramfs by pulling required modules
>>>>>    e.g. ssh, nfs etc. depending on /etc/kdump.conf
>>>>>
>>>>>    Now the question is whether it is possible for dracut to rebuild boot
>>>>>    initramfs in place? if Yes, is there any issues in rebuilding of boot
>>>>>    initramfs everytime when there is a change in /etc/kdump.conf?
>>>>
>>>> dracut is called by /sbin/new-kernel-package. dracut is not a service, which is
>>>> run on every boot. So, no, dracut can't watch files and build an initramfs on
>>>> itsself.
>>>>
>>>
>>> Normally user would restart kdump service after changing kdump config
>>> file. Idea is to invoke dracut through kdump service, as it already
>>> watches and detect changes in kdump config files.
>>>
>>> I was wondering if dracut allow us to insert/install additional dracut
>>> modules to already existing initramfs? OR does it rebuild initramfs all
>>> over again?
>>
>> Sorry for restarting this discussion very late. I would like to know how
>> safe is to rebuild kernel's default (boot) initramfs for an already
>> installed kernel ?
>>
>> Also, Does dracut provides any of following mechanism?
>> a) Mechanism where dracut can detect what options were used during first
>> build for a given (exsisting) initramfs. (This mechanism may help one to
>> regenerate similar initramfs with additional dracut modules.)
> 
> currently dracut only stores which modules were used to generate the image in
> usr/lib/dracut/modules.txt
> 
> But yes, you are right. Would be nice to save all the options and have a
> mechanism to regenerate it with those.
> 
>>
>> OR
>>
>> b) Add additional modules to an existing initramfs instead of
>> regenerating again. Is this possible at all?
> 
> You can always generate a second cpio image with additional files and either
> concatenate both images or specify those two images in the bootloader.

Is it possible to specify two images to bootloader for a single kernel
entry? Does grub2 support it?

> 
> OR
> 
> unpack the initramfs, add the file, (maybe run depmod, if kernel driver added),
> and repack.
>