Bug 1236691 - /virt/install does not respect guest kernel_options
Summary: /virt/install does not respect guest kernel_options
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Beaker
Classification: Retired
Component: tests
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: 21.0
Assignee: Dan Callaghan
QA Contact: tools-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-06-29 18:05 UTC by Jan Stancek
Modified: 2015-08-26 06:15 UTC (History)
7 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2015-08-26 06:15:29 UTC
Embargoed:


Attachments (Terms of Use)

Description Jan Stancek 2015-06-29 18:05:18 UTC
Description of problem:
My guest recipe is:
<guestrecipe guestargs="--ram=1024 --vcpus=1 --file-size=20 --hvm --kvm --nonsparse" guestname="x86_64_kvm_1cpu" kernel_options="!ksdevice inst.zram=off" kernel_options_post="" ks_meta="method=nfs" role="None" whiteboard="3.10.0-287.el7 KVM x86_64 1 vcpu">

Guest is started with command line:
Command line: inst.repo=nfs:vtap-bos-eng01.bos.redhat.com:/vol/engineering/devarchive/redhat/nightly/RHEL-7.2-20150629.n.0/compose/Server/x86_64/os/ ks=http://beaker.engineering.redhat.com/kickstart/1412499 serial console=tty0 console=ttyS0,115200

PROBLEM: "!ksdevice inst.zram=off" are not passed to guest kernel command line

Version-Release number of selected component (if applicable):
distribution-distribution-virt-install-4.0-88.noarch

How reproducible:
100%

Steps to Reproduce:
1. try to pass some kernel options to guest at installation time

Actual results:
kernel_options field is ignored

Expected results:
kernel_options field is added to guest kernel command line

Additional info:

Comment 2 Dan Callaghan 2015-07-01 00:35:50 UTC
I don't think this is a regression, is it?

We just need the task to grab kernel_options out of the recipe XML and append it to the end of the --extra-args option that it builds, I guess.

BTW !ksdevice doesn't mean anything to the kernel (the ! prefix is a Cobbler-ism, reimplemented in Beaker) so I'm not sure why that's in there. Although it makes no difference to this bug.

Comment 3 Jan Stancek 2015-07-01 08:59:50 UTC
(In reply to Dan Callaghan from comment #2)
> I don't think this is a regression, is it?

Likely not a regression.

> BTW !ksdevice doesn't mean anything to the kernel (the ! prefix is a
> Cobbler-ism, reimplemented in Beaker) so I'm not sure why that's in there.
> Although it makes no difference to this bug.

The option I cared about was "inst.zram=off", because zram has fatal bug, that breaks installation of recent RHEL7.2 nightly trees.

Comment 6 Dan Callaghan 2015-07-24 01:56:10 UTC
Tagged as:
/distribution/virt/install 4.0-89
/distribution/virt/image-install 1.0-5
/distribution/virt/start 2.1-10
/distribution/virt/stop 2.0-17
/distribution/virt/start_stop 2.1-3

Comment 8 Dan Callaghan 2015-07-24 02:16:38 UTC
Suggested test case:
Run a job with a guest recipe, put kernel_option_post="dummyoption" in <guestrecipe/>.
Check kernel command line shown in guest console log after the recipe is finished.
Expected results:
"dummyoption" should appear on kernel command when the guest reboots after installation.

Comment 9 Jan Stancek 2015-07-24 06:30:45 UTC
(In reply to Dan Callaghan from comment #8)
> Suggested test case:
> Run a job with a guest recipe, put kernel_option_post="dummyoption" in
                                     ^^ this BZ is about kernel_options

kernel_options_post is handled via kickstart as parameter for "bootloader" option, as far as I know that always worked fine.

> <guestrecipe/>.
> Check kernel command line shown in guest console log after the recipe is
> finished.

kernel_options should be on command line only during installation.

Comment 10 Dan Callaghan 2015-07-26 22:10:14 UTC
(In reply to Jan Stancek from comment #9)

Ah yes of course, I got it the wrong way around. Thanks for the correction :-)

Comment 12 Dan Callaghan 2015-08-26 06:15:29 UTC
Tasks published on beaker-project.org.


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