Bug 592140

Summary: Enabling kdump at the end of firstboot fails
Product: Red Hat Enterprise Linux 6 Reporter: Brian Lane <bcl>
Component: kexec-toolsAssignee: Neil Horman <nhorman>
Status: CLOSED CURRENTRELEASE QA Contact: Han Pingtian <phan>
Severity: medium Docs Contact:
Priority: low    
Version: 6.0CC: syeghiay
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: kexec-tools-2.0.0-70 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-11-10 20:59:50 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:
Bug Depends On:    
Bug Blocks: 524819    
Attachments:
Description Flags
grub.conf from EFI system install
none
output of parted -l on the EFI system
none
patch to look for grub.conf correctly
none
updated patch
none
working patch none

Description Brian Lane 2010-05-14 00:23:20 UTC
Description of problem:
I tried to enable kdump at the end of firstboot, it warned me that it needed to reboot, I selected ok and it displayed an error: 'Error! No bootloader config file found, aborting configuration!'

Clicked ok and it returned to the kdump page with it disabled. I completed the install successfully with it disabled.

Version-Release number of selected component (if applicable):
firstboot-1.110.2-1.el6.x86_64

How reproducible:
Unknown, I have tried once so far.



Additional info:

I couldn't find any firstboot logs related to kdump or the error. I checked the anaconda logs and they have nothing as well.

Comment 2 RHEL Program Management 2010-05-14 02:38:52 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

Comment 3 Martin Gracik 2010-05-14 07:39:37 UTC
Hi Brian,

I tried to reproduce this, I installed nightly from May 11th, with firstboot-1.110.2-1. In firstboot, right after restart, I enabled kdump, in the dialog about restart needed, I pressed Yes, and got no error message, everything went fine.

So I could not reproduce it, can you try yourself again?

Comment 4 Brian Lane 2010-05-14 17:12:45 UTC
I tried the install using the same .iso on a virt (single disk, use all space) and it enables kdump just fine.

I tried running firstboot on the EFI system and it had the same problem. I did a reinstall just to be sure and it still won't enable kdump.

I'll attach my grub.conf and parted -l output. Let me know if there are any other files to look at, as far as I can tell firstboot isn't logging anything.

Comment 5 Brian Lane 2010-05-14 17:13:36 UTC
Created attachment 414116 [details]
grub.conf from EFI system install

Comment 6 Brian Lane 2010-05-14 17:14:06 UTC
Created attachment 414117 [details]
output of parted -l on the EFI system

Comment 7 Brian Lane 2010-05-17 15:49:57 UTC
More info:

/boot is mounted, but some of the files are in different locations.

/etc/grub.conf exists (attached above)
/boot/grub/ only has device.map and splash.xpm.gz in it, no grub.conf

/boot/efi is a separate partition and it has grub.conf in it:

/boot/efi/EFI/redhat/grub.conf 
/boot/efi/EFI/redhat/grub.efi

So, if firstboot/kdump is looking for /boot/grub/grub.conf it isn't going to find it.

/etc/grub.conf is a symlink to /boot/efi/EFI/redhat/grub.conf

Comment 8 Neil Horman 2010-05-19 10:48:06 UTC
yeah, we're looking for /boot/grub/grub.conf.  I'll put together a patch

Comment 9 Neil Horman 2010-05-19 10:49:43 UTC
Created attachment 415083 [details]
patch to look for grub.conf correctly

I think this should do it, could you please test this out and confirm that firstbook works properly for you?  Thanks!

Comment 10 Brian Lane 2010-05-19 16:34:54 UTC
That won't work, you're adding a new grub entry pointing to the efi config, but that overwrites the previous entry in the dict.

I'd suggest either testing for /etc/grub.conf (assuming it always points to the right place -- I don't know enough to be sure of this) or making the bootloaders dict support lists of config files to test for, eg:

bootloaders = { "grub"   : [("/boot/grub/grub.conf", 16),
                            ("/boot/efi/EFI/redhat/grub.conf", 256)],
                "yaboot" : [("/boot/etc/yaboot.conf", 32)],
                "elilo"  : [("/boot/efi/EFI/redhat/elilo.conf", 256)],
              }

Comment 11 Neil Horman 2010-05-19 17:12:44 UTC
Dang your right, its a dict not a list of lists.  I'll fix up the patch to do the latter suggestion I think.  Thanks!

Comment 12 Neil Horman 2010-05-19 19:56:51 UTC
Created attachment 415243 [details]
updated patch

here you go.  I've not tested it yet, but I think this should make the bootloaders dictionary list aware, and let us match multiple entries for each name.

Comment 13 Brian Lane 2010-05-19 23:15:43 UTC
Created attachment 415284 [details]
working patch

Comment 14 Brian Lane 2010-05-19 23:16:27 UTC
Attached is a tested patch. I store the offset in the instance so that the bootloaders don't need to be scanned every time the offset is needed.

Comment 20 releng-rhel@redhat.com 2010-11-10 20:59:50 UTC
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.