Hey folks!
So we're in freeze for Fedora 37 Beta now, and the first go/no-go
meeting should be on September 8.
It would be really great if we can get the validation tests run now so
we can find any remaining blocker bugs in good time to get them fixed.
Right now the blocker list looks short, but there are definitely some
tests that have not been run.
You can use the testcase_stats view to find tests that need running:
https://openqa.fedoraproject.org/testcase_stats/37/
For each validation test set (Base, Desktop etc.) it shows when each
test was last performed. So you can easily look for Basic and Beta
tests that have not yet been run. We need to run all of these.
You can enter results using `relval report-results`, or edit the
summary results page at
https://fedoraproject.org/wiki/Test_Results:Current_Summary . That's a
redirect link which will always point to the validation results page
for the currently-nominated compose, which right now is 20220826.n.0.
Sumantro will be running a validation 'test week' starting on
Wednesday, so you can drop by the Fedora Test Day room on
chat.fedoraproject.org to hang out with other testers and get any help
you need in testing. See
https://lists.fedoraproject.org/archives/list/test-announce@lists.fedorapro…
for that announcement.
Thanks folks!
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
Dear all,
You are kindly invited to the meeting:
Fedora Cloud Workgroup on 2022-09-01 from 15:00:00 to 16:00:00 UTC
At fedora-meeting-1(a)irc.libera.chat
The meeting will be about:
Standing meeting for the Fedora Cloud Workgroup
Source: https://calendar.fedoraproject.org//meeting/1999/
Hey folks! I apologize for the wide distribution, but this seemed like
a bug it'd be appropriate to get a wide range of input on.
There's a bug that was proposed as an F37 Beta blocker:
https://bugzilla.redhat.com/show_bug.cgi?id=1907030
it's quite an old bug, but up until recently, the summary was
apparently accurate - dnf would run out of memory with 512M of RAM, but
was OK with 1G. However, as of quite recently, on F36 at least (not
sure if anyone's explicitly tested F37), dnf operations are commonly
failing on VMs/containers with 1G of RAM due to running out of RAM and
getting OOM-killed.
There's some discussion in the bug about what might be causing this and
potential ways to resolve it, and please do dig into/contribute to that
if you can, but the other question here I guess is: how much do we care
about this? How bad is it that you can't reliably run dnf operations on
top of a minimal Fedora environment with 1G of RAM?
This obviously has some overlap with our stated hardware requirements,
so here they are for the record:
https://docs.fedoraproject.org/en-US/fedora/latest/release-notes/welcome/Ha…
that specifies 2GB as the minimum memory for "the default
installation", by which I think it's referring to a default Workstation
install, though this should be clarified. But then there's a "Low
memory installations" boxout, which suggests that "users with less than
768MB of system memory may have better results performing a minimal
install and adding to it afterward", which kinda is recommending that
people do exactly the thing that doesn't work (do a minimal install
then use dnf on it), and implying it'll work.
After some consideration I don't think it makes sense to take this bug
as an F37 blocker, since it already affects F36, and that's what I'll
be suggesting at the next blocker review meeting. However, it does seem
a perfect candidate for prioritized bug status, and I've nominated it
for that.
I guess if folks can chime in with thoughts here and/or in the bug
report, maybe a consensus will emerge on just how big of an issue this
is (and how likely it is to get fixed). There will presumably be a
FESCo ticket related to prioritized bug status too.
Thanks folks!
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
Cancelling the meeting today because devconf_us is going on. If you have pressing business, The meeting time is available still for cloud-sig business and if you feel like there is something you need to discuss, please follow the guidelines in the README.md from the cloud repository: https://pagure.io/cloud-sig
David Duncan | Partner Solutions Architect
Dear all,
You are kindly invited to the meeting:
Fedora Cloud Workgroup on 2022-08-18 from 15:00:00 to 16:00:00 UTC
At fedora-meeting-1(a)irc.libera.chat
The meeting will be about:
Standing meeting for the Fedora Cloud Workgroup
Source: https://calendar.fedoraproject.org//meeting/1999/
cc: cloud@, server@ fpo
Hi,
When troubleshooting early boot issues with a console, e.g. virsh console, or the virt-manager console, or even a server's remote management console providing a kind of virtual serial console... the boot scroll is completely wiped. This is a new behavior in the last, I'm not sure, 6-12 months? Everything before about 3 seconds is cleared as if the console reset command was used, as in it wipes my local scrollback.
I captured this with the script command, and when I cat this 76K file, it even wipes the local console again. So there is some kind of control character that's ordering my local console to do this. The file itself contains the full kernel messages. I just can't cat it. I have to open it in a text editor that ignores this embedded console reset command.
With the help of @glb, we discovered that this is almost certainly Plymouth. When I boot with parameter plymouth.enable=0 the problem doesn't happen. And hence the higher level question if we really even need Plymouth in Server or Cloud editions?
I suppose ideally we'd track down the problem and fix plymouth, so that existing installations get fixed. Whereas if we remove plymouth, we have to ponder whether and how to remove plymouth from existing installations. Unless we flat out aren't using it at all.
Any ideas?
Plymouth is in the @core group in fedora-comps, so pretty much everything gets it.
https://pagure.io/fedora-comps/blob/main/f/comps-f37.xml.in#_635
--
Chris Murphy