https://bugzilla.novell.com/show_bug.cgi?id=300124#c3 --- Comment #3 from Olaf Dabrunz 2007-08-28 11:38:57 MST --- When is this function called? During installation, or in the running system? If during the installation, when during the installation workflow is it called? Please attach a y2log. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=300124#c4 --- Comment #4 from Bernhard Walle 2007-08-28 12:10:18 MST --- (In reply to comment #3 from Olaf Dabrunz)

When is this function called? During installation, or in the running system?

The kdump module is only called in the running system. You can just rpm -i yast2-kdump and then execute "yast kdump". When you select "enable kdump" and save the settings, the command line parameter is added. (Don't remove the NEEDINFO flag because Jozef should provide Yast logs.) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=300124#c6 --- Comment #6 from Bernhard Walle 2007-08-28 13:24:39 MST --- Thanks for taking care about that issue. (In reply to comment #5 from Olaf Dabrunz)

Also, please note that

Bootloader::setKernelParam (Bootloader::getDefaultSection (), "crashkernel", crash_value);

will set this parameter on the default section, which may be any section, e.g. containing a XEN kernel or even memtest86 or any other kernel of the user's choice.

That's a good point, IMO. Because we're talking about servers here mostly it's not that critical as for desktop installations where a huge amount of users might have Windows as default. ;) Some solutions I could imagine: - Change the command line of the active kernel. The only problem is that it's not really possible to get out the current kernel. Do some boot loaders have support for this? It's possible to implement something like function get_entry(): current_version = shell("uname -r") current_cmdline = read("/proc/cmdline") for entry in get_all_entries(): filename = entry.get_kernel() version = shell("/sbin/get_kernel_version " . filename) if version == current_version and \ entry.get_commandline() == current_cmdline: return entry return None It's no problem if the kernel is on an un-mounted partition because then it's the wrong kernel. (Yes, I know, when root is set to a /boot partition then the path is wrong etc.) But this is not really easy to implement, I think. - Present the user a list of boot entries and let the user decide which kernel he wants to enable. That would also make it possible for the user to enable Kdump for multiple kernels. - Only present a text message that explains that the user must add the string "crashkernel....." and then start yast bootloader and let the user do it manually. That might be a intermediate solution for 10.3, but I'm quite sure that this is nothing for SLES 11.

bwalle@, what happens if the user removes RAM from the system so that a previously set "crashkernel" value would need to allocate too much RAM during next boot and the system cannot start up? Does the kernel ignore this value then, does it stop booting or does it crash?

Also a good point. ;) At first, this is architecture specific. Reserving the memory is done in architecutre specific code -- different architectures behave even different when parsing the command line - PPC64 ignores the offset and always takes 16M - IA64 as architecture with a relocatable kernel since ages can guess an offset ... I only tested this on x86_64 by accident, so I cannot talk about all possible archs. There are two cases 1. The reserved value es larger or the same as the system memory. Then the kernel crashes at boot with some obscure error. 2. There's some (but too small) memory for the kernel/system. Then the system behaves just as if you try to boot a full features SUSE Linux with 16 MiB of RAM ... But this is nothing unchangable. I could try to prepare a patch that handles the case better. At least the first case with presenting a clear error message what to do or to just ignore the memory reservation and printing a message in the kernel log. But the 2nd case is more difficult. It would imply to make policy decisions in kernel space. I don't think that something like "make it impossible to reserve more as 50 % of system RAM for crashkdump" gets accepted upstream. However, in general I think the case where the user removes that much memory is very rare. Note that we don't talk about "Ließchen Müller" that uses kdump on the laptop but mostly Enterprise server users. I'll work on the first issue as soon as time permits, though. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=300124#c9 --- Comment #9 from Olaf Dabrunz 2007-08-31 06:17:34 MST --- For now, that sounds like a way to go. And I agree that we need to have a selection dialog in the future. Here is a write-up of the results we had so far, after a phone-conference with Bernhard Walle and an IRC-conference with Jozef Uhliarik, with some odds and ends added by myself (since I was at it), for future reference: (In reply to comment #6 from Bernhard Walle)

...

Also, please note that

Bootloader::setKernelParam (Bootloader::getDefaultSection (), "crashkernel", crash_value);

will set this parameter on the default section, which may be any section, e.g. containing a XEN kernel or even memtest86 or any other kernel of the user's choice.

That's a good point, IMO. Because we're talking about servers here mostly it's not that critical as for desktop installations where a huge amount of users might have Windows as default. ;) Some solutions I could imagine:

- Change the command line of the active kernel. The only problem is that it's not really possible to get out the current kernel. Do some boot loaders have support for this?

It's possible to implement something like

[deleted for brevity: code that tries to find the currently running kernel in the bootloader configuration by comparing kernel version and commandline -- the code seems to be used now in yast2-kdump]

It's no problem if the kernel is on an un-mounted partition because then it's the wrong kernel. (Yes, I know, when root is set to a /boot partition then the path is wrong etc.)

But this is not really easy to implement, I think.

