Bug 1873840
| Summary: | virt-install claims qemu needs access to ~/.config/virt-manager/boot but that shouldn't be necessary | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jiri Jaburek <jjaburek> | ||||
| Component: | virt-manager | Assignee: | Cole Robinson <crobinso> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 33 | CC: | agedosier, berrange, clalancette, crobinso, itamar, jforbes, laine, libvirt-maint, philip.wyett, veillard, virt-maint | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | virt-manager-3.1.0-1.fc33 | Doc Type: | If docs needed, set a value | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2020-10-03 00:56:28 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: | |||||||
| Attachments: |
|
||||||
|
Description
Jiri Jaburek
2020-08-30 14:22:42 UTC
Thanks for the report. virt-install itself doesn't do anything with dconf/gsettings so I don't think it's related to virt-install code directly. Even using qemu:///system, it's only authorizing the connection to system libvirtd, which shouldn't be touching your homedir at all So I'm confused Can you provide ls -l ~/.config/dconf/user* If those permissions don't belong to your user, can you reset them 'chmod 644' and see if re-running virt-install reproduces the errors? Right, that's correct - it wasn't somehow owned by my user. I guess I must have run something (virt-install?) as root with sudo env_keep+="HOME" while not having ~/.cache/dconf created and that got created with root:root. And I misinterpreted the Permission denied as the 'qemu' user trying to access my home. Removing ~/.cache/dconf and running virt-install as my user got rid of the dconf warnings and ~/.cache/dconf is now owned by me. However one warning remains: WARNING /home/user/.cache/virt-manager/boot may not be accessible by the hypervisor. You will need to grant the 'qemu' user search permissions for the following directories: ['/home/user', '/home/user/.cache'] $ ls -ld .cache/ .cache/virt-manager/ .cache/virt-manager/* drwx------. 1 user user 530 Aug 31 20:34 .cache// drwxr-x--x. 1 user user 100 Aug 30 01:27 .cache/virt-manager// drwxr-x--x. 1 user user 0 Aug 31 20:35 .cache/virt-manager/boot/ drwxr-xr-x. 1 user user 72 Aug 30 01:27 .cache/virt-manager/qemu:___system/ -rw-r--r--. 1 user user 561001 Aug 31 20:35 .cache/virt-manager/virt-install.log -rw-r--r--. 1 user user 59416 Aug 30 16:11 .cache/virt-manager/virt-manager.log This message does seem to come from virt-install's check_path_search. A qemu:///system spawned qemu process has presumably no business getting into my home, so the warning doesn't make much sense. Thanks. Thanks for the info. Can you provide full virt-install --debug output when reproducing? You're right that may be a bug warning about that directory. Created attachment 1713256 [details]
virt-install --debug log
Sure, attached.
It seems that the issue is some code guessing the kernel+initrd download dir to be in my home,
DEBUG (urlfetcher:104) Using scratchdir=/home/user/.cache/virt-manager/boot
whereas dumpxml on the still-installing domain shows it as under /var/lib:
<os>
<type arch='x86_64' machine='pc-q35-4.2'>hvm</type>
<kernel>/var/lib/libvirt/boot/virtinst-2fr_qjyi-vmlinuz</kernel>
<initrd>/var/lib/libvirt/boot/virtinst-ads3i38i-initrd.img</initrd>
<cmdline>ks=file:/fedora.ks inst.repo=https://download.fedoraproject.org/pub/fedora/linux/releases/32/Server/x86_64/os</cmdline>
<boot dev='hd'/>
</os>
(as it should be for qemu:///system)
Thanks. Something is wrong there I think but I'll need to dig into it This is fixed as part of:
commit 5473695fe1c0964c7a2e90cb910e83b0fc91f80b
Author: Cole Robinson <crobinso>
Date: Tue Sep 8 18:41:41 2020 -0400
installer: Upload unattended and cloudinit data to remote connections
FEDORA-2020-656e86b662 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-656e86b662 FEDORA-2020-656e86b662 has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-656e86b662` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-656e86b662 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2020-c30055ffe4 has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-c30055ffe4` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-c30055ffe4 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2020-c30055ffe4 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report. |