[Now Playing] Toolbx Test Day 2023-09-14
by Sumantro Mukherjee
Hey Folks,
Toolbx as a blocker for Fedora Workstation was declared as part of
Fedora Linux 39 changes process.
The idea for test week is for testers is to install latest version of
Toolbx and install Fedora and any other OS as well. The wiki[0] has
all the necessary details. Come join us and make Fedora better!
[0] https://fedoraproject.org/wiki/Test_Day:2023-09-14_Toolbx
--
//sumantro
Fedora QE
TRIED AND PERSONALLY TESTED, ERGO TRUSTED
7 months, 4 weeks
Fedora Linux 39 Beta blocker status summary #1
by Adam Williamson
Hi folks! Sorry for not sending these sooner, but better late than
never: here's a blocker bug status summary for Fedora 39. We're
currently targeting a go/no-go meeting this Thursday (September 14) and
release the following Tuesday (September 19).
Action summary
==============
Accepted blockers
-----------------
1. anaconda - webUI: cannot install to encrypted software RAID
partition - POST: anaconda team to send new release/build
2. kernel - /dev/tpm* is missing with new kernels - VERIFIED: releng
and I to push the fix stable
3. shim - Live image made with BOOTX64.EFI from latest shim-x64-15.6-2
fails to boot on some boards - NEW: likely waive again at go/no-go
Proposed blockers
-----------------
1. anaconda - Anaconda webUI can't handle two volumes with the same
LABEL, writes into a different partition than indicated - NEW: anaconda
team to investigate and fix
2. edk2 - Fedora 39 fails to boot on qemu VM using OVMF_CODE.secboot.fd
firmware - NEW: QA to isolate the bug more precisely, kraxel to
investigate and fix
3. fedora-repos - updates-testing is not enabled when it should be -
VERIFIED: releng and I to push the fix stable
4. python-blivet - blivet-gui creates different volumes with the same
name, confusing anaconda webUI - ASSIGNED: blivet team to investigate
and fix
Bug-by-bug detail
=================
Accepted blockers
-----------------
1. anaconda - webUI: cannot install to encrypted software RAID
partition - POST
There is a fix for this which has been verified. We need a new anaconda
build with it included (anaconda team).
2. kernel - /dev/tpm* is missing with new kernels - VERIFIED
This just needs to be pushed to stable (me and releng).
3. shim - Live image made with BOOTX64.EFI from latest shim-x64-15.6-2
fails to boot on some boards - NEW
It seems that, unfortunately, we may have to waive this *again*. There
is definite movement upstream but it probably hasn't moved far enough
to let us fix it for Beta. We're hoping to finally have this resolved
for Final.
Proposed blockers
-----------------
1. anaconda - Anaconda webUI can't handle two volumes with the same
LABEL, writes into a different partition than indicated - NEW
It's possible to have multiple btrfs volumes with the same label, which
confuses anaconda/blivet and can result in data getting written to a
different place than indicated. Seems likely to be accepted as a
blocker, we need anaconda/blivet folks to look at fixing this (anaconda
team).
2. edk2 - Fedora 39 fails to boot on qemu VM using OVMF_CODE.secboot.fd
firmware - NEW
This was initially filed and proposed on the basis that VM boot didn't
work at all, but then we discovered it was specific to the Secure Boot-
enabled UEFI firmware configuration. That may not be important enough
to merit blocker status, but we should definitely look into exactly
what the trigger is between host and guest, and get the edk2
maintainers to look into this (kraxel).
3. fedora-repos - updates-testing is not enabled when it should be -
VERIFIED
It's an interesting question whether the criteria do or should cover
this, but the fix is already accepted as an FE and queued for stable,
so it will be pushed shortly (me and releng).
4. python-blivet - blivet-gui creates different volumes with the same
name, confusing anaconda webUI - ASSIGNED
This is kinda a companion to 1: not only can multiple btrfs volumes
with the same label exist, but blivet actually creates them this way at
present unless you explicitly set a label. There's a question whether
resolving this would be enough to make 1. not a blocker, or whether we
should still block on 1. because other tools could potentially create
the same situation. Either way, we want blivet devs to fix this,
ideally (vtrefny).
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net
8 months
freeze exceptions for FTI bugs
by Kamil Paral
Lately we've seen a surge of FTI (fails to install) bugs being proposed as
freeze exceptions [1] [2]. We generally grant them, because we want the
base repo to be in a consistent and buildable state. However, I wonder,
isn't this approach mostly relevant for the Final release? Does it make
sense to also have this approach for Beta?
The reason why I'm thinking about this is because of course there's some
work connected with granting and processing these freeze exceptions (FEs).
But at the same time, updates-testing is enabled by default, so users can
get the fixed versions immediately, and the fixes can be pushed stable
right after the Beta freeze is over. Is the extra FE-related work justified?
One reason I can think of is when the package A in question needs to be
used for rebuilding/installing another package B. In that case, if package
A is not pushed stable, you can't prepare an update for package B into
updates-testing (or can you? Can you build several inter-connected packages
together and make a Bodhi update for them? What if you have access rights
to just package B but not A?). I do understand that in this case waiting
until the freeze lifts might be inconvenient.
What if we granted FEs for Beta just in these justified cases but not in
general, in order to decrease the processing-work? Is that a good/bad idea?
Or perhaps we can grant FTI FEs automatically? Either always, or in some
cases?
What are your thoughts on this?
Thanks,
Kamil
[1] https://qa.fedoraproject.org/blockerbugs/milestone/39/beta/buglist
[2]
https://pagure.io/fedora-qa/blocker-review/issues?status=all&search_patte...
8 months
Re: Donate 1 minute of your time to test upgrades from F38 to F39
by Luna Jernberg
Did this on my Thinkpad Edge a couple of days ago, and it went fine :)
Den ons 23 aug. 2023 kl 20:23 skrev Miroslav Suchý <msuchy(a)redhat.com>:
>
> Do you want to make Fedora 39 better? Please spend 1 minute of your time and try to run:
>
> # Run this only if you use default Fedora modules
> # next time you run any DNF command default modules will be enabled again
> sudo dnf module reset '*'
>
> dnf --releasever=39 --setopt=module_platform_id=platform:f39 \
> --enablerepo=updates-testing \
> $(rpm -q fedora-repos-modular >/dev/null && echo --enablerepo=updates-testing-modular) \
> --assumeno distro-sync
>
>
> This command does not replace `dnf system-upgrade`, but it will reveal potential problems.
>
> You may also run `dnf upgrade` before running this command.
>
>
> The `--assumeno` will just test the transaction, but does not make the actual upgrade.
>
>
> In case you hit dependency issues, please report it against the appropriate package.
>
> Or against fedora-obsolete-packages if that package should be removed in Fedora 39. Please check existing reports against fedora-obsolete-packages first:
>
> https://red.ht/2kuBDPu
>
> and also there is already bunch of "Fails to install" (F39FailsToInstall) reports:
>
> https://bugzilla.redhat.com/buglist.cgi?bug_id=2168845&bug_id_type=anddep...
>
>
> Two notes:
>
> * you may want to run the same command with dnf5 to help test new dnf.
>
> * this command found zero issues on my personal system - great work all everybody!
>
>
> Thank you
>
> Miroslav
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
8 months, 1 week