This algorithm is a start. We had to solve a similar problem in perl-Bootloader. Here is the idea of that algorithm: To find the correct section, find out whether the kernel matches the version and flavour of the running one, and check that the device in the section is the one from which the kernel in the section is actually mounted in the currently running system. - Compare the full filename of the kernel (<name>-<version>-<flavour>) with the filename in bootloader configuration section -- in yast2-kdump, it may be sufficient to compare only the <version>-<flavour> part. - Find out whether the device in the "root" parameter is mounted in the current system (i.e., it belongs to the currently running installation), and the kernel file given with a full path in the "image" parameter is actually on that device (check with "stat -c %d <kernel>" against "stat -c '%t %t' <device>"). For this, you could use the section data in the configuration data provided by Bootloader::Export(). This is not recommended though, because so far this is not intended as a stable interface to section data. A better solution would be to have an interface in the Bootloader:: frontend. Also, the GetSectionOfCurrentlyRunningKernel() functionality sounds like something other modules may find useful as well. So probably it makes sense to put the above algorithm into yast2-bootloader, where it could be maintained. In this case, the only other interface that seems to be needed for a section selection in yast2-kdump is Bootloader::GetSectionNames(). Comparing the kernel commandline from "/proc/cmdline" with the ones in the sections will only work in some cases. Some options that can be found in the bootloader configuration may disappear and not show up in "/proc/cmdline". Jozef Uhliarik found that e.g. "showopts" disappears on his system. Also, the user may add options (manually) during boot. In effect, this makes the comparison of the kernel options too unreliable to be useful. Also, a kernel options comparison will rarely improve the results of the heuristic algorithm that I presented above. The above algorithm only fails when a second kernel with the same <version>-<flavour> is installed on the system. Then the algorithm will find one of them, but it may not be the currently running one. Given that all our kernels have a different <version>-<flavour>, we will not encounter this problem with our kernels. For user-compiled kernels the default is to create a different <version> as compared to the SUSE kernels, and the user anyway needs to take care to change the EXTRAVERSION in the kernel Makefile if he wants to build and install multiple kernels with the help of the kernel build system. No big problem there as well. So I believe we should make the above algorithm a feature for 11.0 / SLES11, to be implemented in yast2-bootloader and used in yast2-kdump as described.

- Present the user a list of boot entries and let the user decide which kernel he wants to enable. That would also make it possible for the user to enable Kdump for multiple kernels.

Right. (I have included the text for this above, to make it more readable.)

- Only present a text message that explains that the user must add the string "crashkernel....." and then start yast bootloader and let the user do it manually. That might be a intermediate solution for 10.3, but I'm quite sure that this is nothing for SLES 11.

Yep. In the meantime, it seems we have a better intermediate solution. So next we might go for the "good" solution.

...

bwalle@, what happens if the user removes RAM from the system so that a previously set "crashkernel" value would need to allocate too much RAM during next boot and the system cannot start up? Does the kernel ignore this value then, does it stop booting or does it crash?

Also a good point. ;)

At first, this is architecture specific. Reserving the memory is done in architecutre specific code -- different architectures behave even different when parsing the command line

- PPC64 ignores the offset and always takes 16M - IA64 as architecture with a relocatable kernel since ages can guess an offset ...

I only tested this on x86_64 by accident, so I cannot talk about all possible archs. There are two cases

1. The reserved value es larger or the same as the system memory. Then the kernel crashes at boot with some obscure error.

2. There's some (but too small) memory for the kernel/system. Then the system behaves just as if you try to boot a full features SUSE Linux with 16 MiB of RAM ...

But this is nothing unchangable. I could try to prepare a patch that handles the case better. At least the first case with presenting a clear error message what to do or to just ignore the memory reservation and printing a message in the kernel log.

But the 2nd case is more difficult. It would imply to make policy decisions in kernel space. I don't think that something like "make it impossible to reserve more as 50 % of system RAM for crashkdump" gets accepted upstream.

However, in general I think the case where the user removes that much memory is very rare. Note that we don't talk about "Ließchen Müller" that uses kdump on the laptop but mostly Enterprise server users.

I'll work on the first issue as soon as time permits, though.

Right. Here is what we talked about on the phone: Probably it makes sense to decide in userspace on a policy for the crashkernel value for different RAM-sizes, and then tell the kernel about this policy. In this way, the kernel can still make adequate decisions during boot even when the user removed (or added) RAM. The crashkernel parameter could support an extended syntax (modeled after the netdevice= parameter): crashkernel=<ramsize-range1>:<cksize1>[,<ramsize-range2>:<cksize2>,..] A typical use would be: crashkernel=0-191M:0,192M-511M:64M,512M-1023M:>>3,1G-:128M meaning: 0-191M:0 below 192MiB RAM, set crashkernel to 0 192M-511M:64M from 192MiB to 511MiB RAM, set crashkernel to 64MiB 512M-1023M:>>3 from 512MiB to 1023MiB RAM, set crashkernel to 1/8th of the RAM size (= (ramsize >> 3)) 1G-:128M from 1GiB RAM upwards, set crashkernel to 128MiB This approach solves the problem that when the crashkernel feature is used systems could become unbootable after relatively normal hardware changes. The extended crashkernel syntax, together with changes in yast2-kdump that support this syntax, seems to be another possible feature for 11.0 / SLES11. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.