https://bugzilla.novell.com/show_bug.cgi?id=300124#c6
--- 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 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.