config file -- OSRELEASE

Hi,

is there any reason why the kernel version saved in the configuration file is the version of the running kernel and not the version for which the config file is for?

It's a big problem because my plan was to ship the configuration files with the kernel RPMs in SLES.

However, we don't build the kernels on
systems which run the kernel that is just built -- so that's not possible.

I think from implementation point of view it's not a problem, that's why I ask and didn't create a patch.

Thanks,
Bernhard

is there any reason why the kernel version saved in the configuration file is the version of the running kernel and not the version for which the config file is for?

It's a big problem because my plan was to ship the configuration files with the kernel RPMs in SLES. However, we don't build the kernels on systems which run the kernel that is just built -- so that's not possible.

Quoted 3 lines · Bernhard Walle

is there any reason why the kernel version saved in the configuration file is the version of the running kernel and not the version for which the config file is for?

The reason is that makedumpfile gets a running kernel's page_size as a 1st-kernel's page_size. If they are different, makedumpfile cannot analyze /proc/vmcore and it fails. So I think a configuration file should be created while 1st-kernel is running.

Quoted 4 lines

It's a big problem because my plan was to ship the configuration files with the kernel RPMs in SLES. However, we don't build the kernels on systems which run the kernel that is just built -- so that's not possible.

It is a good idea to ship the configuration files with the kernel RPMs. I think you can do it with current implementation, because you need only one configuration file for one kernel image.

I think you can ship configuration files as follows:

1. Build a kernel file and a debuginfo file.
2. Boot the system with the above kernel file.
3. Generate a configration file from a debuginfo file.
4. Ship the configration file with the kernel RPM.

Any problem to follow the method above ?

Hello,

Quoted 9 lines · Ken'ichi Ohmichi

Quoted 3 lines · Bernhard Walle

is there any reason why the kernel version saved in the configuration file is the version of the running kernel and not the version for which the config file is for?

The reason is that makedumpfile gets a running kernel's page_size as a 1st-kernel's page_size. If they are different, makedumpfile cannot analyze /proc/vmcore and it fails. So I think a configuration file should be created while 1st-kernel is running.

I also didn't find a possibility to get the page size from a kernel image without running the executable.

Quoted 16 lines

Quoted 4 lines

It's a big problem because my plan was to ship the configuration files with the kernel RPMs in SLES. However, we don't build the kernels on systems which run the kernel that is just built -- so that's not possible.

It is a good idea to ship the configuration files with the kernel RPMs. I think you can do it with current implementation, because you need only one configuration file for one kernel image.

I think you can ship configuration files as follows:

1. Build a kernel file and a debuginfo file.
2. Boot the system with the above kernel file.
3. Generate a configration file from a debuginfo file.
4. Ship the configration file with the kernel RPM.

Quoted 1 line

Any problem to follow the method above ?

No, that's not possible because it would change our whole build process. However, I just replace the OSRELEASE now after generating the config file with the kernel that's built and change the page size according to the .config on IA64. That works for now. I know it's not the best solution, but the only practicable for now.

Quoted 32 lines · Ken'ichi Ohmichi

Quoted 9 lines

Quoted 3 lines · Bernhard Walle

is there any reason why the kernel version saved in the configuration file is the version of the running kernel and not the version for which the config file is for?

The reason is that makedumpfile gets a running kernel's page_size as a 1st-kernel's page_size. If they are different, makedumpfile cannot analyze /proc/vmcore and it fails. So I think a configuration file should be created while 1st-kernel is running.

I also didn't find a possibility to get the page size from a kernel image without running the executable.

Quoted 17 lines

Quoted 4 lines

It's a big problem because my plan was to ship the configuration files with the kernel RPMs in SLES. However, we don't build the kernels on systems which run the kernel that is just built -- so that's not possible.

It is a good idea to ship the configuration files with the kernel RPMs. I think you can do it with current implementation, because you need only one configuration file for one kernel image.

I think you can ship configuration files as follows:

1. Build a kernel file and a debuginfo file.
2. Boot the system with the above kernel file.
3. Generate a configration file from a debuginfo file.
4. Ship the configration file with the kernel RPM.

Any problem to follow the method above ?

Quoted 5 lines

No, that's not possible because it would change our whole build process. However, I just replace the OSRELEASE now after generating the config file with the kernel that's built and change the page size according to the .config on IA64. That works for now. I know it's not the best solution, but the only practicable for now.

Do we need more information in vmlinux to make it more amenable to automatic processing? version and page size for example.

Now, the items makedumpfile cannot get from vmlinux statically are only version and page size. Do you have any idea for getting them from vmlinux ?

Quoted 4 lines · Ken'ichi Ohmichi

Now, the items makedumpfile cannot get from vmlinux statically are only version and page size. Do you have any idea for getting them from vmlinux ?

I already tried to address a similar issue (version + command line length for kexec-tools) by adding a ELF note. But it seems that kernel hackers didn't like it.

http://article.gmane.org/gmane.comp.boot-loaders.fastboot.general/3996/.

Quoted 6 lines · Bernhard Walle

Quoted 4 lines · Ken'ichi Ohmichi

Now, the items makedumpfile cannot get from vmlinux statically are only version and page size. Do you have any idea for getting them from vmlinux ?

Quoted 5 lines

I already tried to address a similar issue (version + command line length for kexec-tools) by adding a ELF note. But it seems that kernel hackers didn't like it.

http://article.gmane.org/gmane.comp.boot-loaders.fastboot.general/3996/.

I'm not seeing the discussion there.

Looking at the patch I'm not quite certain of the composition of your notes.