Determine version of kernel that produced vmcore
Ken'ichi Ohmichi
oomichi at mxs.nes.nec.co.jp
Fri Jul 13 07:05:33 EDT 2007
Hi all,
2007/07/10 08:02:43 -0400, Neil Horman <nhorman at redhat.com> wrote:
>> Besides Dan's plan, I'm planning the change of CONFIGFILE for distributors.
>> In the kernel building process, distributors need to make CONFIGFILE
>> on an older kernel (ex. RHEL5 kernel is built on RHEL4), and OSRELEASE
>> may be an older kernel. So OSRELEASE should be modified to the building
>> kernel version by hand, but it is not smart.
>>
>> To solve this problem, I'm proposing 2 plans.
>> Could you give me your opinion ?
>>
>> Plan 1:
>> A new option [--osrelease="string"] is added.
>> The OSRELEASE of CONFIGFILE is overwritten by "string".
>> In the kernel building process, distributors should specify "string"
>> as the building kernel version.
>>
>> Plan2:
>> Remove the OSRELEASE from CONFIGFILE.
>> Instead of checking the OSRELEASE, makedumpfile only checks whether the
>> area of /proc/vmcore specified by the symbol "system_utsname" in CONFIGFILE
>> is the string "2.6.". If CONFIGFILE and /proc/vmcore don't match, the
>> "system_utsname" must not point to the correct area in most cases.
>> Old makedumpfile needs OSRELEASE, and it cannot work by new CONFIGFILE.
>> But I think there are not any problems because old makedumpfile will not
>> read new CONFIGFILE. Now, CONFIGFILE is used only by RHEL5's kdump initramfs,
>> the CONFIGFILE is generated during 1st-kernel running. Even if CONFIGFILE
>> will be updated, makedumpfile can read the CONFIGFILE because makedumpfile
>> should be updated with CONFIGFILE.
>>
>>
>> I'd like to change the name of CONFIGFILE to mkdfinfo.
>>
>Why not, instead of either plan above, just redefine OSRELEASE to be the version
>of the kernel the config file was built against? i.e. when you build a config
>file, you need to specify a kernel to extract symbol information from, why not
>grab the utsname from that kernel and use that to set OSRELEASE? When you're
>building a config file the running kernel on the system isn't really relevent
>anyway.
Did you say "makedumpfile should get OSRELEASE from a vmlinux file,
and output it to a mkdfinfo file", right ?
If so, you are right. I'm creating the patch for it.
BTW, I'd like to remove PAGESIZE from a mkdfinfo file.
While 2nd-kernel is running, new makedumpfile comes to consider
2nd-kernel PAGESIZE as 1st-kernel PAGESIZE without getting PAGESIZE
from a mkdfinfo file.
In current implementation, makedumpfile considers 2nd-kernel PAGESIZE
as 1st-kernel PAGESIZE if a vmlinux file is specified instead of a
mkdfinfo file. On the other hand, makedumpfile can get 1st-kernel
PAGESIZE correctly if a mkdfinfo file is specified, because there
is the rule that a mkdfinfo file should be generated on 1st-kernel.
Now, I will change this rule for generating a mkdfinfo file on the
kernel-building environment. I feel considering 2nd-kernel PAGESIZE
as 1st-kernel PAGESIZE is better than considering the PAGESIZE of
kernel-building environment, because 1st-kernel and 2nd-kernel have
the same PAGESIZE in most cases such as relocatable kernel.
Please let me know your opinion.
Thanks
Ken'ichi Ohmichi
More information about the kexec
mailing list