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? > Of course such a service could be created and create the initramfs on shutdown, > if any of the files, which should be watched, have changed. > > This of course is a dangerous automatism, which might as well lead to a > unbootable system. Further steps (with grubby) would have to make sure, the last > bootable entry is still there, along with the last kernel version. > > I was already thinking about creating such a monster, but this would involve to > reinvent the current /sbin/new-kernel-package / grubby infrastructure, which has > to be done anyway in the next years. The first step was to create a common > configuration file format for all the bootloaders, which they parse and display. > > http://harald.fedorapeople.org/downloads/boot-unification.pdf > A simple boot manager parsing the config layout as a reference implementation: > http://freedesktop.org/wiki/Software/gummiboot > > Next step is to patch grub2 to parse those config files and display the menu > entries. I think once such a infrastructure exists, things would be much easier. Also, would it be possible to make such a infrastructure OS crash aware, so that it can load different initramfs in crash scenario and default initramfs in a normal boot process. I am not sure how practical this idea would be to implement. > > Next step is to enhance /sbin/new-kernel-package and obsolete grubby. > > Then, I think we are ready to create such a service. > >> >> 2. Make dracut tool fadump aware and it will build fadump aware initrd (default >> OS initrd) during kernel install. Once built, this initrd should never be >> rebuilt again. Which means the default initramfs will contain vmcore capture >> steps. This approach would pack all possible dracut modules (nfs, ssh, bonding >> etc.) so that the default initrd will be capable of supporting all possible >> dump target. Hence this approach will bloat the initramfs. On my Power test >> system, the size of the default initrd generated without any changes is 16M. >> With the above approach this size jumps to 27M. > > Yeah, this is crazy. > >> >> Since both the above approaches would require changes to dracut package, I would >> like to know your views on above approaches. >> >> Thanks, >> -Mahesh. >> > > -- > 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
