On Tue, Jun 08, 2010 at 02:52:52PM -0400, Peter Jones wrote: > On 06/08/2010 02:46 PM, Bill Nottingham wrote: > > Dave Jones (davej@xxxxxxxxxx) said: > >> - kdump is kind of a disaster, it's never worked in fedora afair. > >> jarod was poking at it from a rhel context, but I doubt he has the time to maintain > >> it fulltime in fedora. lets just drop it all ? > > ... > >> - there's no more mkinitrd in f14, so dracut or gtfo ? > > > > Actually, why can't/shouldn't the kdump stuff use dracut? > > It absolutely should if we keep it at all. > We have an additional config mechansim that uses dracut thats partially complete. I've been meaning to finish it forever, but have never gotten around to it, because there was always something higher priority in the way in making kexec function on RHEL. As for keeping it, lets clarify what exactly we're talking about here: the kexec bits in the spec file that Dave is referring to are completely useless now, yes, and can be removed. but the kexec-tools package and the kdump infrastructure that goes with it does work in several cases. Its broken in alot of cases (mostly because no one tests it, I've gotten 36 legitimate kexec bugs in fedora since Fedora 7, most of those from partners who opened them at the same time as a corresponding RHEL bug). But it does work in several use cases, and can work in more if we have the users to test them, and the time to fix issues they report. So, what exactly are we talking about here Dave: removing the kexec bits from the kernel spec file, or the entire user space package? I vote yes to the former, and absolutely not to the latter. Neil _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel