GNOME Bugzilla – Bug 709047
Booting from mounted ISOs & HW devices fails due to permission issues
Last modified: 2016-03-31 13:22:07 UTC
On Fedora 19, when I double-click on an ISO image, it is automatically mounted via the image mounter, and I get an autorun notification suggesting to open it in Boxes. But this fails saying "Connection to loop0 failed". If I start gnome-boxes from the console and create a box, choosing loop0 for source, I get the same error, and this message in the console: libvirt-machine.vala:78: Failed to fetch configuration for domain 'boxes-unknown': Unable to get domain XML config: Domain not found: no domain with matching uuid If I create a box using the ISO file itself as the source, everything works fine. I've found at least 3 people reporting the same error on Internet, mostly on Ubuntu. gnome-boxes is 3.8.4-2.fc19.x86_64
Likely permission issue. Can you check if you have read access to /dev/loop0 ?
You're right, /dev/loop0 is owned by the disk group on Arch Linux, and I didn't have read access. After adding myself to the disk group, I'm able to boot the loop device with GNOME Boxes. Maybe a more detailed error message would be useful in this case.
So maybe that's a problem for distributors? By default, gnome-boxes is proposed, but by default users cannot access /dev/loop0. Probably an issue for the archive mounter, which should set correct permissions. (ATM it crashes here on Fedora 20 so I cannot investigate the bug.)
(In reply to comment #2) > You're right, /dev/loop0 is owned by the disk group on Arch Linux, and I didn't > have read access. After adding myself to the disk group, I'm able to boot the > loop device with GNOME Boxes. Maybe a more detailed error message would be > useful in this case. The error message needs improvement for sure, see bug#688787. However we really need to solve the real issue so that this error doesn't occur in the first place. That however is not an easy task. I've talked to libvirt devs (at least one of them) and other Boxes devs but I haven't yet found a solution for this. One idea has been that Boxes can use a setuid helper to read the device and we pass an fd from this helper to qemu through libvirt. At the time this idea was proposed, this fd passing mechanism was new in Qemu and libvirt patches were not yet merged (1.5 years ago). Hopefully that work is all merged now and its all a matter of someone getting around to implementing this.
(In reply to comment #3) > So maybe that's a problem for distributors? By default, gnome-boxes is > proposed, but by default users cannot access /dev/loop0. No, its not distro-specific afaict as /dev/loop0 has same permissions on Fedora 20 here. I agree that until Boxes has some solution for this, the choice of Boxes should not be presented if user doesn't have read permissions on disk.
OK, glad to know you've a longer term plan.
Given that, * "Open in Boxes" is no longer presented to user since 3.10 and Boxes no longer claims to be able to handle bootable media devices. * User has the option to select the ISO (or device if its readable to user) from a menu in Boxes (or through file selection). * Its unlikely we'll be able to fix it. I'm marking this as WONTFIX. Please feel free to reopen this if anyone has any concrete ideas on how to fix this without adding too much complexity to Boxes and especially if you can also provide patches.