From Fedora Project Wiki

m
Line 110: Line 110:
 
</code>  
 
</code>  
  
{{Common bugs issue|bluez-obex|bluez obex dbus service is incorrectly setup|1389347}}
+
{{Common bugs issue|bluez-obex|bluez obex dbus service is incorrectly set up|1389347}}
  
 
On some machines, the '''bluez-obex''' service starts with erroneous settings which prevents bluetooth communication with other devices, such as mobile phones.  
 
On some machines, the '''bluez-obex''' service starts with erroneous settings which prevents bluetooth communication with other devices, such as mobile phones.  

Revision as of 16:49, 26 October 2018

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.

Note.png
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

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.

Upgrade issues

Core system issues

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

link to this item - Bugzilla: #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 doesn't resolve variables in mirrorlists

link to this item - Bugzilla: #1637148

When a yum/dnf repository contain links to on-line mirrorlists and these mirrorlists use variables, such as $releasever or $basearch within their URLs, 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.

Printing via CUPS filters does not work

link to this item - Bugzilla: #1628255

Idea.png
Update available for testing
A candidate fix for this issue has been submitted to the updates-testing repository for testing. Users experiencing this problem are encouraged to test this update and report to Bodhi whether it solves the problem. To test the update, run this command: sudo dnf --enablerepo=updates-testing update --advisory=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 the bug report.

Installing the update (see above) is likely easier than any method for 'working around' this problem.

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

link to this item - Bugzilla: #1637496

This affects most 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
$ 

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 prints misleading "cannot install the best update candidate" messages for packages where newer version exists in disabled module

link to this item - Bugzilla: #1616118

When using DNF to update packages on Fedora 29, you may see worrying warning messages like this:

Problem 1: cannot install the best update candidate for package bubblewrap-0.3.0-2.fc29.x86_64
 - 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.

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.

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.

1Gb/s ethernet port is configured as 10Mb/s port on Thinkpad T480s

link to this item - Bugzilla: #1627816

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

If you hit this problem, restart NetworkManager:

sudo systemctl restart NetworkManager.service

bluez obex dbus service is incorrectly set up

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.

Workstation (GNOME) Issues

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.

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 far as we know, there is no workaround for this behaviour. This bug will be fixed in one of the future updates.

Switch user option missing from user menu until lock screen appears

link to this item - Bugzilla: #1576903

Idea.png
Update available for testing
A candidate fix for this issue has been submitted to the updates-testing repository for testing. Users experiencing this problem are encouraged to test this update and report to Bodhi whether it solves the problem. To test the update, run this command: sudo dnf --enablerepo=updates-testing update --advisory=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.

ARM & AArch64 Issues

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.

Some imx.6 SoC's may not have working graphics or networking

link to this item

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