Bug 1033508 - libguestfs doesn't work because it can't find a kernel in ovirt-node
Summary: libguestfs doesn't work because it can't find a kernel in ovirt-node
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: ovirt-node
Version: 6.4
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: rc
: 6.5
Assignee: Fabian Deutsch
QA Contact: Virtualization Bugs
URL:
Whiteboard:
: 846956 (view as bug list)
Depends On: 1033632
Blocks: TRACKER-bugs-affecting-libguestfs rhevh-for-rhev-3.3
TreeView+ depends on / blocked
 
Reported: 2013-11-22 09:46 UTC by Richard W.M. Jones
Modified: 2014-01-21 19:37 UTC (History)
11 users (show)

Fixed In Version: ovirt-node-3.0.1-8.el6
Doc Type: Bug Fix
Doc Text:
When running 'libguestfs-test-tool' the following error message was generated: "$ libguestfs-supermin-helper: failed to find a suitable kernel. I looked for kernels in /boot and modules in /lib/modules. If this is a Xen guest, and you only have Xen domU kernels installed, try installing a fullvirt kernel (only for libguestfs use, you shouldn't boot the Xen guest with it)". This occurred because the kernel and initrd are not located in /boot. To fix this the kernel has been symlinked into /boot. The libguestfs-test-tool now runs without error.
Clone Of:
Environment:
Last Closed: 2014-01-21 19:37:49 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2014:0033 normal SHIPPED_LIVE ovirt-node bug fix and enhancement update 2014-01-22 00:14:30 UTC
oVirt gerrit 22244 None None None Never

Description Richard W.M. Jones 2013-11-22 09:46:58 UTC
Description of problem:

libguestfs-test-tool prints:

    $ libguestfs-supermin-helper: failed to find a suitable kernel.
    I looked for kernels in /boot and modules in /lib/modules.
    If this is a Xen guest, and you only have Xen domU kernels
    installed, try installing a fullvirt kernel (only for
    libguestfs use, you shouldn't boot the Xen guest with it).

Version-Release number of selected component (if applicable):

libguestfs 1.16 in RHEL 6.4 (ovirt-node)

How reproducible:

100%

Steps to Reproduce:
1. Run libguestfs-test-tool

Actual results:

Fails as above.

Expected results:

Should run and print various diagnostics followed by:
===== TEST FINISHED OK =====

Additional info:

Please add libguestfs-test-tool as a step in regression testing
when creating ovirt-node.

Comment 1 Richard W.M. Jones 2013-11-22 09:47:59 UTC
libguestfs-test-tool output reported by a user:
https://www.redhat.com/archives/libguestfs/2013-November/msg00068.html

Comment 3 Fabian Deutsch 2013-11-22 11:11:35 UTC
On RHEV-H the kernel and initrd is not located in /boot, they are only exposed in /dev/.initramfs/live/ as vmlinuz0 and initrd0.

A workaround is to symlink the kernel into /boot.

$ ln -s /dev/.initramfs/live/vmlinuz0 /boot/vmlinuz-$(uname -r)

Afterwards libguestfs-test-tool should run fine.

Comment 4 Fabian Deutsch 2013-11-22 11:57:00 UTC
(In reply to Fabian Deutsch from comment #3)
> On RHEV-H the kernel and initrd is not located in /boot, they are only
> exposed in /dev/.initramfs/live/ as vmlinuz0 and initrd0.
> 
> A workaround is to symlink the kernel into /boot.
> 
> $ ln -s /dev/.initramfs/live/vmlinuz0 /boot/vmlinuz-$(uname -r)

It should be
$ ln -s /dev/.initramfs/live/isolinux/vmlinuz0 /boot/vmlinuz-$(uname -r)

> Afterwards libguestfs-test-tool should run fine.

Comment 5 Fabian Deutsch 2013-11-22 12:01:12 UTC
Rich,

we can probably create that symlink for compatibility, but libguestfs should probably also look fpor kernels in the in the livecd related paths

/dev/.initramfs/live
/dev/.initramfs/live/isolinux

One problem might be that the kernel found there (vmlinuz9) is "unversioned".

Comment 6 Richard W.M. Jones 2013-11-22 12:24:44 UTC
The following might work:

export FEBOOTSTRAP_KERNEL=/dev/.initramfs/live/isolinux/vmlinuz0

(I can't test this)

It's not great for RHEL users however unless we can add this
environment variable in some place where it will always be set
(for shell users and VDSM hooks at least).

Comment 7 Richard W.M. Jones 2013-11-22 14:20:11 UTC
(In reply to Richard W.M. Jones from comment #6)
> The following might work:
> 
> export FEBOOTSTRAP_KERNEL=/dev/.initramfs/live/isolinux/vmlinuz0
> 
> (I can't test this)

The customer reported that this didn't work:

  select kernel /dev/.initramfs/live/vmlinuz0
  febootstrap-supermin-helper: cannot guess module path.

Comment 8 RHEL Program Management 2013-11-25 14:28:29 UTC
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 11 Richard W.M. Jones 2013-11-28 08:52:14 UTC
*** Bug 846956 has been marked as a duplicate of this bug. ***

Comment 12 Richard W.M. Jones 2013-11-28 09:49:10 UTC
Anyway we have a program to test if the kernel/appliance
stuff is working or not:

  libguestfs-test-tool

It doesn't require any special permissions.

It is completely self-contained.

It only takes a minute to run.

It can be called from a script (has correct exit statuses for
error/success).

It should be added to whatever regression test is done on
ovirt-node candidates.

Comment 13 Fabian Deutsch 2013-11-29 09:42:29 UTC
IIUIC everything is in place (pkgs and configuration), the only thing missing are the correct symlinks to the kernel.

Comment 15 Cheryn Tan 2014-01-08 05:37:11 UTC
This bug is currently attached to errata RHBA-2013:15277. If this change is not to be documented in the text for this errata please either remove it from the errata, set the requires_doc_text flag to minus (-), or leave a "Doc Text" value of "--no tech note required" if you do not have permission to alter the flag.

Otherwise to aid in the development of relevant and accurate release documentation, please fill out the "Doc Text" field above with these four (4) pieces of information:

* Cause: What actions or circumstances cause this bug to present.
* Consequence: What happens when the bug presents.
* Fix: What was done to fix the bug.
* Result: What now happens when the actions or circumstances above occur. (NB: this is not the same as 'the bug doesn't present anymore')

Once filled out, please set the "Doc Type" field to the appropriate value for the type of change made and submit your edits to the bug.

For further details on the Cause, Consequence, Fix, Result format please refer to:
https://bugzilla.redhat.com/page.cgi?id=fields.html#cf_release_notes

Thank you for your help.

Comment 17 Charlie 2014-01-15 02:15:52 UTC
Hiya, could you let me know how this problem was resolved for the doctext? Thanks

Comment 19 errata-xmlrpc 2014-01-21 19:37:49 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.

http://rhn.redhat.com/errata/RHBA-2014-0033.html


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