test October 2023

test@lists.fedoraproject.org

25 participants
29 discussions

Session defaults to X11 after reboot in the 39 beta.
by Scott Lembcke 20 Oct '23

20 Oct '23

So I just put a fresh install of the F39 beta on a Ryzen 7840U laptop (Framework 14). Everything is up to date as of Oct 20th. The issue: after booting the laptop and logging in, it defaults to an X11 session even though "Gnome" is selected from the gear menu in the lower right. To get a Wayland session, all I need to do is log out and immediately log back in. It only seems to do this after a fresh boot. I don't know enough about GDM to debug this any further and make a proper bug report. Is there a particular log file I should look into?

3 2

Failed to start udisks2.service
by camiro pan 20 Oct '23

20 Oct '23

Hello everybody, i run fedora 38 on my dell xps 9300 and want to install Fedora 39 beta/nightly. When i boot from a Fedora 39 (nightly) boot device i get the error message: "[Failed] Failed to start udisks2.service - Disk Manager". After that error message, the Gnome desktop starts normaly and usullay (not every time) the window with the button "install fedora" appears. Clicking on the install button loads the installer, but before it launches an error message appears and closes immediatly, so i can not report or see the error log. The output of "systemctl status udisks2.service" is " udisks daemon version 2.10.1 starting *** stack smashing detected ***: terminated udisks2.service: Main process exited, code=dumped, status=6/ABRT udisks2.service: Failed with result 'core-dump'. Failed to start udisks2.service - Disk Manager. " this happens to all version of fedora with udisks v2.10.1, so fedora-rawhide, fedora 39 beta and fedora 39 nightly. After searching for this issue, i found out that udisks v2.10.1 has a dependency on libblockdev and since fedora rawhide comes with the newer version libblockdev 3.0.4-1.fc40, i was hoping that this fix the issue. Unfortunaly, as i mention, it doesn't. I'm pretty sure that the fedora installer crashs because of the udisks error.

2 3

anyone available to test x86_64 macOS dual boot?
by Kamil Paral 18 Oct '23

18 Oct '23

It would be great if somebody could test Fedora 39 dual boot on a macOS device, because our internal team currently doesn't have hardware to do so. It needs to be an older x86_64 Mac (Macbook, Mac Mini, etc), the newer M-based Macs are not yet supported by Fedora. Is here anyone who has access to such a device and willing to test it? The testcase is here: https://fedoraproject.org/wiki/QA:Testcase_dualboot_with_macOS The install media (preferably Workstation or KDE Live) can be downloaded from here: https://fedoraproject.org/wiki/Test_Results:Fedora_39_Branched_20231014.n.0… And the test result can be reported here (next to "QA:Testcase_dualboot_with_macOS"): https://fedoraproject.org/wiki/Test_Results:Fedora_39_Branched_20231014.n.0… (or here to the list, of course) Thanks!

2 2

2023-10-16 @ 15:00 UTC - Fedora QA Meeting
by Adam Williamson 16 Oct '23

16 Oct '23

# Fedora Quality Assurance Meeting # Date: 2023-10-16 # Time: 15:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: ** #fedora-meeting on irc.libera.chat ** Greetings testers! It's time for another QA meeting. As usual lately, please note this meeting will really be *on IRC*. The Matrix bridge is still down and the meeting bot for Matrix is not quite done yet. So please use an IRC client or the web client - https://web.libera.chat/#fedora-meeting - to join. If anyone has any other items for the agenda, please reply to this email and suggest them! Thanks. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 39 status 3. Test Day / community event status 4. Open floor -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org https://www.happyassassin.net

2 1

Re: Access a Virtual disk without the VM running
by George R Goffe 16 Oct '23

16 Oct '23

Thanks to those who responded. guestfish is looking promising... Thanks for the suggestion. Best Regards, George... Date: Sat, 14 Oct 2023 22:17:38 -0700 From: Gordon Messmer <gordon.messmer(a)gmail.com> Subject: Re: Access a Virtual disk without the VM running To: test(a)lists.fedoraproject.org Message-ID: <efc87d7d-4175-44c2-ad1b-dfde4784a549(a)gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed On 2023-10-14 15:04, George R Goffe via test wrote: > Ideally, I would mount the VDI on the host and just copy the file. Is > there a way to do this easily? https://rwmj.wordpress.com/2010/10/04/tip-open-virtualbox-vdi-file-using-li… guestfish tools should work...

