On Tue, Jun 04, 2013 at 01:50:19PM +0530, Mahesh Jagannath Salgaonkar wrote: > 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. dracut takes --mount option and that option doesn not differentiate between environment. One can always create new options to mount certain things only in kdump environment. I am not sure how much sense does it make to try to special case everything related to kdump in dracut. Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
