Bug 848440
| Summary: | (gnome-boxes:9436): Boxes-WARNING **: app.vala:233: Unable to open qemu+unix:///session: no connection driver available for No connection for URI qemu:///session | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Martin <mholec> | ||||
| Component: | gnome-boxes | Assignee: | Christophe Fergeau <cfergeau> | ||||
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | urgent | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | rawhide | CC: | berrange, cfergeau, marcandre.lureau, tpelka, vbenes, virt-maint, zeenix | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2012-08-20 13:46:09 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: |
|
||||||
The libvirt issue is fixed in libvirt-0.10.0-0rc0.2.fc18 (see bug 842068) Thanks Daniel for the pointer, this leaves "Anyway Boxes should notify user in GUI about connection error" Another error which should be handled in GUI: (gnome-boxes:2670): Boxes-WARNING **: libvirt-machine.vala:533: Failed to start 'fedora17': Unable to start domain: cannot access file '/home/mholec/Stažené/Fedora-17-x86_64-DVD.iso': No such file or directory (In reply to comment #2) > Thanks Daniel for the pointer, this leaves "Anyway Boxes should notify user > in GUI about connection error" As I have said before, broken installations are not something I'm interested in annoying the user with in the UI. As long as we dump enough information on the log to be able to figure out the issue (as was done on this bug), there is nothing else Boxes should be doing. (In reply to comment #3) > Another error which should be handled in GUI: > > (gnome-boxes:2670): Boxes-WARNING **: libvirt-machine.vala:533: Failed to > start 'fedora17': Unable to start domain: cannot access file > '/home/mholec/Stažené/Fedora-17-x86_64-DVD.iso': No such file or directory If this happens during installation, its very rare for user to delete the ISO immediately after choosing it in the wizard (and its very much user error). If this happened after installation, something must have gone wrong (libvirt events not getting it e.g) and VM was not marked as installed and the ISO was therefore not marked as optional. Anyways, I don't think this error belong in the UI either and if you disagree, please open a different bug so we discuss it there as its unrelated to this bug. *** This bug has been marked as a duplicate of bug 842068 *** (In reply to comment #4) > (In reply to comment #2) > > Thanks Daniel for the pointer, this leaves "Anyway Boxes should notify user > > in GUI about connection error" > > As I have said before, broken installations are not something I'm interested > in annoying the user with in the UI. As long as we dump enough information > on the log to be able to figure out the issue (as was done on this bug), > there is nothing else Boxes should be doing. Frozen Boxes when starting is lot more annoying for user then polite error notification in GUI. It is an exception and it should be handled properly instead of just freezing an application. (In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #2) > > > Thanks Daniel for the pointer, this leaves "Anyway Boxes should notify user > > > in GUI about connection error" > > > > As I have said before, broken installations are not something I'm interested > > in annoying the user with in the UI. As long as we dump enough information > > on the log to be able to figure out the issue (as was done on this bug), > > there is nothing else Boxes should be doing. > Frozen Boxes when starting is lot more annoying for user then polite error > notification in GUI. It is an exception and it should be handled properly > instead of just freezing an application. Boxes is broken in this case and its very unrecoverable system-level error that I don't expect end-users to be able to do anything about. There is no point in showing them an error. In either case, they'll simply decide not to use boxes (at least for a while) and turn to some alternatives. At best they might file a bug and thats where we'll need more debug on the console.. Things like these should not happen in the first place. Thats what we must focus on. (In reply to comment #6) > Things like these should not happen in the first place. Thats what we must > focus on. We'll be doing our best to make sure libvirt/selinux/... never break, but so far breakages have unfortunately happened from time to time. So we can stick our heads in the sand, and keep saying 'these breakages should not happen'. Or we can accept that real world is far from being perfect, and fail gracefully when bad things happen (even if it means we display a fail-whale-like screen) instead of freezing/crashing/... which makes us look even worse to the user. (In reply to comment #7) > (In reply to comment #6) > > > Things like these should not happen in the first place. Thats what we must > > focus on. > > We'll be doing our best to make sure libvirt/selinux/... never break, but so > far breakages have unfortunately happened from time to time. When things break, we fix them! Thats it. We have argued about this a lot in the past and we both have failed to convince each other so we both should move on and let eachother decide the approach for projects are responsible for. (In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > > > > Things like these should not happen in the first place. Thats what we must > > > focus on. > > > > We'll be doing our best to make sure libvirt/selinux/... never break, but so > > far breakages have unfortunately happened from time to time. > > When things break, we fix them! Thats it. Of course we do want to fix them, but between the time the breakage is reported and the time the fix gets to users' machines, boxes looks bad... And honestly, all this discussion really feels like "should developers handle errors in their code?", which I still hope we can agree on... |
Created attachment 604629 [details] gdb log Description of problem: Gnome Boxes starts, but with frozen GUI. (gnome-boxes:9436): Boxes-WARNING **: app.vala:233: Unable to open qemu+unix:///session: no connection driver available for No connection for URI qemu:///session Version-Release number of selected component (if applicable): gnome-boxes-3.5.5-1.fc18.x86_64 libvirt-0.10.0-0rc0.fc18.x86_64 How reproducible: always Steps to Reproduce: 1. Run gnome-boxes Actual results: Boxes is frozen after start. Expected results: Boxes should work. Anyway Boxes should notify user in GUI about connection error. Additional info: ps aux|grep libvirt root 1077 0.0 0.3 485460 13976 ? Ssl 09:03 0:00 /usr/sbin/libvirtd nobody 1215 0.0 0.0 13100 732 ? S 09:03 0:00 /sbin/dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/default.pid --conf-file= --except-interface lo --listen-address 192.168.122.1 --dhcp-range 192.168.122.2,192.168.122.254 --dhcp-leasefile=/var/lib/libvirt/dnsmasq/default.leases --dhcp-lease-max=253 --dhcp-no-override nobody 1256 0.0 0.0 13100 736 ? S 09:03 0:00 /sbin/dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/virtbridge.pid --conf-file= --except-interface lo --listen-address 192.168.100.1 --dhcp-range 192.168.100.128,192.168.100.254 --dhcp-leasefile=/var/lib/libvirt/dnsmasq/virtbridge.leases --dhcp-lease-max=127 --dhcp-no-override mholec 9269 0.3 0.3 583692 12492 ? Sl 11:33 0:00 /usr/sbin/libvirtd --timeout=30 root 9413 0.0 0.0 109188 996 pts/0 S+ 11:35 0:00 grep --color=auto libvirt