I mentioned this in a QA meeting, and have given it enough testing that I think it's broadly usable. If desired it can be copied out of my user account and put up somewhere where QA folks will see it and can modify it as issues or improvements are discovered.
What is it? The idea is to produce a system that can confidently be used for baremetal testing, without risking the primary operating system. While VM's are a great way to test, it's also a really idealized environment that tends to not expose an assortment of bugs that affect particular hardware. But then quite a lot of folks reasonably don't want to upgrade their daily use hardware early on, because they don't want to always have to debug things, or have to figure out how to undo the upgrade if it really goes badly.
Therefore, I present a dual-boot setup offering:
* no re-partitioning;
* no installation step, instead system upgrade is used;
* reversibility, or undoability, i.e. with just a few steps you can delete the "test OS".
Hi folks! I want to apologize to packagers who have Rawhide updates
stuck on failed openQA tests, and provide an update.
There were two big problems today. First, the Server base disk image
used for some of the tests got regenerated (this happens weekly).
Unfortunately, this meant it got affected by
https://bugzilla.redhat.com/show_bug.cgi?id=2259266 , and no longer
booted. I should have got that grub2 build untagged or the change
reverted sooner - sorry. I was expecting the package to be fixed sooner,
and it didn't occur to me that this image being regenerated was a risk.
I've now got the package untagged, and forced a rebuild of the disk
image using a grub2 build with the patch re-applied (otherwise I'd have
had to wait for the next Rawhide compose to rebuild the image). I'm now
working through re-running all affected tests.
Second, shell-color-prompt was changed to apply the color prompt to
virtual consoles. This broke a large number of openQA tests, as they
often need to do things at root consoles, and to do that they need to
know when they've actually managed to log in to one, and they do this by
screen matching the prompt. Any test which needed to know it was at a
root console was failing. I've updated the 'needle' to match the color
prompt, and am re-running all affected tests.
I anticipate the mess should be cleaned up in about three or four hours
(there are a lot of failures to re-run, and some of the tests take a
while to run). Sorry again for the inconvenience.
I'll probably propose adding shell-color-prompt to the critical path.
That would mean openQA would have gated the update (allowing me to
update the needles *before* it got pushed and broke tests for every
other update), but it also just seems appropriate - theoretically, a bad
change to the package could cause all sorts of consequences, since it
fiddles with the default prompt.
Adam Williamson (he/him/his)
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
Testing Rawhide in a virtual machine. I have a repo file on a usb that
collects all the rpms. DNF complains if the repo is not available but
does not load the rpms. Is there some setting to get the repo processed?
For a while now when I down load a new drop of Fedora Rawhide x86_64
Workstation to test there are two. One has "osb" in the name. Please pardon
my ignorance, but what does osb stand for and how is it different?
Have a Great Day!
I would like to invite all of you to participate in the Kernel 6.7
Test week is happening from 2024-01-21 to 2024-01-28. It's
fairly simple, head over to the wiki  and read in detail about the
test week and simply run the test case mentioned in and enter your
As usual, the Fedora QA team will hangout at #fedora-test-day(a)libera.chat
for questions and discussion.
Happy New Year :)
TRIED AND PERSONALLY TESTED, ERGO TRUSTED