Bug 1814810

Summary: Basic graphics mode is necessary to boot laptop with dual Intel/AMD Oland GPU
Product: [Fedora] Fedora Reporter: xzj8b3 <xzj8b3>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 32CC: airlied, bcotton, bskeggs, dufresnep, extras-qa, fzatlouk, gmarr, hdegoede, ichavero, itamar, jarodwilson, jeremy, jglisse, john.j5live, jonathan, josef, kernel-maint, linville, masami256, mchehab, mjg59, robatino, steved, y9t7sypezp
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: RejectedBlocker AcceptedFreezeException
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-05-25 17:18:36 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1705306    
Attachments:
Description Flags
dmesg Fedora 32 Beta
none
screenshot showing the F32 Live Beta troubleshooting menu none

Description xzj8b3 2020-03-18 17:04:26 UTC
Created attachment 1671177 [details]
dmesg Fedora 32 Beta

https://bugzilla.redhat.com/show_bug.cgi?id=1802641


After testing Fedora 32 Beta from pendrive I note that the kernel does not yet work with intel integrated graphics ...

The issue had already been reported earlier and makes it just impossible to use the distribution on those adapters!!!

Hopefully the final release will be presented with a working kernel testable in live mode, otherwise it is impossible for users to check if the problem has been solved 

I attach dmesg again

