From Fedora Project Wiki

(add another bug to cron.d selinux issue)
(43 intermediate revisions by 10 users not shown)
Line 6: Line 6:
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.
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.


{{admon/note|Pre-release version|Fedora 29 has not yet been released. During this pre-release period, this page will cover known issues in the Fedora 29 pre-releases. Issues that are fixed will be removed from the page once a fix is available (for instance, an issue that affects the Beta but is fixed in the final release will be removed at the time of that release).}}


== Release Notes ==
== Release Notes ==
Line 21: Line 20:
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.
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.


== Upgrade issues ==
{{Common bugs issue|anaconda-lang-switch|Switching keyboard layout with key combo does not work in Wayland on Fedora Workstation Live image|1389959}}


{{Common bugs issue|f27-gnome-software|GNOME Software in Fedora 27 does not offer upgrade to Fedora 29 even after enabling unstable release upgrades|1628497}}
If you're running Workstation Live install media and configure multiple languages in the installer, you won't be able to switch between them using the standard system shortcut (typically {{key press|Win|Space}} or {{key press|Alt|Shift}}). However, you can still click on the language indicator in the installer with the mouse and that will switch the languages.


Testing has shown that Fedora 27's GNOME Software will not offer an upgrade directly to Fedora 29, even if you enable the gsettings {{code|org.gnome.software show-upgrade-prerelease}} key that should allow this to happen.
This does not affect other install media (KDE Live, DVD and netinst images).


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.
{{Common bugs issue|basic-graphics-fails|'Basic graphics' mode will often fail on Workstation|1691909|1683197}}


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 {{filename|~/.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.
Due to at least two different problems, trying to boot a Fedora 29 Workstation live image or installed system using the 'basic graphics' option will often fail; when doing a BIOS native boot it will probably always fail, with a UEFI native boot it may work.
 
Fortunately this option is less commonly needed than it used to be. If you have a system on which it is necessary, you may need to install a different Fedora edition until fixes or workarounds for the problems are available.


== Core system issues ==
== Core system issues ==


{{Common bugs issue|libdnf-swdb-crash|Package management tools (dnf, GNOME Software etc.) can crash when more than one runs at once|1631533}}
{{Common bugs issue|crond-selinux|Cron jobs in {{filename|/etc/cron.d}} (including cron.hourly) do not run|1625645|1639381}}
 
Testing has shown that cron jobs in correct formats dropped into {{filename|/etc/cron.d}} do not get run. This includes all scripts dropped into {{filename|/etc/cron.hourly}}, as execution of those depends on a job in {{filename|/etc/cron.d}}. This problem is due to SELinux blocking the operation.
 
To work around this problem until it is resolved, a [https://bugzilla.redhat.com/show_bug.cgi?id=1625645#c12 comment on the bug report] contains a suggested [https://selinuxproject.org/page/PolicyLanguage#CIL_Policy_Language CIL]-formatted policy that allows these jobs to run:
 
(allow unconfined_t system_cron_spool_t( file ( entrypoint)))
 
to use this, save that single line to a file with the extension {{code|.cil}}, e.g. {{filename|crond.cil}}, and load it with {{command|semodule}}, e.g. {{command|sudo semodule -i crond.cil}}. After you do this, the jobs should execute successfully.
 
{{Common bugs issue|dnf-module-offline|DNF operations performed with modular repositories offline are not aware of modules|1616167}}
 
If you have any [https://docs.fedoraproject.org/en-US/modularity/ 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 the {{code|--disablerepo}} argument 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.


The version of [https://github.com/rpm-software-management/libdnf 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 {{code|Exec failed: database is locked}}. So far, this issue has been reproduced with one dnf process and one pkcon process, and also with two dnf processes.
{{Common bugs issue|dnf-mirrorlist-variables|DNF doesn't resolve variables in mirrorlists|1637148}}


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.
When a ''yum/dnf'' repository uses a mirrorlist link, and the content of this link contains URLs with special dnf variables, such as <code>$releasever</code> or <code>$basearch</code>, ''DNF'' is unable to replace them with correct release values and fails to download metadata from those links.  


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.
Such behaviour did not happen in previous version of Fedora and there is no workaround for it. A fix has been submitted to solve it. When it is found helpful, this issues will be solved in one of the future updates.


{{Common bugs issue|cups-filters-fail|Printing via CUPS filters does not work|1628255}}
{{Common bugs issue|dnf-verbose-logs|DNF logs very verbosely by default, leads to large log files|1355764}}
{{Common bugs update testing|FEDORA-2018-26b38a126f}}


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 [https://bugzilla.redhat.com/show_bug.cgi?id=1628255#c3 the bug report].
By default, the DNF included with Fedora 29 does some very verbose logging. Especially the file `/var/log/dnf.librepo.log` contains very detailed logging of mirror selection and file download operations. Some operations, such as a system upgrade or `reposync`, can potentially cause multiple gigabytes of messages to be written to this log file. The DNF log files are configured for rotation, so they will be compressed and expired weekly so long as {{package|logrotate}} is installed, but this can be insufficient when a single operation can cause the files to grow very large.


Installing the update (see above) is likely easier than any method for 'working around' this problem.
If the DNF log files are filling up your disk and you need a solution urgently, it is safe to simply remove the log files (after copying them elsewhere if you need them for reference), this will not break anything. A future libdnf update is planned to reduce the `dnf.librepo.log` verbosity. Until then, if this is an ongoing problem for you, you can work around it by redirecting the log output to {{filename|/dev/null}} - see [https://bugzilla.redhat.com/show_bug.cgi?id=1355764#c8 this bug comment] for one way to do that.


{{Common bugs issue|rtkit-update|System update fails when trying to remove {{code|rtkit-0.11-19.fc29}}|1637496}}
{{Common bugs issue|rtkit-update|System update fails when trying to remove {{code|rtkit-0.11-19.fc29}}|1637496}}


This affects most Fedora 29 pre-release installations. If you have {{code|rtkit-0.11-19.fc29}} in your system, an update to a later rtkit will fail, because the older version can't be removed. You can check what version of rtkit you have with this command:
This affects only Fedora 29 pre-release installations. If you have {{code|rtkit-0.11-19.fc29}} in your system, an update to a later rtkit will fail, because the older version can't be removed. You can check what version of rtkit you have with this command:
<pre>$ rpm -q rtkit
<pre>$ rpm -q rtkit
rtkit-0.11-20.fc29.x86_64</pre>
rtkit-0.11-20.fc29.x86_64</pre>
Line 63: Line 81:
$ </pre>
$ </pre>


{{Common bugs issue|crond-selinux|Cron jobs in {{filename|/etc/cron.d}} (including cron.hourly) do not run|1625645|1639381}}
{{Common bugs issue|libdnf-swdb-crash|Package management tools (dnf, GNOME Software etc.) can crash when more than one runs at once|1631533}}


Testing has shown that cron jobs in correct formats dropped into {{filename|/etc/cron.d}} do not get run. This includes all scripts dropped into {{filename|/etc/cron.hourly}}, as execution of those depends on a job in {{filename|/etc/cron.d}}. This problem is due to SELinux blocking the operation.
Note: We hope this problem has been fixed in the final Fedora 29 release and should no longer happen. In case you can still see it with a fully up-to-date system, see the description below and please provide your feedback in {{bz|1631533}}.


To work around this problem until it is resolved, a [https://bugzilla.redhat.com/show_bug.cgi?id=1625645#c12 comment on the bug report] contains a suggested [https://selinuxproject.org/page/PolicyLanguage#CIL_Policy_Language CIL]-formatted policy that allows these jobs to run:
The version of [https://github.com/rpm-software-management/libdnf 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 {{code|Exec failed: database is locked}}. So far, this issue has been reproduced with one dnf process and one pkcon process, and also with two dnf processes.


(allow unconfined_t system_cron_spool_t( file ( entrypoint)))
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 use this, save that single line to a file with the extension {{code|.cil}}, e.g. {{filename|crond.cil}}, and load it with {{command|semodule}}, e.g. {{command|sudo semodule -i crond.cil}}. After you do this, the jobs should execute successfully.
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.


{{Common bugs issue|dnf-module-offline|DNF operations performed with modular repositories offline are not aware of modules|1616167}}
{{Common bugs issue|dnf-history-crash|DNF crashes on upgraded systems|1600917}}


If you have any [https://docs.fedoraproject.org/en-US/modularity/ 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.
The `dnf` utility can crash when encountering history database created on previous release (F28, F27, etc.), which is common on system-upgraded installations.


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".
Workaround for now is to remove `/var/lib/dnf/history/` directory. Be aware that this will remove all entries from `dnf` history!


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 the {{code|--disablerepo}} argument 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.
== Workstation (GNOME) Issues ==


We are aiming to resolve at least the worst possible cases and consequences of this before Fedora 29 proper is released.
{{Common bugs issue|gnome-software-progress|Download progress is often invisible if GNOME Software|1643446}}


{{Common bugs issue|dnf-best-update-candidate|DNF prints misleading "cannot install the best update candidate" messages for packages where newer version exists in disabled module|1616118}}
When you update your system with '''Gnome Software''', sometimes the progress bar showing the percentage of downloaded packages is not correctly visible on the lower part of the '''Cancel''' button. This problem does not affect the functionality of the application and updating the system still works fine.


When using DNF to update packages on Fedora 29, you may see worrying warning messages like this:
Note, that downloading the package set may take several minutes and the application may look unresponsive. If you see such behaviour, do not cancel the download process and wait until it is finished and you are offered to '''Reboot and Install'''.


Problem 1: cannot install the best update candidate for package bubblewrap-0.3.0-2.fc29.x86_64
{{Common bugs issue|gnome-software-noaction|Download button in GNOME Software performs the download, but then changes back to Download|1643059}}
  - package bubblewrap-0.3.0-2.module_2123+73a9ef6f.x86_64 is disabled


Normally, this does not actually signify any real problem at all. DNF is noticing that a disabled module contains a higher version of the package than the version you have installed from the main distribution repositories. Ideally, it would treat this situation as normal and expected, and not print any message like this.
Some testers experienced a situation, when, during system update via '''Gnome Software''', they pushed the '''Download''' button and after the packages were downloaded, the button returned to a  '''Download''' button again and the application did not proceed to '''Reboot and Update'''  button. As a consequence, the system could not be updated.


It is quite safe to simply ignore these messages. They do not indicate any problem, and DNF will not actually do anything problematic in response to this situation.
If you arrive in that situation, the workaround is log out and back in again, or reboot the machine. After that, the application shows the '''Reboot and update''' button and lets you update the system.


{{Common bugs issue|dnf-unique-constraint|DNF crashes on many operations with "UNIQUE constraint failed" error|1596827}}
{{Common bugs issue|gnome-software-refresh|Refresh button in GNOME Software doesn't refresh the repos|1643444}}


Some testers who upgraded from Fedora 28 or earlier to Fedora 29 reported that, after the upgrade, DNF operations commonly fail with an error like this:
The '''Refresh''' button does not refresh the repository metadata in ''GNOME Software''. A fix has already been submitted to upstream and once it is stable, the issue will be solved in a future update.


RuntimeError: C++ std::exception: Step: UNIQUE constraint failed: comps_environment_group.environment_id, comps_environment_group.groupid in
You don't need to work around this problem, because automatic refresh of repositories works fine, so you'll be offered updated packages regularly without issues. However, if you want to force GNOME Software to show you the latest updates immediately, execute this command:
<pre>
        INSERT INTO
$ pkcon refresh force
            comps_environment_group (
</pre>
                environment_id,
                groupid,
                installed,
                group_type
            )
        VALUES
            (144536, 'libreoffice', 1, 4)


Many testers do not report being affected by this, so it does not seem to affect everybody. We currently believe the issue may relate to migration from an old transaction format history to a new one. It seems that removing or renaming the {{filename|/var/lib/dnf/history.sqlite}} stops the crashes from happening, so if you are affected by this issue, please try that.
{{Common bugs issue|gnome-software-leakin|Previous update info is leaking into current update info in GNOME Software|1642878}}


We aim to resolve this issue before the final release of Fedora 29.
When you update packages with '''Gnome Software''', some of the previously updated packages are still shown in the update queue. This problem does not affect the functionality of the application and updating packages still works fine.


== Workstation (GNOME) Issues ==
If you happen to see such behaviour, you can safely ignore it.


{{Common bugs issue|gnome-vt-x11-crash|GNOME may crash on switch back from virtual terminal under X.org with multiple displays|1630367}}
{{Common bugs issue|gnome-vt-x11-crash|GNOME may crash on switch back from virtual terminal under X.org with multiple displays|1630367}}
Line 123: Line 133:


{{Common bugs issue|switch-user-missing|''Switch user'' option missing from user menu until lock screen appears|1576903}}
{{Common bugs issue|switch-user-missing|''Switch user'' option missing from user menu until lock screen appears|1576903}}
{{Common bugs update testing|FEDORA-2018-646c51188f}}


Due to a bug, the ''Switch user'' option on the user menu (top-right menu, then expand the user name) in GNOME may be missing in any given session until the lock screen has appeared at least once. To work around this issue, you can trigger the lock screen manually.
Due to a bug, the ''Switch user'' option on the user menu (top-right menu, then expand the user name) in GNOME may be missing in any given session until the lock screen has appeared at least once. To work around this issue, you can trigger the lock screen manually. If the ''Switch user'' option still doesn't appear, you can switch to a different user from the lock screen itself, before entering your password there is a ''Log in as another user'' button.
 
{{Common bugs issue|gnome-maps-rendering|Display gets messed up when routing panel is active in Gnome Maps|1637751}}
 
On some systems, when planning a route, Gnome Maps failed to render correctly. The routing panel on the right side of the map opens, but its content is incorrectly displayed and hidden behind a white unresponsive panel. Trying to resize the panel can only help occasionally, and sometimes it might lead to even a worse situation.
 
As a workaround for this behaviour, you can use an ''Xorg'' session instead of a ''Wayland'' session. To do so, click on the settings wheel in the login screen and from the list of options, choose ''GNOME on Xorg''.  This bug will be fixed in one of the future updates.
 
{{Common bugs issue|gnome-logout-apps-crash|Running applications can lose data on log out from GNOME|1394937}}
 
If you log out from a GNOME session and have some GNOME applications running, these applications will not be terminated correctly which results in loss of data or settings, if those have not been saved before.  In order to avoid any possible problems caused by this, you should definitely save any unsaved work and ideally close running applications manually before logging out.
 
There have been some less clear reports of applications not shutting down cleanly on log out from GNOME Xorg sessions, which is under discussion in bug #1394937, but we are not yet entirely sure about the details of that possible case.
 
{{Common bugs issue|libdnf-crash-offline-updates|Offline updates get stuck towards the end due to a libdnf crash when any multilib package is installed|1642796}}
{{Common bugs update released|FEDORA-2018-32186e8871}}
 
When you perform offline updates in GNOME (reboot to perform updates), the process might crash at the very end of the process, seemingly hanging on a screen showing 97% or more percent done. We believe this most commonly occurs if you have any multilib package installed - i.e. packages of the same name for different arches installed together. This will often be the case if you run wine or some popular 32-bit third-party games and applications. If you see the percentage at 97 or higher and it does not update for half an hour or longer, force reboot using Ctrl+Alt+Del, the system should not be negatively affected in any way. The DNF team is currently working on a fix for this issue.
 
{{Common bugs issue|totem-wayland-vms|Totem and Cheese fail on Wayland in virtual machines|1467368}}
 
Totem (''Videos'') will fail to play media when using a Wayland session in virtual machines (applies to default libvirt VMs, but not VirtualBox). The audio will play, but neither video nor a totem window will appear. If you need to play media in this environment, please either use X11 session, or a different media player.
 
Cheese fails to start in a similar fashion. Because VMs usually don't have a webcam, this doesn't limit users in any way.
 
== Hardware issues ==
 
{{Common bugs issue|bluez-obex|Bluetooth connection to some devices doesn't work out of the box|1389347}}
 
On some machines, the '''bluez-obex''' service starts with erroneous settings which prevents bluetooth communication with other devices, such as mobile phones.
 
If you experience this problem, you can workaround it by running the following commands on the console:
 
<pre>
sudo dnf install bluez-obexd
systemctl --user start obex
sudo systemctl --global enable obex
</pre>
 
After that, the communication should be possible.
 
{{Common bugs issue|network-speed-kernel|1Gb/s ethernet port is configured as 10Mb/s port on selected laptops|1627816}}
 
With kernel version greater than 4.15.0, some testers have experienced a significant drop in ethernet speed after unplugging and plugging again the ethernet cable on certain laptops.  Originally, the were connected with a speed of 1Gb per second, which then dropped down to 10 Mb/s. Apparently, this only happen to affect the download speed and leaves the upload speed at its original value.
 
If you hit this problem, there are several ways to resolve this:
* restart your system with your cable already plugged in (don't plug it in when your system is running)
* run <code>ethtool -r ETHNAME</code>, where <code>ETHNAME</code> is the name of your ethernet device, possible to see e.g. in <code>ip address</code> output
 
{{Common bugs issue|iscsi-authentication|iSCSI Reverse CHAP authentication not working|1637927}}
 
In Fedora 29, the ''reverse'' (target) CHAP authentication does not work for either a discover or a login. The ''initiator'' authentication works without problems.
 
As a workaround, do not use reverse CHAP authentication for your iSCSI communication.
 
As soon as there will be a fix, this issue will be solved in future updates.
 


== ARM & AArch64 Issues ==
== ARM & AArch64 Issues ==
{{Common bugs issue|rpi-wifi|Raspberry Pi WiFI not working| 1652093 }}
{{Common bugs issue|rpi-wifi|Raspberry Pi WiFI issues on aarch64|1649344}}
A pair of regressions in the kernel included in the Fedora 29 GA release inadvertently caused the WiFi driver for Raspberry Pi devices to be intermittent. The issues have been resolved as of the 4.19.10 kernel.


{{Common bugs issue|rpi-upgrade-issues|Raspberry Pi config.txt is replaced during an upgrade from a previous release |}}
{{Common bugs issue|rpi-upgrade-issues|Raspberry Pi config.txt is replaced during an upgrade from a previous release |}}


When upgrading from a previous release on the Raspberry Pi 2/3/3+ the config.txt is replaced in the update process. To ensure any user defined settings are saved, please create a backup before upgrading. After the upgrade you will also need to re-enable the UART in config.txt  if you intend to use the serial console.  
When upgrading from a previous release on the Raspberry Pi 2/3/3+ the config.txt is replaced in the update process. To ensure any user defined settings are saved, please create a backup before upgrading. After the upgrade you will also need to re-enable the UART in config.txt  if you intend to use the serial console.
 
== XFCE, LXQT and Astronomy Spins ==
 
{{Common bugs issue|spins-missing|Some Fedora Spins are missing from final Compose |}}


{{Common bugs issue|imx6-display-network|Some imx.6 SoC's may not have working graphics or networking}}
When building Fedora 29 final ISOs, some spins (XFCE, LXQT, Astronomy) have failed to build. This issue is being addressed by Fedora Release Engineering.


Some imx6 devices currently lack support for graphics or networking in the Fedora 29 Beta. We are working to have this fixed for final.
[[Category:Common bugs]]

Revision as of 10:57, 6 July 2019

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.


Release Notes

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
    1. a summary of the problem
    2. any known workarounds
    3. 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)

Installation issues

UEFI install in 'basic graphics mode' may fail to boot

link to this item - Bugzilla: #1628495

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.

Switching keyboard layout with key combo does not work in Wayland on Fedora Workstation Live image

link to this item - Bugzilla: #1389959

If you're running Workstation Live install media and configure multiple languages in the installer, you won't be able to switch between them using the standard system shortcut (typically Win+Space or Alt+ Shift). However, you can still click on the language indicator in the installer with the mouse and that will switch the languages.

This does not affect other install media (KDE Live, DVD and netinst images).

'Basic graphics' mode will often fail on Workstation

link to this item - Bugzilla: #1691909 - Bugzilla: #1683197

Due to at least two different problems, trying to boot a Fedora 29 Workstation live image or installed system using the 'basic graphics' option will often fail; when doing a BIOS native boot it will probably always fail, with a UEFI native boot it may work.

Fortunately this option is less commonly needed than it used to be. If you have a system on which it is necessary, you may need to install a different Fedora edition until fixes or workarounds for the problems are available.

Core system issues

Cron jobs in /etc/cron.d (including cron.hourly) do not run

link to this item - Bugzilla: #1625645 - Bugzilla: #1639381

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.

To work around this problem until it is resolved, a comment on the bug report contains a suggested CIL-formatted policy that allows these jobs to run:

(allow unconfined_t system_cron_spool_t( file ( entrypoint)))

to use this, save that single line to a file with the extension .cil, e.g. crond.cil, and load it with semodule, e.g. 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

link to this item - Bugzilla: #1616167

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 the --disablerepo argument 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.

DNF doesn't resolve variables in mirrorlists

link to this item - Bugzilla: #1637148

When a yum/dnf repository uses a mirrorlist link, and the content of this link contains URLs with special dnf variables, such as $releasever or $basearch, DNF is unable to replace them with correct release values and fails to download metadata from those links.

Such behaviour did not happen in previous version of Fedora and there is no workaround for it. A fix has been submitted to solve it. When it is found helpful, this issues will be solved in one of the future updates.

DNF logs very verbosely by default, leads to large log files

link to this item - Bugzilla: #1355764

By default, the DNF included with Fedora 29 does some very verbose logging. Especially the file /var/log/dnf.librepo.log contains very detailed logging of mirror selection and file download operations. Some operations, such as a system upgrade or reposync, can potentially cause multiple gigabytes of messages to be written to this log file. The DNF log files are configured for rotation, so they will be compressed and expired weekly so long as Package-x-generic-16.pnglogrotate is installed, but this can be insufficient when a single operation can cause the files to grow very large.

If the DNF log files are filling up your disk and you need a solution urgently, it is safe to simply remove the log files (after copying them elsewhere if you need them for reference), this will not break anything. A future libdnf update is planned to reduce the dnf.librepo.log verbosity. Until then, if this is an ongoing problem for you, you can work around it by redirecting the log output to /dev/null - see this bug comment for one way to do that.

System update fails when trying to remove rtkit-0.11-19.fc29

link to this item - Bugzilla: #1637496

This affects only Fedora 29 pre-release installations. If you have rtkit-0.11-19.fc29 in your system, an update to a later rtkit will fail, because the older version can't be removed. You can check what version of rtkit you have with this command:

$ rpm -q rtkit
rtkit-0.11-20.fc29.x86_64

If your base installation had at least rtkit-0.11-20.fc29, you should be fine. You can check whether you are affected by first fully updating your system, and then by running:

$ sudo dnf check
rtkit-0.11-19.fc29.x86_64 is a duplicate with rtkit-0.11-20.fc29.x86_64
Error: Check discovered 1 problem(s)

If you see a problem like the one above, you can force-remove the older rtkit by running:

$ sudo rpm -e --noscripts --allmatches rtkit-0.11-19.fc29.x86_64

and then verify:

$ sudo dnf check
$ 

Package management tools (dnf, GNOME Software etc.) can crash when more than one runs at once

link to this item - Bugzilla: #1631533

Note: We hope this problem has been fixed in the final Fedora 29 release and should no longer happen. In case you can still see it with a fully up-to-date system, see the description below and please provide your feedback in RHBZ #1631533.

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 Exec failed: database is locked. 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.

DNF crashes on upgraded systems

link to this item - Bugzilla: #1600917

The dnf utility can crash when encountering history database created on previous release (F28, F27, etc.), which is common on system-upgraded installations.

Workaround for now is to remove /var/lib/dnf/history/ directory. Be aware that this will remove all entries from dnf history!

Workstation (GNOME) Issues

Download progress is often invisible if GNOME Software

link to this item - Bugzilla: #1643446

When you update your system with Gnome Software, sometimes the progress bar showing the percentage of downloaded packages is not correctly visible on the lower part of the Cancel button. This problem does not affect the functionality of the application and updating the system still works fine.

Note, that downloading the package set may take several minutes and the application may look unresponsive. If you see such behaviour, do not cancel the download process and wait until it is finished and you are offered to Reboot and Install.

Download button in GNOME Software performs the download, but then changes back to Download

link to this item - Bugzilla: #1643059

Some testers experienced a situation, when, during system update via Gnome Software, they pushed the Download button and after the packages were downloaded, the button returned to a Download button again and the application did not proceed to Reboot and Update button. As a consequence, the system could not be updated.

If you arrive in that situation, the workaround is log out and back in again, or reboot the machine. After that, the application shows the Reboot and update button and lets you update the system.

Refresh button in GNOME Software doesn't refresh the repos

link to this item - Bugzilla: #1643444

The Refresh button does not refresh the repository metadata in GNOME Software. A fix has already been submitted to upstream and once it is stable, the issue will be solved in a future update.

You don't need to work around this problem, because automatic refresh of repositories works fine, so you'll be offered updated packages regularly without issues. However, if you want to force GNOME Software to show you the latest updates immediately, execute this command:

$ pkcon refresh force

Previous update info is leaking into current update info in GNOME Software

link to this item - Bugzilla: #1642878

When you update packages with Gnome Software, some of the previously updated packages are still shown in the update queue. This problem does not affect the functionality of the application and updating packages still works fine.

If you happen to see such behaviour, you can safely ignore it.

GNOME may crash on switch back from virtual terminal under X.org with multiple displays

link to this item - Bugzilla: #1630367

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.

Switch user option missing from user menu until lock screen appears

link to this item - Bugzilla: #1576903

Due to a bug, the Switch user option on the user menu (top-right menu, then expand the user name) in GNOME may be missing in any given session until the lock screen has appeared at least once. To work around this issue, you can trigger the lock screen manually. If the Switch user option still doesn't appear, you can switch to a different user from the lock screen itself, before entering your password there is a Log in as another user button.

Display gets messed up when routing panel is active in Gnome Maps

link to this item - Bugzilla: #1637751

On some systems, when planning a route, Gnome Maps failed to render correctly. The routing panel on the right side of the map opens, but its content is incorrectly displayed and hidden behind a white unresponsive panel. Trying to resize the panel can only help occasionally, and sometimes it might lead to even a worse situation.

As a workaround for this behaviour, you can use an Xorg session instead of a Wayland session. To do so, click on the settings wheel in the login screen and from the list of options, choose GNOME on Xorg. This bug will be fixed in one of the future updates.

Running applications can lose data on log out from GNOME

link to this item - Bugzilla: #1394937

If you log out from a GNOME session and have some GNOME applications running, these applications will not be terminated correctly which results in loss of data or settings, if those have not been saved before. In order to avoid any possible problems caused by this, you should definitely save any unsaved work and ideally close running applications manually before logging out.

There have been some less clear reports of applications not shutting down cleanly on log out from GNOME Xorg sessions, which is under discussion in bug #1394937, but we are not yet entirely sure about the details of that possible case.

Offline updates get stuck towards the end due to a libdnf crash when any multilib package is installed

link to this item - Bugzilla: #1642796

Idea.png
Fix released
An update has been released to address this problem. After you update your system in your usual way, and possibly reboot, you should no longer be affected by it.

When you perform offline updates in GNOME (reboot to perform updates), the process might crash at the very end of the process, seemingly hanging on a screen showing 97% or more percent done. We believe this most commonly occurs if you have any multilib package installed - i.e. packages of the same name for different arches installed together. This will often be the case if you run wine or some popular 32-bit third-party games and applications. If you see the percentage at 97 or higher and it does not update for half an hour or longer, force reboot using Ctrl+Alt+Del, the system should not be negatively affected in any way. The DNF team is currently working on a fix for this issue.

Totem and Cheese fail on Wayland in virtual machines

link to this item - Bugzilla: #1467368

Totem (Videos) will fail to play media when using a Wayland session in virtual machines (applies to default libvirt VMs, but not VirtualBox). The audio will play, but neither video nor a totem window will appear. If you need to play media in this environment, please either use X11 session, or a different media player.

Cheese fails to start in a similar fashion. Because VMs usually don't have a webcam, this doesn't limit users in any way.

Hardware issues

Bluetooth connection to some devices doesn't work out of the box

link to this item - Bugzilla: #1389347

On some machines, the bluez-obex service starts with erroneous settings which prevents bluetooth communication with other devices, such as mobile phones.

If you experience this problem, you can workaround it by running the following commands on the console:

sudo dnf install bluez-obexd
systemctl --user start obex
sudo systemctl --global enable obex

After that, the communication should be possible.

1Gb/s ethernet port is configured as 10Mb/s port on selected laptops

link to this item - Bugzilla: #1627816

With kernel version greater than 4.15.0, some testers have experienced a significant drop in ethernet speed after unplugging and plugging again the ethernet cable on certain laptops. Originally, the were connected with a speed of 1Gb per second, which then dropped down to 10 Mb/s. Apparently, this only happen to affect the download speed and leaves the upload speed at its original value.

If you hit this problem, there are several ways to resolve this:

  • restart your system with your cable already plugged in (don't plug it in when your system is running)
  • run ethtool -r ETHNAME, where ETHNAME is the name of your ethernet device, possible to see e.g. in ip address output

iSCSI Reverse CHAP authentication not working

link to this item - Bugzilla: #1637927

In Fedora 29, the reverse (target) CHAP authentication does not work for either a discover or a login. The initiator authentication works without problems.

As a workaround, do not use reverse CHAP authentication for your iSCSI communication.

As soon as there will be a fix, this issue will be solved in future updates.


ARM & AArch64 Issues

Raspberry Pi WiFI not working

link to this item - Bugzilla: # 1652093

Raspberry Pi WiFI issues on aarch64

link to this item - Bugzilla: #1649344

A pair of regressions in the kernel included in the Fedora 29 GA release inadvertently caused the WiFi driver for Raspberry Pi devices to be intermittent. The issues have been resolved as of the 4.19.10 kernel.

Raspberry Pi config.txt is replaced during an upgrade from a previous release

link to this item

When upgrading from a previous release on the Raspberry Pi 2/3/3+ the config.txt is replaced in the update process. To ensure any user defined settings are saved, please create a backup before upgrading. After the upgrade you will also need to re-enable the UART in config.txt if you intend to use the serial console.

XFCE, LXQT and Astronomy Spins

Some Fedora Spins are missing from final Compose

link to this item

When building Fedora 29 final ISOs, some spins (XFCE, LXQT, Astronomy) have failed to build. This issue is being addressed by Fedora Release Engineering.