В Tue, 04 Jun 2013 14:04:51 +0530 Mahesh Jagannath Salgaonkar <mahesh@xxxxxxxxxxxxxxxxxx> пишет: > On 05/30/2013 12:19 PM, Harald Hoyer wrote: > > On 05/30/2013 07:17 AM, Mahesh Jagannath Salgaonkar wrote: > >> On 12/06/2012 11:51 AM, Mahesh Jagannath Salgaonkar wrote: > >>> On 11/29/2012 03:44 PM, Harald Hoyer wrote: > >>>> Am 28.11.2012 17:12, schrieb Mahesh J Salgaonkar: > >>>>> Hi Harald, > >>>>> > >>>>> Last year I worked on adding Firmware assisted dump (fadump) support in > >>>>> PowerLinux (ppc64). This feature is now accepted upstream Linux kernel and the > >>>>> documentation is available at http://lwn.net/Articles/488132/ > >>>>> > >>>>> Like kdump, fadump also exports the memory dump through /proc/vmcore in ELF > >>>>> format. This enables us to reuse the existing kdump infrastructure for dump > >>>>> capture and filtering. However, unlike kdump, fadump does not use kexec-based > >>>>> approach, instead it depends on Power firmware to preserve the memory dump and > >>>>> reboot into new kernel. This is what happens in fadump after crash: > >>>>> > >>>>> 1. At the crash, kernel informs power firmware that kernel has crashed. > >>>>> 2. Firmware takes the control and reboots the entire system preserving only the > >>>>> memory (resets all other devices). > >>>>> 3. The reboot follows the normal booting process (non-kexec). > >>>>> 4. The boot loader loads the default kernel and initrd from /boot > >>>>> > >>>>> I am working on integrating fadump with existing kdump infrastructure. The > >>>>> current kdump infrastructure builds a separate initrd (whenever there is a > >>>>> change detected in kdump config file /etc/kdump.conf) which then gets loaded > >>>>> into memory by kexec tool for use by kdump kernel. But, in the fadump approach, > >>>>> the second kernel (after crash) always use the default (OS built) initramfs. > >>>>> Hence, to support fadump, change is required to introduce dump capturing steps > >>>>> in default initramfs itself. Hence the possible approaches I am looking into > >>>>> are: > >>>>> > >>>>> 1. Rebuild the default initramfs every time when there is a change detected in > >>>>> kdump config file (/etc/kdump.conf) > >>>>> This approach would modify existing initramfs in place. I did work on this > >>>>> approach by enhancing mkdumprd (tool from kexec-tools package) to extract > >>>>> and rebuild default initramfs with dump capturing steps. After discussing > >>>>> with Vivek Goyal, he suggested that better approach to add code to dracut > >>>>> for rebuilding boot initramfs instead of enhancing mkdumprd. This means > >>>>> introducing a new dracut module that will be responsible for introducing > >>>>> dump capture steps inside the rebuilt initramfs by pulling required modules > >>>>> e.g. ssh, nfs etc. depending on /etc/kdump.conf > >>>>> > >>>>> Now the question is whether it is possible for dracut to rebuild boot > >>>>> initramfs in place? if Yes, is there any issues in rebuilding of boot > >>>>> initramfs everytime when there is a change in /etc/kdump.conf? > >>>> > >>>> dracut is called by /sbin/new-kernel-package. dracut is not a service, which is > >>>> run on every boot. So, no, dracut can't watch files and build an initramfs on > >>>> itsself. > >>>> > >>> > >>> Normally user would restart kdump service after changing kdump config > >>> file. Idea is to invoke dracut through kdump service, as it already > >>> watches and detect changes in kdump config files. > >>> > >>> I was wondering if dracut allow us to insert/install additional dracut > >>> modules to already existing initramfs? OR does it rebuild initramfs all > >>> over again? > >> > >> 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. > > > >> > >> OR > >> > >> b) Add additional modules to an existing initramfs instead of > >> regenerating again. Is this possible at all? > > > > You can always generate a second cpio image with additional files and either > > concatenate both images or specify those two images in the bootloader. > > Is it possible to specify two images to bootloader for a single kernel > entry? Does grub2 support it? > Yes, it does. You can use initrd file1 file2 ... And it will concatenate files. It aligns files on 4 bytes boundary, not sure whether it can be a problem. > > > > OR > > > > unpack the initramfs, add the file, (maybe run depmod, if kernel driver added), > > and repack. > > > > -- > 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 -- 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
