Re: [Crash-utility] After feedback on crash patch

----- Original Message ----- > Hi, > > I'd like to get crash changed to add a new option to the mod command > in crash. If you've got a dump server and you've got debuginfo RPMs > extracted for pretty much every RHEL/SLES release you can create a > symlink in the same directory as the vmcore pointing to the correct > namelist, for example: > > vmlinux -> /debuginfo/x86_64/rhel5/2.6.18-164/usr/lib/debug/lib/modules/2.6.18-164.el5/vmlinux > > I'd like to see the mod command automatically work out where the > debug modules will be based upon the result of realpath(3) on the > namelist then removing everything after /usr/lib/debug. I know that > there's the "--mod directory" option but you've got to remember to > run it all the time and if you've extracted the kernel debuginfo > crash can easily work out where they are if you use either a full or > relative path or symlink to the namelist. I don't know if anyone > would prefer to see it implemented in a different way but rather > than risk breaking something I didn't understand I added a new -t > option instead (-t because it's similar to -S and t is the next > available option after the letter s). > > I've run it on a few dumps and it seems to be working correctly. All > of the code changes are in kernel.c, help.c needed some changes just > to add the help text. Any feedback would be appreciated. > > Thanks > Shane It's a reasonable idea, but it seems that the eventual "tree" that is selected should be more restrictive. Here's what I mean... It works nicely using the setup that you describe: vmlinux -> /debuginfo/x86_64/rhel5/2.6.18-164/usr/lib/debug/lib/modules/2.6.18-164.el5/vmlinux So on my workstation, I set up a sample tree like so, where "mod -t" with CRASHDEBUG(3) shows this: REL namelist: vmlinux REL realpath: /tmp/mydebuginfos/usr/lib/debug/lib/modules/2.6.18-128.el5/vmlinux REL short path: /tmp/mydebuginfos/usr/lib/debug/ and it found the <module>.ko.debug files OK. But on an internal server, we have a directory structure like this: /cores/debuginfo/x86_64/usr/lib/debug/lib/modules And in that "modules" directory, there are dozens of "2.6.x" kernel version debuginfo trees. So taking one example using a symbolically linked vmlinux file, "mod -t" shows this: REL namelist: vmlinux REL realpath: /cores/debuginfo/x86_64/usr/lib/debug/lib/modules/2.6.32-220.2.1.el6.x86_64/vmlinux REL short path: /cores/debuginfo/x86_64/usr/lib/debug/ But unfortunately it just grabs whichever "<module>.ko.debug" it finds first -- which invariably comes from the wrong kernel version tree, because there are dozens of each <module>.ko.debug file to select from. If it used "/cores/debuginfo/x86_64/usr/lib/debug/lib/modules/2.6.32-220.2.1.el6.x86_64", as the "short path", then it would find the correct (only) <module>.ko.debug files. So would there be a problem in having the "short path" include the parent directory that contains the vmlinux file? We also compress the vmlinux files for space-saving. You might also test what happens when the local symbolic link is to a vmlinux.gz file, because pc->namelist will point to the uncompressed tmpname-generated file instead of back into the original tree. Thanks, Dave