Bug 625996

+++ This bug was initially created as a clone of Bug #431584 +++

Description of problem:
every time i boot 5.5 i get the error
"Memory for crash kernel (0x0 to 0x0) notwithin permissible range"

Version-Release number of selected component (if applicable):
5.1

How reproducible:

every time
Steps to Reproduce:
1. install 5.1 (without enabling kdump)
2. reboot
3. watch startup screen
  
Actual results:
"Memory for crash kernel (0x0 to 0x0) notwithin permissible range"

Expected results:
"kdump disabled"

Additional info:

--- Additional comment from james.antill on 2008-02-05 12:38:07 EST ---

 I assume this was a mistake making this against zsh? Reassigning, and tweaking
the summary.


--- Additional comment from cdredhat.uk on 2008-02-05 12:46:00 EST ---

yes you're right thanks - i didn't realise kdump was actually listed as kexec-kdump

--- Additional comment from nhorman on 2008-02-06 10:26:50 EST ---

Its not a bug, its just an informative message, indicating that you haven't
specified an area of memory to reserve during boot up for use by the kdump
kernel.  You can specify it using the crashkernel=X@Y commandline parameter

--- Additional comment from cdredhat.uk on 2008-02-07 06:44:38 EST ---

if crashkernel=0x0@0x0 is not the "correct way" to disable kdump what is ?
and why doesn't install program use this "other way" instead ?

--- Additional comment from nhorman on 2008-02-07 07:02:16 EST ---

The correct way to disable kdump is to not start the kdump service.  Adding a
crashkernel line to the kernel command line won't enable or disable kdump at
all, that just reserves memory for use by kdump to use.  Sepcifying
crashkernel=0@0 is exactly the same as not specifying a crashkernel parameter at
all.  You'll still get the warning in the logs, which is there to inform you
that, even if you try to start the kdump service, it will fail.

--- Additional comment from cdredhat.uk on 2008-02-07 08:55:03 EST ---

sorry to keep going on a bit more but does this mean the installer is doing the
wrong thing if you untick the enable kdump box !

http://www.flickr.com/photos/osde-info/2241815136/

BTW even if i # chkconfig kdump off and reboot i still see this message on the
boot up screen !

so does this make this is an grub/installer issue rather than kdump issue ?

--- Additional comment from nhorman on 2008-02-07 10:05:01 EST ---

No, there is no issue.

Kdump requires that a large chunk of contiguous memory be reseerved for its use.
 This chunk is sufficiently large that it can't be allocated dynamically in a
runing system.  As such we reserve it on bootup.  This process is 100% separate
from the starting of the kdump service .  It will be reserved weather or not you
start the kdump service later in the boot process.  conversely, if you do not
select any memory, you won't be able to use kdump if you try to start the service.

unchecking the box in the initial install prevents the kdump service from
starting, and thats working just fine.  But the kernel has no knoweldge of that
decision as early in the boot process as we need to reserve that memory.  As
such we need to issue a warning indicating that non crash kernel memory is
reserved, even if we don't intend to start the kdump service later

consider the converse situation.  if you had intended to start the kdump service
later, but didn't specify a valid crashkernel memory range, this warning
provides a  red flag as to what has gone wrong with the process.  If you don't
intend to start kdump, then you can safely ignore this warning.

This is working exactly the way its supposed to.

--- Additional comment from cdredhat.uk on 2008-02-07 12:13:33 EST ---

thanks

--- Additional comment from uleman on 2009-04-06 11:53:53 EDT ---

"Its not a bug, its just an informative message, ..."
"No, there is no issue."
"This is working exactly the way its supposed to."

Despite the helpful explanations, Neil's responses are also a bit too much of the variety, "We developers know what we mean, but you users are just not getting it." 

