Bug 652724

Summary: "Insufficient memory to configure kdump!" during install
Product: Red Hat Enterprise Linux 6 Reporter: Ben <ben.argyle>
Component: kexec-toolsAssignee: Cong Wang <amwang>
Status: CLOSED ERRATA QA Contact: Chao Ye <cye>
Severity: high Docs Contact:
Priority: urgent    
Version: 6.0CC: amwang, czhang, gerrit.slomma, pasteur, phan, qcai, rkhan, tgraf
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: kexec-tools-2_0_0-153_el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-05-19 14:15:53 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
No kdump option found in firstboot
none
Screenshot none

Description Ben 2010-11-12 16:18:03 UTC
Description of problem:

When installing RHEL6 (currently tested on Workstation 32 and 64 bit) a message pops up during firstboot just after NTP has been configured.  It says "Insufficient memory to configure kdump!".  You are then presented with the Kdump configuration screen with everything greyed out and kdump seemingly enabled and with no way to disable it at this point.


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

RHEL6.0


How reproducible:

Every time.


Steps to Reproduce:
1. Install RHEL6.0 Workstation 32 or 64 bit (not tested on Server at this point).
2. Reboot and follow firstboot progress.


Actual results:

Warning message and no way to configure (turn off) kdump during firstboot.


Expected results:

Ability to configure kdump during firstboot.


Additional info:

I don't know.  Maybe there's somewhere to deselect it during the customised package install step but I didn't see it.

Comment 2 Cong Wang 2010-11-15 02:48:12 UTC
Ben, this is not a bug, we disable firstboot when you don't have memory >4G.
Thanks.

Comment 3 Ben 2010-11-15 10:01:31 UTC
Do you mean you disable _kdump_ when you don't have more than 4GB of RAM?  If so I think this should be dealt with much less confusingly.

A modal dialogue box with a red warning sign and text with an exclamation mark at the end does not inspire confidence and generally means something is _broken_.  Some explanation of _why_ there's insufficient memory and that it's not a problem would be helpful.

Also, the screen following the warning where all of the kdump options are greyed out should show that kdump is _not_ enabled, rather than having the tickbox ticked.  And finally, the kdump service should be disabled rather than giving a warning on boot.  If it can't be used, why have it start up? (-:

Comment 4 Gerrit Slomma 2010-11-15 19:50:16 UTC
What is the warning at boot for kdump?
I do not get any but only have 2 GB of RAM.

Comment 5 Cong Wang 2010-11-16 03:21:07 UTC
(In reply to comment #3)
> Do you mean you disable _kdump_ when you don't have more than 4GB of RAM?  If
> so I think this should be dealt with much less confusingly.
> 

Yeah, you don't have a chance to configure kdump via firstboot, thus disabled.
But you can totally enable/configure it manually.

> A modal dialogue box with a red warning sign and text with an exclamation mark
> at the end does not inspire confidence and generally means something is
> _broken_.  Some explanation of _why_ there's insufficient memory and that it's
> not a problem would be helpful.


You need a long paragraph in a small dialog box? :) We have documented this in release notes of RHEL6.

> 
> Also, the screen following the warning where all of the kdump options are
> greyed out should show that kdump is _not_ enabled, rather than having the
> tickbox ticked.  And finally, the kdump service should be disabled rather than
> giving a warning on boot.  If it can't be used, why have it start up? (-:

Oh, it should not, let me check it.

Comment 6 Gerrit Slomma 2010-11-16 06:15:34 UTC
If you never ever can configure kdump via firstboot just let the page with the unconfigurable option out. A step where you can't choose an option is just confusing the user (as proven with this bug).

Comment 7 Cong Wang 2010-11-16 06:48:56 UTC
(In reply to comment #6)

Yeah, I remember I did, but might miss something when I added the dialog box.

Comment 8 Ben 2010-11-16 14:24:45 UTC
I can confirm that kdump is enabled on this vanilla-installed RHEL6 64-bit Workstation with 4GB of RAM (2x 2GB DIMMS) on a Dell Optiplex GX760 (BIOS A08).

[root@knife ~]# chkconfig --list | grep kdump
kdump           0:off   1:off   2:off   3:on    4:on    5:on    6:off

Therefore shouldn't kdump have been configurable?  Given the modal dialogue box and the greyed out kdump configuration page during firstboot the OS seems to have assumed it wasn't usable.  In which case kdump shouldn't be getting started.

This is, therefore, a bug on at least one count.

Comment 11 Chao Ye 2011-02-28 04:59:08 UTC
Created attachment 481303 [details]
No kdump option found in firstboot

Tested on dell-pe830-01.rhts.eng.bos.redhat.com with less than 4GB mem:
===========================================================
[root@dell-pe830-01 ~]# rpm -q kernel kexec-tools firstboot
kernel-2.6.32-118.el6.x86_64
kexec-tools-2.0.0-166.el6.x86_64
firstboot-1.110.10-1.el6.x86_64

No "Insufficient memory to configure kdump!" found

Comment 12 Cong Wang 2011-02-28 05:45:31 UTC
(In reply to comment #11)
Copy firstboot_kdump.py to /usr/share/firstboot/modules.

Comment 13 Chao Ye 2011-02-28 06:26:51 UTC
Created attachment 481311 [details]
Screenshot

Tested on dell-pesc1420-01.rhts.eng.bos.redhat.com:
========================================================================
[root@dell-pesc1420-01 ~]# rpm -q kernel kexec-tools firstboot; free
kernel-2.6.32-118.el6.x86_64
kexec-tools-2.0.0-166.el6.x86_64
firstboot-1.110.10-1.el6.x86_64
             total       used       free     shared    buffers     cached
Mem:       1019884     592184     427700          0      38936     348932
-/+ buffers/cache:     204316     815568
Swap:      2064376          0    2064376

Comment 14 Chao Ye 2011-03-01 06:10:40 UTC
Based on comment #5 and comment #13, change status to VERIFIED.

Comment 15 errata-xmlrpc 2011-05-19 14:15:53 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0736.html