Bug 1185460 - [atomic] kdump cant find kernel image on ostree-based systems
Summary: [atomic] kdump cant find kernel image on ostree-based systems
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: kexec-tools
Version: 7.1
Hardware: All
OS: Linux
urgent
urgent
Target Milestone: rc
: ---
Assignee: Baoquan He
QA Contact: Qiao Zhao
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-01-23 20:12 UTC by Jeremy Eder
Modified: 2015-03-05 07:03 UTC (History)
7 users (show)

Fixed In Version: kexec-tools-2.0.7-17.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-05 07:03:51 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:0324 normal SHIPPED_LIVE kexec-tools bug fix and enhancement update 2015-03-05 11:57:30 UTC

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


Note You need to log in before you can comment on or make changes to this bug.