1 0

Access a Virtual disk without the VM running
by George R Goffe 14 Oct '23

14 Oct '23

Hi, I'm having some problems installing the latest Fedora iso images for the past week or so (Fedora-Everything-netinst-x86_64-Rawhide-20231014.n.0.iso) under VirtualBox... I keep getting fatal error messages "Error in POSTIN for rpm pkg dbus-common" and then the install fails. I have captured /tmp into a tar file and would like to make the files available to this list for debugging purposes but now need to move the file from the VM into my host. Ideally, I would mount the VDI on the host and just copy the file. Is there a way to do this easily? Best regards, George... For the past week

3 2

Fedora Linux 39 Final blocker status summary #2
by Adam Williamson 14 Oct '23

14 Oct '23

Hi folks! We're still trying to get F39 done, so time for another status update... Action summary ============== Accepted blockers ----------------- 1. curl - https://bugzilla.redhat.com/2243182 - ON_QA: QA to test and karma https://bodhi.fedoraproject.org/updates/FEDORA-2023-0f8d1871d8 2. distribution - https://bugzilla.redhat.com/2243034 - ASSIGNED: maintainers to try and squeeze out any possible space savings, FESCo to consider https://pagure.io/fesco/issue/3082 3. ghostscript - https://bugzilla.redhat.com/2241112 - ON_QA: QA to test and karma https://bodhi.fedoraproject.org/updates/FEDORA-2023-c2665a9ff3 4. initial-setup - https://bugzilla.redhat.com/2241274 - ON_QA: QA (and pwhalen, who reported the bug) to test and karma https://bodhi.fedoraproject.org/updates/FEDORA-2023-133bdc4283 5. mutter - https://bugzilla.redhat.com/2241632 - ASSIGNED: desktop team to investigate and fix, now this is well triaged 6. shim - https://bugzilla.redhat.com/2113005 - NEW: stakeholders to consider waiving again at go/no-go 7. uboot-tools - https://bugzilla.redhat.com/2241252 - ASSIGNED: ARM team to investigate and fix 8. distribution - https://bugzilla.redhat.com/2242759 - NEW: stakeholders to consider whether any 'fix' is realistic, implement if so Proposed blockers ----------------- 1. anaconda - https://bugzilla.redhat.com/2243206 - POST: blocker voters to vote, anaconda team to fix if accepted Bug-by-bug detail ================= Accepted blockers ----------------- 1. curl - https://bugzilla.redhat.com/2243182 - ON_QA CVE-2023-38545 curl: a heap based buffer overflow in the SOCKS5 proxy handshake [fedora-all] The fix for this is in updates-testing and just needs testing and karma. 2. distribution - https://bugzilla.redhat.com/2243034 - ASSIGNED Fedora 39: Server boot aarch64 image exceeds maximum size This image is oversize because of increases in the size of qualcomm firmware. (The sizes of aarch64 and x86_64 images differ somewhat because they include different firmware packages; x86_64 is fine ATM). We can't drop the new firmware files (says pbrobinson) and I couldn't see any obvious other place to save 6M when I looked at this. In any case, the 700M size limit makes no practical sense for aarch64 (700M is set as the limit because it's the size of a CD; hands up if you have an aarch64 device with a CD-but-not-DVD drive!), and we are probably reaching the limits of its usefulness as a protection against "bloat", since linux-firmware is constantly increasing in size even if we don't introduce any new "bloat" to the installer environment. So I've proposed https://pagure.io/fesco/issue/3082 to bump the size limit to 1G for the aarch64 image at least. If FESCo goes for that proposal, this would be addressed. 3. ghostscript - https://bugzilla.redhat.com/2241112 - ON_QA CVE-2023-43115 ghostscript: GhostPDL can lead to remote code execution via crafted PostScript documents [fedora-all] The fix for this is in updates-testing and just needs testing and karma. 4. initial-setup - https://bugzilla.redhat.com/2241274 - ON_QA initial-setup text fails on hardware The fix for this is in updates-testing and just needs testing and karma. Especially it'd be great if pwhalen could test and confirm as he reported the issue. 5. mutter - https://bugzilla.redhat.com/2241632 - ASSIGNED Netinstall ISO renders a black screen when using kickstart install (bare metal and VM) I've managed to narrow this down to a specific mutter pull request which caused the problem, and found a small change (discovered by someone from upstream to address a different symptom) that avoids this bug. Now up to the desktop team to decide what the best real fix is. 6. shim - https://bugzilla.redhat.com/2113005 - NEW Live image made with BOOTX64.EFI from latest shim-x64-15.6-2 fails to boot on some boards Sadly we will probably have to waive this one more time, at this point in the cycle it's not realistic to start backporting kernel changes. 7. uboot-tools - https://bugzilla.redhat.com/2241252 - ASSIGNED Fedora-Workstation-39_Beta-1.1 boots to a black screen on Raspberry Pi 4 pbrobinson has said he's working on this, unless anyone else expert in uboot-tools stuff wants to help, not much more to be done. 8. distribution - https://bugzilla.redhat.com/2242759 - NEW dnf system-upgrade fails on some RPi4 due to system boot date that pre- dates gpg key We seem to have developed a pretty good understanding of this one now, but based on that understanding, it may not be realistically possible to "fix" it - the only interventions proposed so far that might "fix" it seem rather too radical to introduce as updates to a stable release (F38), which is where they'd have to go. Unless anyone has a bright idea, we might just have to accept that this isn't realistically fixable and waive it to be addressed with documentation. Proposed blockers ----------------- 1. anaconda - https://bugzilla.redhat.com/2243206 - POST anaconda should allow installations on drives providing installation source This is at -3, +1 in voting currently. Needs more votes. If it happens to be accepted, anaconda team would have to decide on a fix. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org https://www.happyassassin.net

