Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1469491
Summary: | virt-install --boot nvram option gives: ERROR Failed to create file '<filename>': Permission denied | ||
---|---|---|---|
Product: | [Community] Virtualization Tools | Reporter: | Richard W.M. Jones <rjones> |
Component: | virt-manager | Assignee: | Cole Robinson <crobinso> |
Status: | CLOSED UPSTREAM | QA Contact: | |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | unspecified | CC: | berrange, crobinso, gscrivan, libvirt-maint, phrdina, rbalakri |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2017-07-12 07:56:29 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: | |||
Bug Depends On: | |||
Bug Blocks: | 910269 |
Description
Richard W.M. Jones
2017-07-11 11:47:48 UTC
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 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> 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. Well that sounds like a bug in virt-install. 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. 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 (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. I pushed the abspath change to virt-manager: commit b5c9321b0762b6a33a1ca5d20a4ab4bd4a16ad3e (HEAD -> master, origin/master, origin/HEAD) Author: Cole Robinson <crobinso> 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. |