Re: Firmware assisted dump support in dracut

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

On 06/05/2013 09:23 PM, Vivek Goyal wrote:
> On Wed, Jun 05, 2013 at 10:55:04AM -0400, Vivek Goyal wrote:
> 
> [..]
>>>> If first kernel and kdump kernel command line are same in fadump and
>>>> boot environment is same, I think it is worth exploring the option
>>>> of saving kdump from kdump service when system boots back. That will
>>>> do away with any need to tweak initramfs.
>>>
>>> This needs larger memory to be reserved. We may need to make sure that
>>> kdump service is invoked at very early stage before other services kicks
>>> in which may start requesting for memory and run into OOM issue. If we
>>> can make sure that no other services are invoked when kdump service is
>>> saving dump then it will help to fix the size of reserved memory. The
>>> systemd infrastructure provides aggressive parallelization capabilities.
>>> I am not expert on systemd but will need to explore whether with systemd
>>> is this possible.
>>
>> I think we can create a new service for saving dump and make some of
>> the systemd services dependent on start of this service. 
>>
>> Can't integrate with existing kdump service as that one can start
>> later and can take time in regenerating initramfs and holding back other
>> services for that duration will not make sense.
>>
>> By creating a seprate service, delay will be introduced only when there
>> s dump to be saved. Before this we will have bring up all networking
>> and storage in the system so that we can save dump to intended target.
>>
>> I think same service can be used to save dump from inside initramfs
>> too. (As systemd is now started inside initramfs too). 
>>
>> Other appraoch is dumping through initramfs and if you do things
>> conditionally (if dump is available), then any dracut parameter
>> used by kdump will have to have a conditional version too. Something
>> like
>>
>> mount=
>> mount.kdump_only=

Agree. The kdump_only options can be used to store the kdump related
required configs (e.g. lvm configs, network configs etc.) in a separate
directory and add a pre-udev hook that can check if dump is available
and move these configs to their original paths so that the normal
initramfs flow will do its job as per configs.

>>
>> mount.kdump_only will kick in only dump is available. Also we need to
>> make sure that effects of all kdump_only options are undone before
>> root is mounted or we create nice handover mechanism to systemd. I think

Agree.

>> there handover mechanism already between initramfs and systemd for complex
>> storage targets like multipathd.
>>
>> I will let harald comment on what does he think of kdump_only variant
>> options.
> 
> Thinking more about it, I think from kdump point of view, it is better
> to be able to dump from initrafs. We don't want different mechanism
> for different architecture which will result in more confusion and
> possibly code duplication.
> 

Agree. And if we rely on dracut to rebuild the initramfs (with original
dracut arguments) we can be sure that we wont run into issues like
unbootable system.

Thanks,
-Mahesh.