Re: Firmware assisted dump support in dracut

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

On 05/30/2013 07:53 PM, Vivek Goyal wrote:
> On Thu, May 30, 2013 at 08:49:07AM +0200, Harald Hoyer wrote:
> 
> [..]
>>> 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.
>>
> 
> I am not sure how well it will work in the context of kdump.  kdump
> options and original options might conflict. kdump might drop some of
> its own cmdline options in initramfs which might not make any sense
> in regular boot.
> 
> Kdump will specify additional mount points. IIUC, then we will try
> to bring up those targets in regular boot too and mount at user
> specified mount point. And later init services might get confused
> when respective daemon tries to bring up same targets again.

I think we should be able differentiate between regular boot and boot
after crash by checking existence of '/proc/vmcore' file, and do the
kdump specific configs/mount if this file exists. In regular boot we can
mute the kdump code path.

> 
> Thanks
> Vivek
>