Description of problem: every time i boot 5.1 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:
I assume this was a mistake making this against zsh? Reassigning, and tweaking the summary.
yes you're right thanks - i didn't realise kdump was actually listed as kexec-kdump
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
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 ?
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.
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 ?
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.
thanks
"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?
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.
(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.
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"
I thought this was a hardware issue as well, good to know it's just a alert.
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.
(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".
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.
Another vote for hiding this message when it's disabled intentionally. But please, at the very least, make it grammatically correct and change "notwithin" to "not within"!
If it causes confusion, it's a bug that should be addressed.
i think there is lot of rubish conversation is going on. sorry if any one heart with that line becoz when i read that comment and rply i get . we are expecting answer about problem how to come out but no one is providing solution , thing is that if any one have solution regarding that problem then welcome other wise why are u all giving suggesstion . post regarding problem so we can come out with that problem. thnx we are waiting for solution of that problem
Should be a little more friendly message to the user, not to cause alarm and waste time searching the WEB
You can download system-config-kdump and enable kdump with 256 MB.. and should work. Regard
The problem is: The message is there if one disables kdump. Why should one enable kdump with an arbitrary size to get rid of an anoying message that only appears if one disabled kdump on purpose. Seems outright pointless to me. Furthermore is this only treating of the symptom and not of the root cause that still persists.