GNOME Bugzilla – Bug 748043
Errors from gnome-boxes are fairly useless
Last modified: 2018-01-11 10:16:18 UTC
I understand the need to not overwhelm the user with error messages that may be very much too obscure, but I fully expect people using a virtual machine image to be at least moderately aware of what error messages are. Current, when Boxes fails to run a VM, it shows a *deeply* unhelpful error message that is the equivalent of: "You wanted to run this VM? Well, tough". This is vaguely patronizing, and wholly unhelpful to diagnose the issue. Yes, I know: look in the journal. Troubleshooting issues should not require me to physically wrestle control of somebody else's machine, launch the terminal, and go through the logs generated by gnome-boxes. It shouldn't even require *me* from doing that. This is not GNOME Music: this is Boxes. While not a full on power tool, it's still something that requires a bit of knowledge. I think that progressive disclosure of the error message, with the ability to copy it to the clipboard for reporting it, would be majorly helpful. At least, more helpful than just "Failed to start ${machine_name}".
Having a "see details" link in the error message go to the filtered view Logs* might be nice. * https://wiki.gnome.org/Design/Apps/Logs
(In reply to Emmanuele Bassi (:ebassi) from comment #0) > I understand the need to not overwhelm the user with error messages that may > be very much too obscure, but I fully expect people using a virtual machine > image to be at least moderately aware of what error messages are. Not really, no. See bug#748194 where Jeff (who I'm sure has more than moderate level of understanding of a Linux system) doesn't know what KVM is. > I think that progressive disclosure of the error message, with the ability > to copy it to the clipboard for reporting it, would be majorly helpful. At > least, more helpful than just "Failed to start ${machine_name}". I think we more need a simple UI to report the bug with Boxes collecting all logs it can. This is true for other apps too by the way. So maybe a glib/gtk+ api for that would be cool. Anyway, "Failed to start VM" could mean many different things, some of which would actually be nice to present to user, while others not. If you see your terminal and see an error message that you think should be exposed to user, please do let me know and I will definitely consider exposing it. But in general, when this happens, Boxes is simply useless for them and the best they can do anyway is to report the bug and when they do, we can inform them on how to collect information that we'd need to fix it for them.
(In reply to Zeeshan Ali (Khattak) from comment #2) > (In reply to Emmanuele Bassi (:ebassi) from comment #0) > > I understand the need to not overwhelm the user with error messages that may > > be very much too obscure, but I fully expect people using a virtual machine > > image to be at least moderately aware of what error messages are. > > Not really, no. See bug#748194 where Jeff (who I'm sure has more than > moderate level of understanding of a Linux system) doesn't know what KVM is. I'm not saying that we should just dump the KVM errors to the user and call it a day, that's why I said: > > I think that progressive disclosure of the error message, with the ability > > to copy it to the clipboard for reporting it, would be majorly helpful. At > > least, more helpful than just "Failed to start ${machine_name}". There are various steps in the continuum between "generic, completely unhelpful error message" and "drop a bunch on unintelligible errors on the user, and let their unborn god sort them out". Something along the lines of: "descriptive error, with the quick ability to get to the source for the technologically minded". > I think we more need a simple UI to report the bug with Boxes collecting all > logs it can. This is true for other apps too by the way. So maybe a > glib/gtk+ api for that would be cool. I doubt this is possible to do at the toolkit level, but it's certainly something to take into account when in-app notifications land in GTK; being able to to add more information to a notification bar is a good feature to have. > Anyway, "Failed to start VM" could mean many different things, some of which > would actually be nice to present to user, while others not. If you see your > terminal and see an error message that you think should be exposed to user, > please do let me know and I will definitely consider exposing it. But in > general, when this happens, Boxes is simply useless for them and the best > they can do anyway is to report the bug and when they do, we can inform them > on how to collect information that we'd need to fix it for them. That'd be my point: I could not report a bug based on the "failed to start" error. It's useless — actually, worse than useless: it's so ridiculous it's almost infuriating. I *know* the VM failed to start, given that I was not looking at a running VM. What I would have liked to know was the condition that led to the error. Does libvirt report errors categorized by some form of enumeration, like a GError domain? Can you do matching to determine what type of error you got at a higher layer like Boxes? For instance: if I get a "cannot set up guest memory 'pc.ram'" I don't expect to see that error in the UI; what I do expect is an error message that says: "We don't have enough resources to start the VM; try closing some other application, and retry". What I expect, in short, from Boxes is to intercept classes of errors coming from libvirt and present them to the user in a way that is actionable for the user to do something about them. This would also be helpful for you, since you would not: * get random bugs saying "I could not start my VM" * have to go through 20 questions to get to the journal log with the user to determine *what* the message was Because nothing like this will *ever* scale. Considering how brittle the whole thing is, starting from QEmu, up to libvirt, and finally to Boxes, I suspect the only reason why you don't get a ton of random bugs already is because not many people use VMs — *yet*.
(In reply to Emmanuele Bassi (:ebassi) from comment #3) > > Anyway, "Failed to start VM" could mean many different things, some of which > > would actually be nice to present to user, while others not. If you see your > > terminal and see an error message that you think should be exposed to user, > > please do let me know and I will definitely consider exposing it. But in > > general, when this happens, Boxes is simply useless for them and the best > > they can do anyway is to report the bug and when they do, we can inform them > > on how to collect information that we'd need to fix it for them. > > That'd be my point: I could not report a bug based on the "failed to start" > error. It's useless — actually, worse than useless: it's so ridiculous it's > almost infuriating. > > I *know* the VM failed to start, given that I was not looking at a running > VM. > > What I would have liked to know was the condition that led to the error. You (in particular) might find that useful but most users won't. > Does libvirt report errors categorized by some form of enumeration, like a > GError domain? Can you do matching to determine what type of error you got > at a higher layer like Boxes? libvirt does but libvirt-glib doesn't translate them to specific GError currently. It really should! > For instance: if I get a "cannot set up guest memory 'pc.ram'" I don't > expect to see that error in the UI; what I do expect is an error message > that says: "We don't have enough resources to start the VM; try closing some > other application, and retry". As I said there are various cases and knowing about them all in advance and handling them differently, implies a lot of work and I still won't be able to cover them all.. Keeping in mind that such issues are usually happening because of some bug in the lower layers or distro, or (worse) some users trying to be smart and fiddling with stuff they know nothing about, it's hard to be motivated to put a lot of work on handling them all.. > What I expect, in short, from Boxes is to intercept classes of errors coming > from libvirt and present them to the user in a way that is actionable for > the user to do something about them. I agree but I will only add handling based on issues that actually realize and I get bugs for them. Patches would help change that of course. :) > This would also be helpful for you, since you would not: > > * get random bugs saying "I could not start my VM" > * have to go through 20 questions to get to the journal log with the user > to determine *what* the message was > > Because nothing like this will *ever* scale. Actually, there is a 'Troubleshoot log' in the properties view that you can get most details from already. I'm fine with getting such bugs and I'm sure I can write a template message to ask for details if I start getting too many of these to handle. :)
(In reply to Zeeshan Ali (Khattak) from comment #4) > (In reply to Emmanuele Bassi (:ebassi) from comment #3) > > Does libvirt report errors categorized by some form of enumeration, like a > > GError domain? Can you do matching to determine what type of error you got > > at a higher layer like Boxes? > > libvirt does but libvirt-glib doesn't translate them to specific GError > currently. It really should! Actually I don't see any libvirt error that could/should be exposed to users: http://libvirt.org/html/libvirt-virterror.html#virErrorNumber and at least nothing specific to this case. Besides the Troubleshoot log already contains the Qemu log so that should provide you all details, really. Maybe the only thing to do would be to provide a button to jump to trouble shooting log from the failure notification?
What's the "Troubleshoot log"? You mean launching gnome-logs with a specific filter to show only boxed/libvirt/qemu errors? Can it be done? If so, it'd be great to have a button that lets you do so! If this is not what you're saying then I'm still going to ask for human *readable* and *actionable* errors in the UI; you're pandering to a largely non-existent user base that has no idea what a VM is or does and yet managed to run a full emulator, with this generic errors; simultaneously, you're ensuring that people most in favour of using Boxes will move to VirtualBox or virt-manager whenever something bad happens and the only thing they can do is drop to a terminal and divine the meaning of the libvirt error messages by themselves.
(In reply to Emmanuele Bassi (:ebassi) from comment #6) > What's the "Troubleshoot log"? You mean launching gnome-logs with a specific > filter to show only boxed/libvirt/qemu errors? No, the "Troubleshooting log" button in properties view on 'System' tab. It shows very technical info. > If this is not what you're saying then I'm still going to ask for human > *readable* Sure, as I've said before (in here and elsewhere when this issue is raised) but there is only a handfull of cases that I can make make readable for most people. > you're pandering to a largely > non-existent user base that has no idea what a VM is or does and yet managed > to run a full emulator, They are not non-existent and they likely know what a VM is but I do not want to expose details like libvirt (and especially what a domain is and what does xml configuration imply) and qemu etc. All these details are available through throubleshooting log. > with this generic errors; simultaneously, you're > ensuring that people most in favour of using Boxes will move to VirtualBox > or virt-manager whenever something bad happens and the only thing they can > do is drop to a terminal and divine the meaning of the libvirt error > messages by themselves. Many of the errors actually result from distro issues or bugs in lower layers, that we (as in Boxes) nor user can do much about anyway and since virt-manager uses the same infra, access to more detailed error message is all they'll get. Don't expect the errors in there to be very readable either. Anyway, all I'm saying is that it would certainly be a good idea to show some of the errors to user in a readable format and if possible, make them actionable but it's not a good idea to target all (or even most) of the errors, ignoring the amount of work that will be needed and size of Boxes developers team. :)
FWIW, we have this unwieldy thing in totem to translate the "unhelpful" GStreamer errors into user visible ones: https://git.gnome.org/browse/totem/tree/src/backend/bacon-video-widget.c#n3762 So, as long as the errors *are* reported, you could do something with them. I mean, I'm searching for HTTP error codes in the untranslated messages, I'm not sure that libvirt-glib could be that much worse.
(In reply to Bastien Nocera from comment #8) > FWIW, we have this unwieldy thing in totem to translate the "unhelpful" > GStreamer errors into user visible ones: > https://git.gnome.org/browse/totem/tree/src/backend/bacon-video-widget. > c#n3762 > > So, as long as the errors *are* reported, you could do something with them. > I mean, I'm searching for HTTP error codes in the untranslated messages, I'm > not sure that libvirt-glib could be that much worse. Well they *are* reported on the console. If you are geek enough to search for error codes on the web, you are geek enough to run it from a terminal. :)
(In reply to Zeeshan Ali (Khattak) from comment #9) > (In reply to Bastien Nocera from comment #8) > > FWIW, we have this unwieldy thing in totem to translate the "unhelpful" > > GStreamer errors into user visible ones: > > https://git.gnome.org/browse/totem/tree/src/backend/bacon-video-widget. > > c#n3762 > > > > So, as long as the errors *are* reported, you could do something with them. > > I mean, I'm searching for HTTP error codes in the untranslated messages, I'm > > not sure that libvirt-glib could be that much worse. > > Well they *are* reported on the console. If you are geek enough to search > for error codes on the web, you are geek enough to run it from a terminal. :) How about you massage them with the in-app context to provide some useful error messages? Things like missing disk/disc images would be a good place to start.
(In reply to Bastien Nocera from comment #10) > (In reply to Zeeshan Ali (Khattak) from comment #9) > > (In reply to Bastien Nocera from comment #8) > > > FWIW, we have this unwieldy thing in totem to translate the "unhelpful" > > > GStreamer errors into user visible ones: > > > https://git.gnome.org/browse/totem/tree/src/backend/bacon-video-widget. > > > c#n3762 > > > > > > So, as long as the errors *are* reported, you could do something with them. > > > I mean, I'm searching for HTTP error codes in the untranslated messages, I'm > > > not sure that libvirt-glib could be that much worse. > > > > Well they *are* reported on the console. If you are geek enough to search > > for error codes on the web, you are geek enough to run it from a terminal. :) > > How about you massage them with the in-app context to provide some useful > error messages? As I've said before, some errors will be easily translatable to something friendly to user (as long as we don't have to expose internal details). >Things like missing disk/disc images would be a good place > to start. Yeah, that is very much an internal detail in my opinion, especially after we add OVF support.
(In reply to Zeeshan Ali (Khattak) from comment #11) > (In reply to Bastien Nocera from comment #10) <snip> > >Things like missing disk/disc images would be a good place > > to start. > > Yeah, that is very much an internal detail in my opinion, especially after > we add OVF support. Not when you boot live images as I do regularly.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-boxes/issues/51.