Bug 1753985 - Gnome-Boxes cannot connect to Virtualization Backend
Summary: Gnome-Boxes cannot connect to Virtualization Backend
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-boxes
Version: 31
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Christophe Fergeau
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-09-20 12:49 UTC by Lukas Ruzicka
Modified: 2020-11-24 20:00 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-11-24 20:00:35 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
The error in Boxes, screenshot. (21.74 KB, image/png)
2019-09-20 12:49 UTC, Lukas Ruzicka
no flags Details
Logs from OpenQA (1.76 MB, application/gzip)
2019-09-20 12:49 UTC, Lukas Ruzicka
no flags Details

Description Lukas Ruzicka 2019-09-20 12:49:03 UTC
Created attachment 1617205 [details]
The error in Boxes, screenshot.

Description of problem:

Today, I realized that our OpenQA instance reported a failure in Gnome Boxes, which could not connect the virtualization backend. 

Version-Release number of selected component (if applicable):

Fedora 31 compose 20190919.

How reproducible:

Always

Steps to Reproduce:
1. Run Boxes and wait for it.

Actual results:

Boxes cannot be used.

Expected results:

Connection with libvirt is established and Boxes work.

Additional info:

I have not reproduced this yet locally, so I am only including log files from the test suite. I will try to reproduce it on my machine and file anything useful later.

Comment 1 Lukas Ruzicka 2019-09-20 12:49:45 UTC
Created attachment 1617206 [details]
Logs from OpenQA

Comment 2 Fedora Blocker Bugs Application 2019-09-20 12:51:20 UTC
Proposed as a Blocker for 31-final by Fedora user lruzicka using the blocker tracking app because:

 I am proposing this as a blocker, because it violates the Application Criteria. Boxes are a core application, which must always work.

Comment 3 Lukas Ruzicka 2019-09-20 13:48:32 UTC
Hmm. Another run of the OpenQA test showed that Boxes without issue. So this does not look so bad. Maybe, it just was a race condition of some sort.

Comment 4 Lukas Ruzicka 2019-09-20 13:49:25 UTC
s/Boxes without/Boxes started without/

Comment 5 Jonathan Haas 2019-09-21 07:03:47 UTC
Boxes works fine on my Dell XPS 13 system with Fedora 31 beta. Doesn't seem to be a general issue.

Comment 6 Felipe Borges 2019-09-23 11:52:03 UTC
I am not able to reproduce the issue either. Any ideas what I could do to simulate the conditions where the bug happens?

Comment 7 Chris Murphy 2019-09-23 17:22:10 UTC
I used it all last week, this bug surprises me.

Comment 8 Geoffrey Marr 2019-09-23 17:49:59 UTC
Discussed during the 2019-09-23 blocker review meeting: [0]

The decision to classify this bug as a "RejectedBlocker" was made as this only happened once in openQA and no-one has reproduced it manually, so it just seems like a one-off blip for now and that doesn't violate the criteria. It can be re-proposed if we find a way to reproduce it reliably.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2019-09-23/f31-blocker-review.2019-09-23-16.03.txt

Comment 9 Koustubh Sinkar 2020-05-02 20:03:53 UTC
I too faced this bug.  Here the `journalctl -xe` output

```
-- The job identifier is 16063.
May 02 21:23:48 up.signal.black.beauty libvirtd[822267]: libvirt version: 6.1.0, package: 2.fc32 (Fedora Project, 2020-03-24-15:45:44, )
May 02 21:23:48 up.signal.black.beauty libvirtd[822267]: hostname: localhost.localdomain
May 02 21:23:48 up.signal.black.beauty gnome-boxes[822188]: Error setting up default broker: Failed to start storage pool: cannot open >
May 02 21:23:48 up.signal.black.beauty libvirtd[822267]: cannot open directory '$HOME/.local/share/gnome-boxes/images': No such>
May 02 21:23:48 up.signal.black.beauty gnome-boxes[822188]: (src/25a6634@@gnome-boxes@exe/app.c:3421):boxes_app_setup_default_source_co>
May 02 21:23:48 up.signal.black.beauty audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t>
May 02 21:23:48 up.signal.black.beauty systemd[1]: Started Hostname Service.
-- Subject: A start job for unit systemd-hostnamed.service has finished successfully
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- A start job for unit systemd-hostnamed.service has finished successfully.
-- 
-- The job identifier is 16063.
May 02 21:23:48 up.signal.black.beauty gnome-boxes[822188]: g_file_new_for_uri: assertion 'uri != NULL' failed
May 02 21:23:48 up.signal.black.beauty gnome-boxes[822188]: g_file_get_basename: assertion 'G_IS_FILE (file)' failed
May 02 21:23:48 up.signal.black.beauty gnome-boxes[822188]: g_file_new_for_uri: assertion 'uri != NULL' failed
May 02 21:23:48 up.signal.black.beauty gnome-boxes[822188]: g_file_get_basename: assertion 'G_IS_FILE (file)' failed
```

Just upgraded to Fedora 32.

Comment 10 Ben Cotton 2020-11-03 16:53:18 UTC
This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 11 Ben Cotton 2020-11-24 20:00:35 UTC
Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.