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):
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.
Warning message and no way to configure (turn off) kdump during firstboot.
Ability to configure kdump during firstboot.
I don't know. Maybe there's somewhere to deselect it during the customised package install step but I didn't see it.
Ben, this is not a bug, we disable firstboot when you don't have memory >4G.
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? (-:
What is the warning at boot for kdump?
I do not get any but only have 2 GB of RAM.
(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.
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).
(In reply to comment #6)
Yeah, I remember I did, but might miss something when I added the dialog box.
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.
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
No "Insufficient memory to configure kdump!" found
(In reply to comment #11)
Copy firstboot_kdump.py to /usr/share/firstboot/modules.
Created attachment 481311 [details]
Tested on dell-pesc1420-01.rhts.eng.bos.redhat.com:
[root@dell-pesc1420-01 ~]# rpm -q kernel kexec-tools firstboot; free
total used free shared buffers cached
Mem: 1019884 592184 427700 0 38936 348932
-/+ buffers/cache: 204316 815568
Swap: 2064376 0 2064376
Based on comment #5 and comment #13, change status to VERIFIED.
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.