Bug 1185460

Summary: [atomic] kdump cant find kernel image on ostree-based systems
Product: Red Hat Enterprise Linux 7 Reporter: Jeremy Eder <jeder>
Component: kexec-toolsAssignee: Baoquan He <bhe>
Status: CLOSED ERRATA QA Contact: Qiao Zhao <qzhao>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 7.1CC: jkrieger, lilu, qzhao, ruyang, vanhoof, vgoyal, walters
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: kexec-tools-2.0.7-17.el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-03-05 07:03:51 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Comment 8 Dave Young 2015-01-28 08:48:10 UTC
Baoquan is working on a patch, after discussing we found a issue, user can manually set KDUMP_BOOTDIR as other directory which is not /boot, we should respect the KDUMP_BOOTDIR value, should do the appending only when it equals /boot.

Comment 9 Vivek Goyal 2015-01-28 14:50:28 UTC
(In reply to Dave Young from comment #8)
> Baoquan is working on a patch, after discussing we found a issue, user can
> manually set KDUMP_BOOTDIR as other directory which is not /boot, we should
> respect the KDUMP_BOOTDIR value, should do the appending only when it equals
> /boot.

Also we should modify it only if kernel could not be found in /boot. otherwise a user might put a kernel in /boot/ and that kernel will not be used. Instead we will go to a subdir. And that's not what user wanted.

Comment 10 Colin Walters 2015-01-28 18:44:12 UTC
We definitely need a mechanism where kdump can determine the bootdir dynamically; don't want customers hardcoding the checksum in the config file, as it won't work for upgrades.


OSTree does have a full API, although unfortunately we don't have pygobject or any other introspection bindings in the Atomic Host.  However, you can determine the boot directory checksum for a deployment with a C program, like:

  ostree_sysroot_load()
  booted = ostree_sysroot_get_booted_deployment()
  checksum = ostree_deployment_get_bootcsum (booted)

I could look at adding an ostree command for this.  We already have a semi-hidden "ostree admin --print-current-dir".  I could add

ostree admin --print-current-boot-dir ?

Comment 11 Vivek Goyal 2015-01-28 18:57:42 UTC
(In reply to Colin Walters from comment #10)
> We definitely need a mechanism where kdump can determine the bootdir
> dynamically; don't want customers hardcoding the checksum in the config
> file, as it won't work for upgrades.
> 
> 
> OSTree does have a full API, although unfortunately we don't have pygobject
> or any other introspection bindings in the Atomic Host.  However, you can
> determine the boot directory checksum for a deployment with a C program,
> like:
> 
>   ostree_sysroot_load()
>   booted = ostree_sysroot_get_booted_deployment()
>   checksum = ostree_deployment_get_bootcsum (booted)
> 
> I could look at adding an ostree command for this.  We already have a
> semi-hidden "ostree admin --print-current-dir".  I could add
> 
> ostree admin --print-current-boot-dir ?

I think that will work.

Current proposed patch is parsing command line and looking for BOOT_IMAGE= to figure out where is actual boot dir. Is that good enough?

Comment 12 Colin Walters 2015-01-28 19:30:20 UTC
(In reply to Vivek Goyal from comment #11)

> Current proposed patch is parsing command line and looking for BOOT_IMAGE=
> to figure out where is actual boot dir. Is that good enough?

Oh, hmm.  Yes, that should work.  I don't actually know offhand what sets that though.  I think it might be grub2 that synthesizes it?  Yes, looks like it.

So, that seems good enough then.

Comment 18 Vivek Goyal 2015-01-30 15:44:41 UTC
This issue is present in 7.1. Changing version to reflect that.

Comment 20 errata-xmlrpc 2015-03-05 07:03:51 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-0324.html