Comment 1 Steve 2020-03-18 20:33:33 UTC
(In reply to xzj8b3 from comment #0)
...
> I attach dmesg again

...
[   18.475718] radeon 0000:04:00.0: fence driver on ring 0 use gpu addr 0x0000000080000c00 and cpu addr 0x00000000995841ee
...
[   19.951674] [drm:uvd_v1_0_start [radeon]] *ERROR* UVD not responding, trying to reset the VCPU!!!
...

That's a radeon problem, and your earlier report, Bug 1802641, has had the component changed to "linux-firmware".

There is a workaround suggested in Bug 1802641, Comment 8. Did you try it?

Przemek: "It can be mitigated by adding radeon.modeset=0 to the kernel commandline in /etc/defaults/grub followed by grub2-mkconfig"

I suggest closing this as a duplicate of Bug 1802641.

Comment 2 xzj8b3 2020-03-18 23:37:51 UTC
But in Fedora 32 Final will be corrected on release???

Comment 3 Steve 2020-03-19 02:23:49 UTC
(In reply to xzj8b3 from comment #2)
> But in Fedora 32 Final will be corrected on release???

OK, I now see that you opened a new bug against F32.

Here is a list of available updates to linux-firmware:
https://bodhi.fedoraproject.org/updates/?packages=linux-firmware

Unfortunately, the notes don't mention radeon:

linux-firmware-20200316-106.fc32
https://bodhi.fedoraproject.org/updates/FEDORA-2020-9d65d662e2

From the attached file you appear to be booting a live image:

[    0.000000] Command line: BOOT_IMAGE=/images/pxeboot/vmlinuz root=live:CDLABEL=Fedora-WS-Live-32_B-1-2 rd.live.image quiet

You can try the workaround (in Comment 1) from the live image by editing the kernel command-line after pressing the "tab" key. Just append this to the end of the kernel command-line:

radeon.modeset=0

Comment 4 Steve 2020-03-19 02:41:34 UTC
(In reply to Steve from comment #3)
...
> You can try the workaround (in Comment 1) from the live image by editing the
> kernel command-line after pressing the "tab" key. Just append this to the
> end of the kernel command-line:
> 
> radeon.modeset=0

Or you could press "Troubleshooting" and then start in "basic graphics mode".

(I tested that in a VM with an F31 live image, but it should be the same for F32.)

Comment 5 xzj8b3 2020-03-24 17:51:13 UTC
I would like to know if the problem has been solved, I would like to install Fedora 32 Beta ...

or how I can proceed to resolve the situation...

Please answer in this way, in case of success, I could give more details about it in my hand!!!

Or should I wait for final release? What version does Kernel have now?

Comment 6 Steve 2020-03-25 20:18:01 UTC
(In reply to xzj8b3 from comment #5)
> I would like to know if the problem has been solved, I would like to install Fedora 32 Beta ...

There hasn't been a new release of linux-firmware, so probably not:

Here is a list of available updates to linux-firmware:
https://bodhi.fedoraproject.org/updates/?packages=linux-firmware

I believe this is the upstream git repo for linux-firmware:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/

> or how I can proceed to resolve the situation...

Did you try the workarounds in Comment 3 and Comment 4?

> Please answer in this way, in case of success, I could give more details about it in my hand!!!
> 
> Or should I wait for final release? What version does Kernel have now?

Beta releases are for testing, and you tested it and filed a bug report. There's not much more that you can do, except watch for a new release of linux-firmware, and test it, if you can successfully install by using one of the workarounds.

Comment 7 Steve 2020-03-25 20:31:11 UTC
Created attachment 1673615 [details]
screenshot showing the F32 Live Beta troubleshooting menu

(In reply to Steve from comment #4)
...
> Or you could press "Troubleshooting" and then start in "basic graphics mode".
...

Here is a screenshot showing the F32 Live Beta troubleshooting menu.

NB: The word "mode" is truncated to "mo" at the right.

Comment 8 Steve 2020-03-25 23:06:02 UTC
The radeon firmware is licensed by AMD:

$ head -1 /usr/share/licenses/linux-firmware/LICENSE.radeon
Copyright (C) 2009-2017  Advanced Micro Devices, Inc. All rights reserved.

And AMD maintains the radeon firmware:

radeon: update oland rlc microcode from amdgpu
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=f1c9e7b67505fcb5b7236902475286e893591916

Comment 9 xzj8b3 2020-04-03 15:16:51 UTC
So it will already be inserted into the next kernel????

Comment 10 Steve 2020-04-07 04:18:10 UTC
Proposing as a Fedora 32 Final blocker bug:

"Release-blocking live images must boot to the expected boot menu, and then to a desktop or to a login prompt where it is clear how to log in to a desktop."
https://fedoraproject.org/wiki/Basic_Release_Criteria#Initialization_requirements

From the attached dmesg, this bug occurs with the F32-Beta Workstation Live image:

[    0.000000] Command line: BOOT_IMAGE=/images/pxeboot/vmlinuz root=live:CDLABEL=Fedora-WS-Live-32_B-1-2 rd.live.image quiet

According to:

Bug 1802641 - kernel 5.4 Bug Radeon

This is a radeon firmware problem:

https://bodhi.fedoraproject.org/updates/?packages=linux-firmware

Comment 11 Steve 2020-04-07 05:01:10 UTC
From the attached log:

[   18.338058] [drm] initializing kernel modesetting (OLAND 0x1002:0x6607 0x1043:0x192D 0x00).
...
[   18.405837] [drm] Loading oland Microcode

Upstream shows two commits related to Oland firmware:

radeon: update oland rlc microcode from amdgpu (2020-01-07)
Fixes clocking issues at 4k
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=f1c9e7b67505fcb5b7236902475286e893591916

This reverts the above commit and appears to have gone into linux-firmware-20200316:

Revert "radeon: update oland rlc microcode from amdgpu" (2020-02-04)
This reverts commit f1c9e7b67505fcb5b7236902475286e893591916.

This breaks UVD on some boards.
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=0ff2f37095070dd142c0b4c8310d6afcf73a146e

Comment 12 František Zatloukal 2020-04-07 08:30:16 UTC
(In reply to xzj8b3 from comment #0)
> Created attachment 1671177 [details]
> dmesg Fedora 32 Beta
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1802641
> 
> 
> After testing Fedora 32 Beta from pendrive I note that the kernel does not
> yet work with intel integrated graphics ...
> 
> The issue had already been reported earlier and makes it just impossible to
> use the distribution on those adapters!!!
> 
> Hopefully the final release will be presented with a working kernel testable
> in live mode, otherwise it is impossible for users to check if the problem
> has been solved 
> 
> I attach dmesg again

So... it seems from logs that the laptop has dual Intel/AMD GPUs. Is that correct? Does either "basic graphics mode" or "radeon.modeset=0" help?

Comment 13 xzj8b3 2020-04-07 13:44:33 UTC
iMy notebook has an I7-4510U processor with Radeon R5 M230 graphics ...

I am currently using Windows 10 because the bug does not allow me a functional Fedora installation.....

Dmesg was obtained from Fedora32 started in live mode!!!

Comment 14 František Zatloukal 2020-04-11 10:09:48 UTC
Hmm, seems like this is indeed limited o Oland generation of GPUs. I was able to succesfully boot Fedora 32 with dual Intel (Sandy Bridge) and AMD Mars XT (CGN 1.0) GPUs.

Comment 15 Geoffrey Marr 2020-04-13 19:35:04 UTC
Discussed during the 2020-04-13 blocker review meeting: [0]

The decision to classify this bug as a "RejectedBlocker" and an "AcceptedFreezeException" was made as as we think the range of hardware affected is quite small (dual Intel/AMD Oland GPU systems are not very common), but accepted as an FE as a severe problem not fixable with an update on hardware that *is* affected.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2020-04-13/f32-blocker-review.2020-04-13-16.04.txt

Comment 16 Steve 2020-04-14 01:47:54 UTC
(In reply to Geoffrey Marr from comment #15)
> Discussed during the 2020-04-13 blocker review meeting: [0]
> 
> The decision to classify this bug as a "RejectedBlocker" and an "AcceptedFreezeException" was made as as we think the range of hardware
> affected is quite small (dual Intel/AMD Oland GPU systems are not very common), but accepted as an FE as a severe problem not fixable with an update on hardware that *is* affected.
> 
> [0] https://meetbot.fedoraproject.org/fedora-blocker-review/2020-04-13/f32-blocker-review.2020-04-13-16.04.txt

Thanks, Geoffrey.

xzj8b3: What that means is that a fix will be accepted after the "Final Freeze", but this bug won't block the F32 Final release.

QA:SOP freeze exception bug process
https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process

Fedora 32 Schedule: Key
https://fedorapeople.org/groups/schedule/f-32/f-32-key-tasks.html

Comment 17 Paul Dufresne 2020-04-18 19:22:09 UTC
I am looking at https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1865130/comments/61 and thinks it might be related.

Comment 18 Steve 2020-04-19 02:16:24 UTC
(In reply to Paul Dufresne from comment #17)
> I am looking at https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1865130/ comments/61 and thinks it might be related.

Thanks for pointing that out -- and my face is red, because I posted repeatedly on this bug and *not once* did I have the wits to actually look at the F32-Beta Live image itself!

So it's simple:

On the F32-Beta Live image (Fedora-Workstation-Live-x86_64-32_Beta-1.2.iso booted in a VM):

$ rpm -q linux-firmware
linux-firmware-20200122-105.fc32.noarch

That is OLDER than the current linux-firmware on Bodhi:

linux-firmware-20200316-106.fc32 
https://bodhi.fedoraproject.org/updates/FEDORA-2020-9d65d662e2

See Comment 11 for the rest of the story: The upstream revert went into linux-firmware-20200316-106.fc32:

That can be verified by doing a text search for "radeon" on the upstream git log:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/log/?h=20200316

Comment 19 Paul Dufresne 2020-04-20 14:53:48 UTC
linux-firmware-20200316-106.fc32 is now in stable.
So original poster can test it by downloading latest one of latest daily build at:
https://www.happyassassin.net/nightlies.html (green links are known to have past all defined tests).
I am writing this on Fedora-32-20200419.n.0 where:
$ rpm -q linux-firmware
linux-firmware-20200316-106.fc32.noarch
So I know it have the needed version.

Comment 20 Steve 2020-04-20 19:30:31 UTC
Thanks for checking that, Paul. Testing a nightly is a very good idea.

xzj8b3: The nightlies are ISO images of Fedora software that are built every night for testing.

You can download and install one on your pendrive just like you did for the F32-Beta ISO image.

There are a lot to choose from here:

https://www.happyassassin.net/nightlies.html

But you only need Fedora 32:Workstation live:x86_64 with a green link.

The nightlies are updated every night, but I believe that the one Paul tested is here:

https://kojipkgs.fedoraproject.org/compose/branched/Fedora-32-20200419.n.0/compose/Workstation/x86_64/iso/

The latest nightly Fedora 32 Workstation build for x86_64 is here:

https://kojipkgs.fedoraproject.org/compose/branched/latest-Fedora-32/compose/Workstation/x86_64/iso/

Paul: Please correct me if I have said anything wrong.

Comment 21 Steve 2020-04-20 20:58:37 UTC
I installed this nightly on a pendrive and successfully booted to a desktop on two systems (desktop, laptop), and networking was functional on both:
https://kojipkgs.fedoraproject.org/compose/branched/Fedora-32-20200420.n.0/compose/Workstation/x86_64/iso/

Comment 22 xzj8b3 2020-04-21 16:48:06 UTC
(In reply to Steve from comment #1)
> (In reply to xzj8b3 from comment #0)
> ...
> > I attach dmesg again
> 
> ...
> [   18.475718] radeon 0000:04:00.0: fence driver on ring 0 use gpu addr
> 0x0000000080000c00 and cpu addr 0x00000000995841ee
> ...
> [   19.951674] [drm:uvd_v1_0_start [radeon]] *ERROR* UVD not responding,
> trying to reset the VCPU!!!
> ...
> 
> That's a radeon problem, and your earlier report, Bug 1802641, has had the
> component changed to "linux-firmware".
> 
> There is a workaround suggested in Bug 1802641, Comment 8. Did you try it?
> 
> Przemek: "It can be mitigated by adding radeon.modeset=0 to the kernel
> commandline in /etc/defaults/grub followed by grub2-mkconfig"
> 
> I suggest closing this as a duplicate of Bug 1802641.


But do you really want to go back to Fedora if you destroy it at every kernel release or is it still suffering from these problems??

How can you have reliability in a system you always know what problems give new kernels that instead of solving problems create them??

You windows will have poor rivacy but go'... I don't think Linux world is working so well if every time the same problems arise that never resolve and punctually come back.

Windows will now also have built-in Linux and maybe it would be worth trying it all in all...

Fedora has not even been able to preconfigure wireguards so it can already be readily available at first start and therefore accessible to everyone enjoying the benefits.... and even with Firefox, first subscriptions for features start popping up!! Mahhh...

Comment 23 xzj8b3 2020-04-21 16:48:43 UTC
(In reply to František Zatloukal from comment #12)
> (In reply to xzj8b3 from comment #0)
> > Created attachment 1671177 [details]
> > dmesg Fedora 32 Beta
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1802641
> > 
> > 
> > After testing Fedora 32 Beta from pendrive I note that the kernel does not
> > yet work with intel integrated graphics ...
> > 
> > The issue had already been reported earlier and makes it just impossible to
> > use the distribution on those adapters!!!
> > 
> > Hopefully the final release will be presented with a working kernel testable
> > in live mode, otherwise it is impossible for users to check if the problem
> > has been solved 
> > 
> > I attach dmesg again
> 
> So... it seems from logs that the laptop has dual Intel/AMD GPUs. Is that
> correct? Does either "basic graphics mode" or "radeon.modeset=0" help?

But do you really want to go back to Fedora if you destroy it at every kernel release or is it still suffering from these problems??

How can you have reliability in a system you always know what problems give new kernels that instead of solving problems create them??

You windows will have poor rivacy but go'... I don't think Linux world is working so well if every time the same problems arise that never resolve and punctually come back.

Windows will now also have built-in Linux and maybe it would be worth trying it all in all...

Fedora has not even been able to preconfigure wireguards so it can already be readily available at first start and therefore accessible to everyone enjoying the benefits.... and even with Firefox, first subscriptions for features start popping up!! Mahhh...

Comment 24 xzj8b3 2020-04-21 16:49:12 UTC
But do you really want to go back to Fedora if you destroy it at every kernel release or is it still suffering from these problems??

How can you have reliability in a system you always know what problems give new kernels that instead of solving problems create them??

You windows will have poor rivacy but go'... I don't think Linux world is working so well if every time the same problems arise that never resolve and punctually come back.

Windows will now also have built-in Linux and maybe it would be worth trying it all in all...

Fedora has not even been able to preconfigure wireguards so it can already be readily available at first start and therefore accessible to everyone enjoying the benefits.... and even with Firefox, first subscriptions for features start popping up!! Mahhh...

Comment 25 Steve 2020-04-21 20:34:11 UTC
xzj8b3: Thanks for your reply. Could you please test one of the nightlies and see if it works for you or not?

> Fedora has not even been able to preconfigure wireguards ...

I don't know what "wireguards" are. Could you post a link to more information?

Comment 26 Ben Cotton 2020-04-21 21:25:50 UTC
Let's keep this bug's conversation focused on the subject.

xzj8b3, if there are other issues, please feel free to open new bugs or join us on discussion.fedoraproject.org. In the meantime, can you please the latest compose:
https://kojipkgs.fedoraproject.org/compose/32/Fedora-32-20200420.0/compose/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-32-1.4.iso

(that link is for Workstation x86_64. If you need another variant or architecture, see https://kojipkgs.fedoraproject.org/compose/32/Fedora-32-20200420.0/compose/ )

Comment 27 Steve 2020-04-21 22:00:49 UTC
(In reply to Ben Cotton from comment #26)
> Let's keep this bug's conversation focused on the subject.

Sometimes reporters raise more than one issue in a bug report, so it is always much more polite and constructive to collect more information before referring them to another venue.

Comment 28 xzj8b3 2020-04-30 12:40:42 UTC
I always report, "sometimes too much", but I see it was done a great job with Fedora 32 ... then of course I have my limits, otherwise I would be much more detailed each time in the description of any problems.

Thank you again for the resolution of the problem that I hope in the future will no longer occur .... A wonderful distribution as Fedora can not afford similar problems can damage the image, not even because of problems of third parties!!!

I've never seen a distribution with such an active team behind it....and that's what distinguishes Fedora from other distros...and I hope it will continue like this!!!!

Comment 29 xzj8b3 2020-04-30 12:41:24 UTC
I always report, "sometimes too much", but I see it was done a great job with Fedora 32 ... then of course I have my limits, otherwise I would be much more detailed each time in the description of any problems.

Thank you again for the resolution of the problem that I hope in the future will no longer occur .... A wonderful distribution as Fedora can not afford similar problems can damage the image, not even because of problems of third parties!!!

I've never seen a distribution with such an active team behind it....and that's what distinguishes Fedora from other distros...and I hope it will continue like this!!!!

Comment 30 xzj8b3 2020-05-19 15:34:43 UTC
https://betanews.com/2020/05/19/open-source-security-flaws/


A shame to read similar articles about a world as beautiful as opensource, of course nothing is perfect but I hope we can improve more and more, paying more attention to new users who are increasingly closer to this world ... I do not approve Forums that boast of Ubuntu Benkmark as if this is better than other distributions, indeed the thing has bothered me rather because for a long time I hear a lot of nonsense about Fedora communities that do not correspond to reality ... Sure ubuntu is very attentive to new users trying to make life easier, a little bit we all learned from that, but I estimate a lot Fedora for its policy and the speed of response with which you address emerging issues even in bugzilla, I would like just a little more attention to novice users when they arise in some problem that often have difficulty understanding, as it would be nice to see wikis written in a more understandable with more examples. ..I find for example the plugin section of dnf too synthetic, it would be very nice to have more understandable wikis even for new or average user and if it were possible maybe even in Italian etc.

Comment 31 xzj8b3 2020-05-19 16:02:50 UTC
I didn't understand where I should go for more issues, which would be very nice to be able to discuss

Comment 33 Steve 2020-05-19 17:18:33 UTC
> I didn't understand where I should go for more issues, which would be very nice to be able to discuss

In comment 26, Ben suggested this site:

Fedora Discussion
https://discussion.fedoraproject.org/

> That's Wireguard.

Thanks for the link.

There is a search tool in the upper-right corner of the Fedora Discussion web site. A search for "wireguard" returns several results:

https://discussion.fedoraproject.org/search?q=wireguard%20order%3Alatest

This will find Fedora packages supporting WireGuard:

$ dnf -q search wireguard
======================================== Name & Summary Matched: wireguard ========================================
golang-zx2c4-wireguard-wgctrl-devel.noarch : Control of WireGuard interfaces on multiple platforms
============================================= Name Matched: wireguard =============================================
wireguard-tools.x86_64 : Fast, modern, secure VPN tunnel
=========================================== Summary Matched: wireguard ============================================
wgctrl.x86_64 : Control of WireGuard interfaces on multiple platforms

This is the WireGuard project web site:

https://www.wireguard.com/

Comment 34 Steve 2020-05-19 17:42:57 UTC
> I find for example the plugin section of dnf too synthetic ...

I'm not sure what you mean by "synthetic". Could you post the Italian word for what you mean?

Anyway, "dnf" is a command-line tool. Novices should use the gnome "Software" GUI app, which is installed by default:

$ dnf repoquery --info gnome-software

Comment 35 xzj8b3 2020-05-19 20:15:53 UTC
Well use linux so then it doesn't even make sense to install it and try to get to know it... I have never installed anything with Gnome Software.

By "synthetic" I mean short...

It would be very nice to have more extensive descriptions of plugins installable in dnf, so you know much more and use them better, perhaps with more examples in various situations 

I never understood the correct use of :

python3-dnf-plugin-torproxy.noarch 

python3-dnf-plugin-snapper.noarch

python3-dnf-plugin-versionlock.noarch 

I think it would be interesting to have more information and examples of use on each plugin so you can 'choose more properly those of our interest and learn to make the most of them, some have very poor descriptions and do not understand either the use, nor how to get more information about them ... have a few lines each in the wiki and that's it!!

Comment 36 xzj8b3 2020-05-19 20:18:45 UTC
Then Tilix is fabulous other than software gnome.

Comment 37 Steve 2020-05-19 22:36:31 UTC
> By "synthetic" I mean short...

Thanks for your clarification. I suggest opening documentation bugs, which are requests that the documentation be improved. For a documentation bug, put "[DOC]" at the beginning of the bug summary. Components in BZ are:

Component dnf-plugins-extras:

python3-dnf-plugin-torproxy.noarch 
python3-dnf-plugin-snapper.noarch

https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&classification=Fedora&component=dnf-plugins-extras&list_id=11077378&product=Fedora&query_format=advanced

Component dnf-plugins-core:

python3-dnf-plugin-versionlock.noarch

https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&classification=Fedora&component=dnf-plugins-core&list_id=11077384&product=Fedora&query_format=advanced

To find the BZ component for a package, use a command like this:

$ dnf -Cq repoquery --info python3-dnf-plugin-torproxy | grep 'Source'

Comment 39 Steve 2020-05-20 01:24:14 UTC
(In reply to Steve from comment #37)
...
> To find the BZ component for a package, use a command like this:
> 
> $ dnf -Cq repoquery --info python3-dnf-plugin-torproxy | grep 'Source'

And to find the upstream git repos, run:

$ dnf -Cq repoquery --info python3-dnf-plugin-torproxy | grep 'URL'

Comment 40 Fedora Program Management 2021-04-29 16:52:42 UTC
This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '32'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 32 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 41 Ben Cotton 2021-05-25 17:18:36 UTC
Fedora 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.