Post 38 to 39 upgrade cannot launch QEMU/KVM VMs via virt-manager
by Ian Laurie
I upgraded a 38 workstation/server from 38 to 39. The only casualty so
far seems to be that virt-manager can no longer launch VMs.
Trying to do so results in this:
============================================
Error starting domain: Failed to connect socket to
'/var/run/libvirt/virtnetworkd-sock': No such file or directory
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 72, in
cb_wrapper
callback(asyncjob, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 108, in
tmpcb
callback(*args, **kwargs)
File "/usr/share/virt-manager/virtManager/object/libvirtobject.py",
line 57, in newfn
ret = fn(self, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/share/virt-manager/virtManager/object/domain.py", line
1402, in startup
self._backend.create()
File "/usr/lib64/python3.12/site-packages/libvirt.py", line 1373, in
create
raise libvirtError('virDomainCreate() failed')
libvirt.libvirtError: Failed to connect socket to
'/var/run/libvirt/virtnetworkd-sock': No such file or directory
============================================
Can anyone offer some insight before I create a BZ for this? I suspect
it is an upgrade issue maybe?
Thanks,
Ian
--
Ian Laurie
FAS: nixuser | IRC: nixuser
TZ: Australia/Sydney
8 months, 3 weeks
Preliminary Fedora Workstation Live image with installer Web UI
by Martin Kolman
Hi!
As the final switch of the Fedora Workstation Live image to using the new Anaconda Web UI by default[0] draws closer, we now have finally most of the building blocks in place & have created a test image, that should represent quite well how the actual Workstation Live image will look like after the switch:
https://fedorapeople.org/groups/anaconda/webui/temp/Fedora-Workstation_GI...
The installation flow is quite different from how it was on <=F38:
- the image boots into a Gnome Initial Setup running in a minimal Gnome Shell session[1]
- this GIS will ask the user to select language and keyboard, then provides an option to either install Fedora or try the Fedora desktop
- if the Install option is selected, the Anaconda Web UI will be started
- if the "try desktop" option is selected, the selected keyboard and language should be used for the desktop (on this image, only keyboard is used for some reason)
- using the Web UI, the user can configure partitioning & Fedora will be installed on the target system afterwards
- quitting the installer after successful installation will reboot the Live environment to the new system
- then Gnome Initial setup will start again, as usual during regular Fedora Workstation installations
- it will asks user to configure the remaining bits, like user, timezone or online accounts
- it will also ask again for language & keyboard - this is a known issue in process of being fixed
Some testing of this image will be much appreciated! :) Issues that are identified & fixed thanks to this can hopefully make the transition & overall F39 release into a smoother ride. :)
Please fill any issues you spot into Bugzilla, under the regular Fedora product and anaconda component & mark you new bugs as blocking on bug 2231339.
Bug 2231339[2] is the main tracking bug for the F39 WebUI effort & marking any relevant bugs as blocking on this bug will help us keep track of them.
You can also check the bugs blocking the tracker bugs to see if your issue has perhaps been already reported.
Thanks in advance & looking forward to your bug reports and general feedback. :)
Best Wishes
Martin Kolman
[0] https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation
[1] https://pagure.io/fedora-workstation/issue/362
[2] https://bugzilla.redhat.com/show_bug.cgi?id=2231339
8 months, 3 weeks
Re: Thoughts welcome: interface between automated test gating and
the "critical path"
by Adam Williamson
On Fri, 2022-09-02 at 08:37 +0000, Zbigniew Jędrzejewski-Szmek wrote:
> >
> > Now, because I glued openQA to the critpath because it was handy, there
> > are two sets of consequences to a package being in critical path:
> >
> > 1. Tighter Bodhi requirements
> > 2. openQA tests are run, and results gate the update (except Rawhide)
> >
> > So, one of the implicit questions here is, is it OK to keep twinning
> > these two sets of consequences, or should we split them up? Splitting
> > them up kinda implies answer 2) from my original mail: "Keep the
> > current "critical path" concept but define a broader group
> > of "gated packages" somewhere". Because we would then need some new
> > concept that isn't "critical path". As I said, that's more *work* -
> > it'd require us to write new code in several places[0]. Even if we
> > decide it'd be nice to do this, is it nice *enough* to be worth doing
> > that work?
>
> I'd still vote for keeping a single critpath list and using it as
> "the list of packages that require extra care and testing".
>
> As you describe, the original meaning of critpath has shifted, but
> it's because the way we do updates and QA has also shifted. Doing
> gating tests for a package seems much more useful than just keeping
> it longer in 'updates-testing' in hope that somebody discovers an
> important regresion in the second week.
Well, there's a caveat there - openQA doesn't test everything. On the
whole we cover quite a lot with the set of tests that gets run on
updates, but there's certainly lots of potential for there to be
important bugs it misses, that a human tester might catch. So I think
there is still a case for the higher karma requirements too.
>
> So yeah, I don't think it makes sense to do the extra work to split
> the concepts. Also because we have way too many concepts and processes
> in Fedora already.
On the whole, though, I agree with you. I just don't trust my own
opinion because it's obviously biased by what's convenient for me. :D
> > If we don't think it's worth doing that work, then we're kinda stuck
> > with openQA glomming onto the critpath definition to decide which
> > updates to test and gate, because I don't have any other current viable
> > choices for that, really. And we'd have to figure out a critpath
> > definition that's as viable as possible for both purposes.
> >
> >
> > BTW, one other thought I've had in relation to all this is that we
> > could enhance the current critpath definition somewhat. Right now, it's
> > built out of package groups in comps which are kinda topic-separated:
> > there's a critpath-kde, a critpath-gnome, a critpath-server, and so on.
> > But the generated critical path package list is a monolith: it doesn't
> > distinguish between a package that's on the GNOME critpath and a
> > package that's on the KDE critpath, you just get a big list of all
> > critpath packages. It might be nice if we actually did distinguish
> > between those - the critpath definition could keep track of which
> > critpath topic(s) a package is included in, and Bodhi could display
> > that information in the web UI and provide it via the API. That way
> > manual testers could get a bit more info on why a package is critpath
> > and what areas to test, and openQA could potentially target its test
> > runs to conserve resources a bit, though this might require a bit more
> > coding work on the gating stuff now I think about it.
>
> That sounds useful. We only need a volunteer to figure out the details
> and do the work ;)
I actually did a huge rewrite of the thing that generates the critpath
data this week, and it probably wouldn't be tooooo much work, honestly.
The most annoying bit would be the Bodhi frontend stuff, but that's
because I'm bad at frontend dev in general. :P But yeah, this is
definitely off in sky-castle land. I'll add it to my ever-growing list
of sky-castle projects to do when I get a couple of years of spare
time...
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
8 months, 3 weeks
Podman issue might be breaking toolbx anytime now
by Sumantro Mukherjee
Hey Folks!
This is to flag that there is an issue in Podman [0] which will break
Toolbx's basic
functionality in F37 and F38. Toolbx is currently release blocking and
is a part of
FCOS and Workstation ISO.
We are tracking the issue in [0] and request folks to test updates
when fixes are available.
[0] https://github.com/containers/podman/issues/19634
--
//sumantro
Fedora QE
TRIED AND PERSONALLY TESTED, ERGO TRUSTED
8 months, 3 weeks
Failing jobs for Rawhide (and F39?) in Fedora CI due to use of old
mock configs
by Adam Williamson
I've seen several folks report that jobs (usually scratch build tests)
are failing in Fedora CI, e.g. this one:
https://osci-jenkins-1.ci.fedoraproject.org/job/fedora-ci/job/dist-git-bu...
the failures all seem to have a common cause. You'll note these lines:
DEBUG: The GPG keys listed for the "fedora" repository are already installed but they are not correct for this package.
DEBUG: Check that the correct key URLs are configured for this repository.. Failing package is: curl-8.2.1-2.fc40.x86_64
DEBUG: GPG Keys are configured as: file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-39-primary, file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-39-primary, file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-38-primary
DEBUG: Public key for fedora-gpg-keys-40-0.1.noarch.rpm is not installed. Failing package is: fedora-gpg-keys-40-0.1.noarch
...for several packages. If you look carefully, you'll see it's using
the wrong GPG keys: it's using the keys for F38 and F39, trying to
validate a package from Rawhide. Obviously that will fail.
This is happening because CI is running EL 8, and the EPEL 8 mock/mock-
core-configs update for F39 branching is not yet stable:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-a5c155a6c0
the current stable mock-core-configs for EPEL 8 still thinks Rawhide is
F39, so that's why it tries to use the F39 and F38 GPG keys to validate
Rawhide packages. It needs the newer version of mock-core-configs that
knows Rawhide is now F40.
I've tried pinging CI folks about this to see if they can pull mock in
from updates-testing, but so far no response. I guess it would help if
folks running EPEL 8 can test mock, confirm it works, and up-karma the
update.
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net
9 months
DNF5 ~ How to "sudo dnf remove --oldinstallonly"
by Ian Laurie
In DNF5 how do you do this DNF4 style command?
sudo dnf remove --oldinstallonly
I'm guessing there must be a way but it's eluding me so far.
--
Ian Laurie
FAS: nixuser | IRC: nixuser
TZ: Australia/Sydney
9 months
DNF5 is in a bad state.
by Onyeibo
Good Morning
I ran an update on a second rawhide machine of mine (DNF5 broke the
other one and I have not reinstalled Fedora there). After this last
update, I get the following behaviour when I attempt another update:
# dnf update
bash: /usr/bin/dnf: No such file or directory
What I find most aggravating about DNF5 is the silence when it
encounters an issue. It moves with other things, giving the
impression that all is fine. It does not print any hint when it
encounters an issue until it finishes. When it is done, the user
discovers a huge mess.
This trend is frustrating for those wishing to file a report. What do
we say is wrong?
Finally ... which Rawhide image is reliable these days? I might need to
grab an image before I poweroff this laptop. I have little faith that
this update will allow my machine to boot. Afterall, there is no
telling at what stage DNF5 lost its way.
9 months
F39 Branching and update gating status
by Adam Williamson
Hey folks! Just a quick update on the state of update gating wrt
Branching.
First, distro-wide gating (that's gating on the openQA tests,
effectively) is not currently enabled for Rawhide. This is an artifact
of how gating works, but I'm leaving it that way for now as we know not
all tests are passing. I'll turn it on tomorrow. Please, uh, don't
submit anything broken. :D Most tests should pass on Rawhide updates,
but a few will fail, this cannot be resolved till we can build
branched-39 base images.
Second, F39 is gated, and many update tests currently don't pass. This
is known, and can't be resolved until the Branched compose is synced to
the mirror system and mirror manager includes f39 entries. I was hoping
to get that cleared up before going to bed but it looks like it'll have
to be in the morning now. (I'm also writing a guide so others can do
this in future, but it's a bit tricky as this is the first cycle where
we had Rawhide gating enabled going in, which changes things a bit).
If you have an F39 update that's stuck in gating, please just hang
tight and I'll make sure it gets sorted tomorrow somehow. Thanks!
On a related note, trying to deal with some updates that got stuck
caused me to find some more bugs in Bodhi test result display and
failure waiving:
https://pagure.io/fedora-qa/fedora_openqa/issue/107
https://pagure.io/waiverdb/issue/431
I've written fixes for both, but didn't want to push the result
reporting one out yet in case it has unexpected consequences, and the
waiverdb one will have to wait on a waiverdb admin to review it. Once
that is fixed, waiving failed tests that have chained dependencies
should work properly.
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net
9 months
