Re: Firmware assisted dump support in dracut

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Kernel]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux