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. 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. 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
