On 06/04/2013 07:44 PM, Vivek Goyal wrote: > 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 > > Also what about kernel command line? Kernel command line can be very > specific to kdump environment. It is atleast in x86. I am hoping that's > not the case with firmware assisted dump. In fadump case, kernel command line is same as first kernel. > > Also can you point me to some writeup of fadump again. I want to refresh > what fadump is doing and how firmware is assisting and how does it make > better than regular kdump. It's at Documentation/powerpc/firmware-assisted-dump.txt in upstream kernel. > > I suspect it is very similar to s390 firmware dump (zfcpdump). Does > s390 kdump or s390 zfcpdump reboot after saving dump or they have > mechanism to continue to boot and hotplug memory after saving dump. I > am wondering how do they do it. > > CCing michael. > > 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