Clearly, there is an issue: several people have stumbled over this (google it). In my work as a software developer, anything that generates customer support calls (or forum entries, as the case may be) is a bug, though you can argue over the severity. In this case, I think it's pretty obvious what the defect is: the message is poorly worded (not to mention poorly typed), causing it to be misleading and alarming (not "informative").

So I think a few edits would help. Note that I know nothing about kexec/kdump, nor anything about constraints on boot messages (lengthwise or otherwise). But I'm looking for these improvements:
1) If there's a more or less accepted way to indicate that this is just an informational message and not indicative of a failure, use it. (Info: or Warning:?)
2) Indicate that this has something to do with kdump (kexec?), so you can go look for instructions if you want to learn more.
3) While alerting the user to the fact that insufficient memory has been allocated for kdump, suggest that this is only relevant if you actually want to use kdump.

For example:
"Info: Memory for crash kernel (0x0 to 0x0) insufficient for kdump. Allocate more if using kdump."

What do you think?

--- Additional comment from gerrit.slomma on 2009-06-30 17:39:51 EDT ---

Sounds good. Furthermore i would rather have the message disappear if - and only if - the memory-amount for crashkernel is set to "0x0 to 0x0" since this only means the crashkernel-feature is set to off by intention. Must be a rather simple "if-then-else" statement surrounding the statement that prints this message.

--- Additional comment from bugzilla.uk on 2009-06-30 18:57:11 EDT ---

(In reply to comment #10)
> Sounds good. Furthermore i would rather have the message disappear if - and
> only if - the memory-amount for crashkernel is set to "0x0 to 0x0" since this
> only means the crashkernel-feature is set to off by intention. Must be a rather
> simple "if-then-else" statement surrounding the statement that prints this
> message.  

I would also prefer it to not report anything or at least reword it if this isn't a problem. "not within permissible range" gives the impression something is broken.

--- Additional comment from rjones on 2009-09-16 09:36:58 EDT ---

Yeah, this was the first time I ever came across that, i thought for sure I had bad hardware or messed up the install or found a bug in 5.4.  Would be nice if when you go to install a server and turn off kdump, it disabled this message or gave a better worded message like "kdump disabled, not configured"

--- Additional comment from charles on 2010-03-27 20:53:58 EDT ---

I thought this was a hardware issue as well, good to know it's just a alert.

--- Additional comment from bug.edu on 2010-04-26 09:41:20 EDT ---

Please reword this "alert".  It is unnecessarily alarming and generates many help requests.  I think many people are tired of explaining this to alarmed users.  It only teaches users to ignore real errors, which is a VERY BAD THING.

--- Additional comment from lutz.willek on 2010-06-24 11:24:24 EDT ---

(In reply to comment #7)
> No, there is no issue.

Take a step back, try to understand, here is an issue. 

Hundreds of thousands people wasting time by searching informations about a stupid warning message.

Please disable this warning, if no crashkernel=xy line is provided and:

> consider the converse situation.  if you had intended to start the kdump service
> later, but didn't specify a valid crashkernel memory range, this warning
> provides a  red flag as to what has gone wrong with the process.  If you don't
> intend to start kdump, then you can safely ignore this warning.

later, if you try to start kdump check for a valid cmdline "crashkernel=xy".

--- Additional comment from nicolai on 2010-08-19 15:03:15 EDT ---

I notice that this is a closed ticket so I am not sure if this is even read or considered by the developers but I fail to understand why this is even reported by the kernel. As I understand it the reasoning is: "If you ever want to enable kdump later this may be a problem at that time so we tell you now". That is just confusing people. Why isn't it kdump that gives this error, as in:

 if (no-enough-memory-reserved-for-crash-kernel) {
   fail("Not enough memory reserved. Please add more memory using the crashkernel=X@Y kernel parameter");
 }

As others have said, this is a defect since it is causing confusion for end-users.

Gerrit Slomma:
Cloned the bug since i think no developer is reading closed bugs anymore.
Rebased to RHEL 5.5, wasn't able to rebase the initial bug, so the clone was necessary.