Created attachment 461159 [details] gzip compressed traces from an attempt to use /sbin/mkdumprd Description of problem: After fixing for an umpteenth time bug 635893, just to get anywhere instead of immediately starting an inifinite loop (why this still lingers unfixed?), an attempt to use /sbin/mkdumprd from kexec-tools-2.0.0-41.fc15 gets into another infinite loop. This time when going through kernel modules. While trying to trace that shell script /sbin/mkdumprd a 10 minutes wait produced 123M of trace but this was not getting any closer to a desired kdump image. Trying to grep, for example, in this trace for a pattern: ' echo /lib/modules/2.6.36-1.fc15.x86_64/kernel/.*nat' produced 296 lines. Seems tad excessive. Similar with other cases. An attempt to boot a new kernel with a service kdump active simply gets stuck. Version-Release number of selected component (if applicable): kexec-tools-2.0.0-41.fc15 How reproducible: Every time.
Its pointless to open a new bug that does nothing but gripe, please don't waste your time or mine. bz 635893 is open to track this, and I'll get to it when I can. *** This bug has been marked as a duplicate of bug 635893 ***
(In reply to comment #1) > Its pointless to open a new bug that does nothing but gripe, In case you failed to notice, despite that I wrote explicitely "another infinite loop", this looks like a new bug. The problem in bug 635893 is an infinite loop but not the same one and whatever you can find in comments there does not fix a loop from _this_ report. If I would have a patch for that one I would attach it but I got lost in this huge trace and I do not know what really changed. I did not try very long but I failed to work around here. It is up to you where you want to track it but I was told a number of times that different bugs should NOT be conflated in the same report. I am not sure what "nothing but gripe" refers too.