Re: Firmware assisted dump support in dracut

[Vivek Goyal <vgoyal-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

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=
> 
> 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
> 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.

Thanks
Vivek