This page documents common bugs in Fedora 29 and, if available, fixes or workarounds for these problems. If you find your problem in this page, do not file a bug for it, unless otherwise instructed. Where appropriate, a reference to the current bug(s) in Bugzilla is included.
- 1 Release Notes
- 2 My bug is not listed
- 3 Installation issues
- 4 Upgrade issues
- 5 Core system issues
- 6 Workstation (GNOME) Issues
Read the F29_Beta_release_announcement for specific information about changes in Fedora 29 and other general information.
My bug is not listed
Not every bug is listed in this page, but Bugzilla should be a comprehensive database of known bugs. This page is a sampling of the bugs most commonly discussed on our mailing lists and forums.
To see if your bug has already been reported, you can search Bugzilla. If it has not yet been reported, we encourage you to do so to help improve Fedora for yourself and others. A guide to Bugs and feature requests has been prepared to assist you.
If you believe an already-reported bug report should be added to this page because it is commonly encountered, you can:
- Add it yourself, if you have wiki access. Common bugs instructions provides guidance on how to add an entry to the page correctly, but the most important thing is to make sure that the bug is listed - don't worry if you don't get the format quite right, we can clean it up later.
- Or, add the CommonBugs keyword to the bug report. Someone from the QA team will then inspect the issue to determine whether the bug should be listed as a common bug. To expedite your request, please add a comment to the bug that includes
- a summary of the problem
- any known workarounds
- an assessment on the impact to Fedora users
For reference, you can query Bugzilla for bugs tagged CommonBugs:
- CommonBugs? (bugs with CommonBugs keyword, but do not yet have a link to this page)
- CommonBugs+(bugs with CommonBugs keyword and contain a link to this page)
UEFI install in 'basic graphics mode' may fail to boot
Several testers have reported that attempting to boot Fedora 29 installer images in native UEFI mode and using the Install Fedora 29 in basic graphics mode option from the Troubleshooting menu may fail to reach the graphical installer successfully.
So far, this bug has not been reported to affect any system which does not boot successfully using the regular boot option, so we suggest simply doing that instead. If you have a system which fails to boot either in "normal" or "basic" graphics mode, please report this to the bug.
GNOME Software in Fedora 27 does not offer upgrade to Fedora 29 even after enabling unstable release upgrades
Testing has shown that Fedora 27's GNOME Software will not offer an upgrade directly to Fedora 29, even if you enable the gsettingskey that should allow this to happen.
If you are simply trying to upgrade to Fedora 29 and don't really mind how it happens, you have two obvious choices. You can simply upgrade to Fedora 28 and then from 28 to 29 via GNOME Software, or you can do the upgrade in one go using dnf instead of GNOME Software, following the DNF_system_upgrade instructions.
If you are specifically attempting to test GNOME Software upgrade from 27 to 29, you should be able to force the option to appear by doing the following. Exit GNOME Software, then edit the file
~/.cache/gnome-software/fedora-pkgdb-collections/fedora.json. Remove the entire dict for Fedora 28, and/or set Fedora 29's status to Active instead of Under Development. Run GNOME Software again, and it should offer you the upgrade to Fedora 29 instead of 28. You may have to attempt this a few times, as GNOME Software will sometimes re-download the file in question and hence restore it to its original state.
Core system issues
Package management tools (dnf, GNOME Software etc.) can crash when more than one runs at once
The version of libdnf included in Fedora 29 introduces a database called 'swdb' which is intended to replace old, tool-specific databases like the yum/DNF history database, with the intention that all package management tools will share a common view of the transaction history and so on. However, it seems that multiple processes attempting to access this database simultaneously may not queue in an orderly fashion, or exit cleanly, but crash with an error message like . So far, this issue has been reproduced with one dnf process and one pkcon process, and also with two dnf processes.
To the best of our current knowledge, this problem cannot result in partially-completed transactions or inconsistent databases, as the process that crashes should not have actually made any changes to anything yet. However, as any crash in a package manager is undesirable and worrying, we are working to resolve this as soon as possible.
To "work around" it for now, simply retry the transaction that failed. Once the other transaction has completed, it should succeed. If the other process is one you ran yourself, it should be easy to identify, but it may be harder if it is an automatically-scheduled update or something along those lines.
Printing via CUPS filters does not work
A change in glibc is reported to cause any attempt to print which must go through a CUPS filter running on Fedora 29 to fail. There are various affected scenarios, which are discussed in more detail in the bug report.
Installing the update (see above) is likely easier than any method for 'working around' this problem.
Cron jobs in
/etc/cron.d (including cron.hourly) do not run
Testing has shown that cron jobs in correct formats dropped into
/etc/cron.d do not get run. This includes all scripts dropped into
/etc/cron.hourly, as execution of those depends on a job in
/etc/cron.d. This problem is due to SELinux blocking the operation.
(allow unconfined_t system_cron_spool_t( file ( entrypoint)))
to use this, save that single line to a file with the extension
crond.cil, and load it with
sudo semodule -i crond.cil. After you do this, the jobs should execute successfully.
DNF operations performed with modular repositories offline are not aware of modules
If you have any modules enabled on your Fedora 29 system, and you somehow perform a package management operation with the modular repositories disabled, any packages installed from the modules will be treated as if they were non-modular packages.
For instance, say you have a module enabled that provides version 2.0 of package foo, but the non-modular Fedora 29 repositories contain version 3.0 of the same package. Normally, when you run DNF, it will recognize that you are using the module, and not offer to upgrade to foo 3.0 from the non-modular repositories. If, however, you somehow run an update operation with the modular repositories disabled, DNF will incorrectly offer this "update".
It is not likely that you will run into this scenario in normal use of Fedora 29 Beta, but we do recommend you be careful with the use of theargument to DNF. It is also at least possible that you may hit it by temporarily enabling the updates-testing-modular repository to enable a new repository; until the module is present in the updates-modular repository, subsequent operations without the updates-testing-modular repository enabled may run into this issue, so, again, take care.
We are aiming to resolve at least the worst possible cases and consequences of this before Fedora 29 proper is released.
Workstation (GNOME) Issues
GNOME may crash on switch back from virtual terminal under X.org with multiple displays
Some testers have reported that GNOME may crash on a system with multiple displays, running GNOME under X.org (rather than Wayland), if the user switches to a VT (console) and then switches back again. So far this bug has been reported to affect Lenovo Thinkpad T460s, T470s and T480s laptops, and a desktop with a Radeon R7-based graphics card, with various display configurations.
If you are affected by a problem like this, the most obvious workaround is to run on Wayland instead of X.org, if you can. If you must use X.org, we can only advise that you avoid using virtual terminals until this can be investigated and resolved.