Bug 1469491 - virt-install --boot nvram option gives: ERROR Failed to create file '<filename>': Permission denied
virt-install --boot nvram option gives: ERROR Failed to create file '<filenam...
Status: CLOSED UPSTREAM
Product: Virtualization Tools
Classification: Community
Component: virt-manager (Show other bugs)
unspecified
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Cole Robinson
: Reopened
Depends On:
Blocks: TRACKER-bugs-affecting-libguestfs
  Show dependency treegraph
 
Reported: 2017-07-11 07:47 EDT by Richard W.M. Jones
Modified: 2017-07-17 09:32 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-07-12 03:56:29 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Richard W.M. Jones 2017-07-11 07:47:48 EDT
Description of problem:

$ cp /usr/share/edk2/aarch64/vars-template-pflash.raw .
$ virt-install --name=tmp --ram=2048 --arch=aarch64 --vcpus=1 --os-type=linux --os-variant=fedora23 --boot loader=/usr/share/edk2/aarch64/QEMU_EFI-pflash.raw,loader_ro=yes,loader_type=pflash,nvram=vars-template-pflash.raw --location=https://dl.fedoraproject.org/pub/fedora-secondary/releases/26/Server/aarch64/os/ --disk=tmp,size=6 --nographics --noreboot

Starting install...
Retrieving file vmlinuz...                                  |  15 MB  00:22 !!! 
Retrieving file initrd.img...                               |  47 MB  00:50     
Allocating 'tmp'                                            | 6.0 GB  00:00     
ERROR    Failed to create file 'vars-template-pflash.raw': Permission denied
Domain installation does not appear to have been successful.
If it was, you can restart your domain by running:
  virsh --connect qemu:///session start tmp
otherwise, please restart your installation.

This worked fine in earlier versions.

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

virt-install-1.4.1-2.fc26.noarch

How reproducible:

100%

Steps to Reproduce:
1. See above.

Expected results:

It should notice that the nvram file has already been created and use it.
Comment 1 Richard W.M. Jones 2017-07-11 07:55:52 EDT
It looks as if virt-install simply passes this element to the libvirt
XML, so libvirt is the problem here.  I am using:

libvirt-daemon-3.4.0-1.fc27.x86_64
Comment 2 Richard W.M. Jones 2017-07-11 07:59:08 EDT
The XML generated by virt-install (found by --print-xml option) is
as follows.  I'm guessing the lack of a full path is the problem.

<domain type="qemu">
  <name>tmp</name>
  <uuid>f7c7c522-b64b-4d58-81e1-1cd6bd7cb8dd</uuid>
  <memory>2097152</memory>
  <currentMemory>2097152</currentMemory>
  <vcpu>1</vcpu>
  <os>
    <type arch="aarch64" machine="virt">hvm</type>
    <loader readonly="yes" type="pflash">/usr/share/edk2/aarch64/QEMU_EFI-pflash.raw</loader>
    <nvram>vars-template-pflash.raw</nvram>
    <boot dev="hd"/>
  </os>
  <features>
    <acpi/>
  </features>
  <cpu mode="custom" match="exact">
    <model>cortex-a57</model>
  </cpu>
  <clock offset="utc"/>
  <devices>
    <emulator>/usr/bin/qemu-system-aarch64</emulator>
    <disk type="file" device="disk">
      <driver name="qemu" type="qcow2"/>
      <source file="/var/tmp/tmp"/>
      <target dev="sda" bus="scsi"/>
    </disk>
    <controller type="scsi" index="0" model="virtio-scsi"/>
    <interface type="user">
      <mac address="52:54:00:8a:2d:67"/>
      <model type="virtio"/>
    </interface>
    <console type="pty"/>
    <channel type="unix">
      <source mode="bind"/>
      <target type="virtio" name="org.qemu.guest_agent.0"/>
    </channel>
  </devices>
</domain>
Comment 3 Pavel Hrdina 2017-07-11 10:59:33 EDT
You are using the --boot ...,nvram=$PATH options incorrectly.  The libvirt documentation states:

"Some UEFI firmwares may want to use a non-volatile memory to store some variables. In the host, this is represented as a file and the absolute path to the file is stored in this element."

The "absolute path to the file is stored in this element" is the important part of the documentation.
Comment 4 Richard W.M. Jones 2017-07-11 13:59:54 EDT
Well that sounds like a bug in virt-install.
Comment 5 Pavel Hrdina 2017-07-12 03:56:29 EDT
There is no bug in any component.

From the Comment 1 the relevant part of virt-install command line is:

 "--boot loader=/usr/share/edk2/aarch64/QEMU_EFI-pflash.raw,loader_ro=yes,loader_type=pflash,nvram=vars-template-pflash.raw"

Where you've provided relative path "vars-template-pflash.raw".

The Comment 2 shows the generated XML which correctly uses the provided path:

  <os>
    <type arch="aarch64" machine="virt">hvm</type>
    <loader readonly="yes" type="pflash">/usr/share/edk2/aarch64/QEMU_EFI-pflash.raw</loader>
    <nvram>vars-template-pflash.raw</nvram>
    <boot dev="hd"/>
  </os>

You need to use absolute path in order to get it work, virt-install will not expand the relative path to absolute path.
Comment 6 Cole Robinson 2017-07-12 07:27:08 EDT
Rich, what are you trying to do exactly? Is 'vars-template-pflash.raw' just meant to be the generated nvram basename, or do you actually want it generated in $CWD, or something else?

Things we could fix: have libvirt reject a non-absolute path (which it should really do for a whole slew of cases like disk paths if it doesn't do that already), and/or have virt-install run os.path.abspath on the value like we do for --disk, or have virtinst reject a non absolute path
Comment 7 Richard W.M. Jones 2017-07-17 09:00:18 EDT
(In reply to Cole Robinson from comment #6)
> Rich, what are you trying to do exactly? Is 'vars-template-pflash.raw' just
> meant to be the generated nvram basename, or do you actually want it
> generated in $CWD, or something else?

No it's an existing file in the current working directory.

This worked in Fedora 25, it's just stopped working at some point
recently.
Comment 8 Cole Robinson 2017-07-17 09:18:44 EDT
I pushed the abspath change to virt-manager:

commit b5c9321b0762b6a33a1ca5d20a4ab4bd4a16ad3e (HEAD -> master, origin/master, origin/HEAD)
Author: Cole Robinson <crobinso@redhat.com>
Date:   Mon Jul 17 09:16:45 2017 -0400

    osxml: run abspath on passed nvram value


But it would be interesting to test and see if an absolute path is still working as you expected or if there's some other regression.
Comment 9 Richard W.M. Jones 2017-07-17 09:32:19 EDT
It works.  I tested it using the reproducer (comment 0) against
the current master of virt-manager, just substituting ./virt-install
for the virt-install command.  Thanks.

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