1 0

pipewire-0.3.81-1 in updates-testing will be a 0-day breakage for some
by Ian Laurie 12 Oct '23

12 Oct '23

Looks like pipewire-0.3.81-1 has some issues. At first it looked like it only impacted virtual machines but my laptop turned out to be a victim also. It fails 100% for me in VirtualBox across a wide range of hosts for all current Fedora guests (F37, 38, 39 and Rawhide). https://bugzilla.redhat.com/show_bug.cgi?id=2242080 For me, last known working version is pipewire-0.3.80-1. Downgrading to this fixes all cases (VMs and native). All of that said, it's working on 2 other native hosts, however the VMs on those host all fail until Downgrading to 0.3.80-1. Ian -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney

1 0

Partitioning in VirtualBox using FedoraCore 40
by George R Goffe 11 Oct '23

11 Oct '23

Hi, I'm having trouble creating a partition scheme that I have been using it seems like forever. It's not working now with the "latest" spin iso image (/isos/Fedora-Everything-netinst-x86_64-Rawhide-202310 10.n.0.iso). I keep getting this popup error message (enclosed). It looks like anaconda is choosing to try partitions named by appending "/efi" to the partition name. I'm sure I'm doing something wrong but for the life of me, can't see where I'm going wrong. Can anyoneone help me please? Best regards, George...

4 9

Fwd: [Test-Announce] Please help complete validation testing for current Fedora 39 candidate nightly!
by Kamil Paral 11 Oct '23

11 Oct '23

---------- Forwarded message --------- From: Adam Williamson <adamwill(a)fedoraproject.org> Date: Wed, Oct 11, 2023 at 1:50 AM Subject: [Test-Announce] Please help complete validation testing for current Fedora 39 candidate nightly! To: <test-announce(a)lists.fedoraproject.org> Hey folks! You probably saw the mail "Fedora 39 Branched 20231010.n.0 nightly compose nominated for testing" today. Although we still don't have an RC for the Fedora 39 Final release, I want to ask folks to please help us fill out the matrices for this candidate as much as possible. It's best if we find any remaining blocker bugs *now*, not wait for an RC before doing the full testing. You can use testcase_stats to see what test cases probably need running - https://openqa.fedoraproject.org/testcase_stats/39/ . The pages there shows the execution history and last run date for each test on the corresponding matrix page, so you can see at a glance which tests haven't been run recently or at all. Please focus on tests marked Basic, Beta or Final that have not yet been run, or not been run for some time. And of course, if you find a significant bug, mark the test as a failure, file a bug, and nominate it as a release blocker. Thanks a lot folks! -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org https://www.happyassassin.net _______________________________________________ test-announce mailing list -- test-announce(a)lists.fedoraproject.org To unsubscribe send an email to test-announce-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-announce@lists.fedorapro… Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

test October 2023