Bug 1030962

Hi AJ,

This is the doc text that will go into the Known Issues section of the Big Bend Update 1 Release Notes. Please sign off on the technical accuracy of this text.

On installing the Red Hat Storage Server from an ISO image, a package for the kdump service kexec-tools gets installed by default.The 'crashkernel=auto' kernel parameter that is required for reserving memory for the kdump kernel is not set for the kernel entry in the bootloader configuration file at /boot/grub/grub.conf. This kernel parameter, if missing, is supposed to be set by the 'posttrans scriptlet' of the kernel package. Therefore, the kdunmp service fails to start up with the following message in the logs.

kdump: No crashkernel parameter specified for running kernel

Workaround: On installing another kernel after the Red Hat Storage Server installation, the 'crashkernel=auto' kernel parameter is successfully set for the newly installed kernel entry in the bootloader configuration file.

(In reply to Pavithra from comment #2)
> Hi AJ,
> 
> This is the doc text that will go into the Known Issues section of the Big
> Bend Update 1 Release Notes. Please sign off on the technical accuracy of
> this text.
> 
> On installing the Red Hat Storage Server from an ISO image, a package for
> the kdump service kexec-tools gets installed by default.The
> 'crashkernel=auto' kernel parameter that is required for reserving memory
> for the kdump kernel is not set for the kernel entry in the bootloader
> configuration file at /boot/grub/grub.conf. This kernel parameter, if
> missing, is supposed to be set by the 'posttrans scriptlet' of the kernel
> package. Therefore, the kdunmp service fails to start up with the following
> message in the logs.
> 
> kdump: No crashkernel parameter specified for running kernel
> 
I suggest rephrasing this text to:

----------------------------

On installing RHSS from ISO, the package for the kdump service, kexec-tools, gets installed by default. However, the 'crashkernel=auto' kernel parameter, required for reserving memory for the kdump kernel, is not being set for the current kernel entry in the bootloader configuration file, /boot/grub/grub.conf. Therefore the kdump service fails to start up, with the following message available in the logs.

 kdump: No crashkernel parameter specified for running kernel

----------------------------

> Workaround: On installing another kernel after the Red Hat Storage Server
> installation, the 'crashkernel=auto' kernel parameter is successfully set
> for the newly installed kernel entry in the bootloader configuration file.

I believe that the work-around should not be limited to installing another kernel, which may not always be an appropriate solution. The issue being resolved on installing another kernel, may be given as an *additional information*, while the work-around may be given as below.

----------------------------

After RHSS installation, the 'crashkernel=auto', or an appropriate 'crashkernel=<size>M', kernel parameter may be set manually for the current kernel, in the bootloader configuration file. Then the RHSS system must be rebooted, upon which the memory for the kdump kernel would be reserved, and the kdump service would be started up successfully. Refer to the following link for more information on  'Configuring kdump on the Command Line'

[1] https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s2-kdump-configuration-cli.html

----------------------------

(In reply to Pavithra from comment #2)
> package. Therefore, the kdunmp service fails to start up with the following
> message in the logs.

(kdump, not kdunmp..)

I'm not an expert on kdump so can't provide any useful commentary here; Rejy's suggestions in comment#3 seem plausible.

(In reply to Anthony Towns from comment #4)
> (In reply to Pavithra from comment #2)
> > package. Therefore, the kdunmp service fails to start up with the following
> > message in the logs.
> 
> (kdump, not kdunmp..)
> 
> I'm not an expert on kdump so can't provide any useful commentary here;
> Rejy's suggestions in comment#3 seem plausible.

I have tested it out, and it works :-)

Rejy,
I've incorporated your comments. Can you please review?
This bug is documented in the Release Notes for Big Bend Update 1 in the link below:
http://documentation-devel.engineering.redhat.com/docs/en-US/Red_Hat_Storage/2.1/html-single/2.1_Update_1_Release_Notes/index.html#chap-Documentation-2.1_Update_1_Release_Notes-Known_Issues

(In reply to Pavithra from comment #6)
> Rejy,
> I've incorporated your comments. Can you please review?
> This bug is documented in the Release Notes for Big Bend Update 1 in the
> link below:
> http://documentation-devel.engineering.redhat.com/docs/en-US/Red_Hat_Storage/
> 2.1/html-single/2.1_Update_1_Release_Notes/index.html#chap-Documentation-2.
> 1_Update_1_Release_Notes-Known_Issues

Have put in a few changes:

On installing the Red Hat Storage Server from ISO or PXE, the package for the kdump service, kexec-tools, gets installed by default. However, the crashkernel=auto kernel parameter, required for reserving memory for the kdump kernel, is not being set at the entry for the current kernel, in the bootloader configuration file, /boot/grub/grub.conf. Therefore the kdump service fails to start up, with the following message available in the logs.

kdump: No crashkernel parameter specified for running kernel

Workaround: After installing the Red Hat Storage Server, the crashkernel=auto, or an appropriate crashkernel=<size>M kernel parameter, may be set manually for the current kernel in the bootloader configuration file. Then the Red Hat Storage Server system must be rebooted, upon which the memory for the kdump kernel would be reserved, and the kdump service would be started successfully. Refer to the following link for more information on Configuring kdump on the Command Line <--- https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s2-kdump-configuration-cli.html

Additional information: On installing a new kernel after the Red Hat Storage Server installation, the crashkernel=auto kernel parameter is successfully set, at the entry for the newly installed kernel, in the bootloader configuration file.

Rejy,

I've incorporated your comments and modified the text. Please review it in the link here:

http://documentation-devel.engineering.redhat.com/docs/en-US/Red_Hat_Storage/2.1/html/2.1_Update_1_Release_Notes/chap-Documentation-2.1_Update_1_Release_Notes-Known_Issues.html

This is documented as a known issue in the Big Bend Update 1 Release Notes.

(In reply to Pavithra from comment #8)
> Rejy,
> 
> I've incorporated your comments and modified the text. Please review it in
> the link here:
> 
> http://documentation-devel.engineering.redhat.com/docs/en-US/Red_Hat_Storage/
> 2.1/html/2.1_Update_1_Release_Notes/chap-Documentation-2.
> 1_Update_1_Release_Notes-Known_Issues.html
> 
> This is documented as a known issue in the Big Bend Update 1 Release Notes.

A small error at the last paragraph.

Additional information: On installing a new kernel after the installing Red Hat Storage Server, 

should be

Additional information: On installing a new kernel after installing the Red Hat Storage Server,

Thank you Rejy.
I've corrected it here:

http://documentation-devel.engineering.redhat.com/docs/en-US/Red_Hat_Storage/2.1/html/2.1_Update_1_Release_Notes/chap-Documentation-2.1_Update_1_Release_Notes-Known_Issues.html

(In reply to Pavithra from comment #10)
> Thank you Rejy.
> I've corrected it here:
> 
> http://documentation-devel.engineering.redhat.com/docs/en-US/Red_Hat_Storage/
> 2.1/html/2.1_Update_1_Release_Notes/chap-Documentation-2.
> 1_Update_1_Release_Notes-Known_Issues.html

Looks good. :-)

This is an anaconda bug -- anaconda sets crashkernel=auto for rhel installs, but when installing an RHS system uses the "Fedora" installclass, due to the product name not beginning with "Red Hat Enterprise".

Assistance from the anaconda team is required to fix this.

Thank you for submitting this issue for consideration in Red Hat Gluster Storage. The release for which you requested us to review, is now End of Life. Please See https://access.redhat.com/support/policy/updates/rhs/

If you can reproduce this bug against a currently maintained version of Red Hat Gluster Storage, please feel free to file a new report against the current release.