From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mahesh Jagannath Salgaonkar Subject: Re: Firmware assisted dump support in dracut Date: Tue, 04 Jun 2013 13:50:19 +0530 Message-ID: <51ADA343.2070100@linux.vnet.ibm.com> References: <20121128161234.GA8991@in.ibm.com> <50B73598.804@redhat.com> <50C03971.4050104@linux.vnet.ibm.com> <51A6E0E4.1000502@linux.vnet.ibm.com> <51A6F663.5030804@redhat.com> <20130530142318.GC2864@redhat.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20130530142318.GC2864-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> Sender: initramfs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" To: Vivek Goyal Cc: Harald Hoyer , Initramfs Dracut , Ananth Narayan , Steven F Best , Haren Myneni 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 >