This page documents common bugs in Fedora 28 and, if available, fixes or workarounds for these problems. If you find your problem in this page, please 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 GNOME issues
- 6.1 Wayland issues
- 6.2 Modifiers (shift, ctrl etc.) not applied to first character in passwords entered to GNOME Shell password dialogs (affects passwords starting with capital letters, pasting with ctrl-v...)
- 6.3 Right-click and middle-click by touchpad area no longer work by default
- 6.4 Totem and Cheese fail on Wayland in virtual machines
- 6.5 Scroll events are not sent into virtual machines from touchpad/trackpoint under Wayland
- 6.6 Content of VPN entry in GNOME status menu sometimes does not appear
- 6.7 Non-empty directories on Samba shares can't be deleted by Nautilus
- 6.8 Keyboard layout in Login Screen (GDM) is ignored and US is used
- 7 Plasma (KDE) issues
- 8 Network issues
- 9 Hardware issues
- 10 Application issues
- 11 ARM issues
- 12 Fedora Server issues
- 13 Fedora Cloud issues
- 14 Fedora Atomic issues
- 15 Cinnamon in QEMU/KVM
- 16 Soas issues
- 17 Other issues
- 18 See also
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)
Switching keyboard layout with key combo does not work in Wayland
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+ or + ). 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).
Installer on several live images does not offer iSCSI support
On many or all Fedora Live images, the installer will not offer iSCSI functionality (the "Add iSCSI target" button will not appear in the 'Specialized & Network Disks' screen). You can avoid the problem by running
sudo dnf install udisks2-iscsi from a console before starting the install process, or by installing from a dedicated installer image rather than a live image.
Upgrade from Fedora 26 might fail due to rich dependencies
When you upgrade from Fedora 26 to Fedora 27 or 28, the transaction might get aborted immediately due to target packages having rich dependencies. The list of such packages as of Mar 2018 is available in bug 1552547. Eventually, the intended solution is to send updated dnf+rpm into Fedora 26 to handle this transaction properly. In the meantime, the easiest workaround is to remove affected packages before doing the upgrade, and install them back in the upgraded system.
GRUB update might fail if /boot is on XFS
If you use XFS filesystem on
/boot and upgrade your system, you might end up in a GRUB minimal prompt (just a command prompt, no kernel to choose from interactively) after the upgrade is complete. The problem is in the system rebooting while XFS is in dirty state and not all changes being saved to the filesystem yet.
In order to prevent this issue, you might try to disable plymouth (by removing
rhgb kernel boot option) during the upgrade or uninstall it prior the upgrade (these workarounds were not tested).
If this already occurred to you, you should be able to fix the problem by booting a Live or rescue image, mounting the filesystem in question (which should replay the journal), perhaps running
xfs_repair to make sure there are no more issues. In the worst case, you'll also need to fully re-install grub.
Core system issues
Boot process is very slow or appears to hang with kernel 4.16.4 onwards
From version 4.16.4, the kernel (upstream: this issue is not Fedora-specific) is stricter in determining when the kernel is "ready" to supply random numbers. Previously it indicated it was "ready" when the RNG was able to provide only a limited degree of randomness; now it indicates it is "ready" only when the RNG is able to provide randomness sufficient for cryptographic purposes. This was considered a security issue.
If any part of a system's boot process happens to involve blocking on this "readiness", the boot process will be delayed until the kernel indicates it is "ready", and of course with this change, that becomes more likely to happen. This is particularly likely to affect systems without access to a hardware random number generator and with only limited internal sources of entropy; in practice this means it commonly affects virtual machines and cloud instances. In particularly serious cases, the delay can be such that timeouts kick in and the system fails to boot fully.
If your system seems to boot fine with kernel 4.16.3 or earlier, but is slow to boot or appears to hang during boot with 4.16.4 and later, you may well be affected by this issue. You can try simply hitting random keys on the keyboard when the boot process appears to hang: this acts as a source of entropy and allows the kernel to seed its RNG. If you can get the boot process to continue after several seconds of keyboard mashing, this indicates you are suffering from this issue. It can also be a viable workaround in some cases, though of course not all.
For virtual machines and cloud instances, allowing the host to provide entropy to the VM/instance can help significantly, particularly if the host has a hardware RNG and this is configured as the source. The details of how to do this vary between virtualization systems and clouds. This page documents how to do it in OpenStack. This test case includes some information on how to do it in libvirt. This page explains how to do it directly in qemu. Other virtualization systems may also support virtio-rng.
A particularly severe form of this issue manifests itself if you boot with an initramfs generated while
is installed. In this case the boot process will hang extremely early (at the time systemd starts up, so if any systemd activity has happened at all, you are already past this case), and the use of virtio-rng will not help (for VMs/cloud instances) as it is not yet loaded at this point. If you find yourself in this situation, it's probably best to remove
sudo dracut -f to re-generate the initramfs for the current kernel. This form of the issue may potentially affect Fedora images generated with kernel 4.16.4 or later, but so far as we know, no official or semi-official images affected by this issue have yet been released.
Wayland is the replacement for the legacy X11 display stack. Although development has been rapid and Wayland is usable in most situations, some bugs remain. Please see the following link to learn the details:
Please check the list for your issue before you file a new bug, although if you're not sure, filing a new bug is the right thing to do.
Wayland is currently enabled by default only in GNOME. If you want to disable it, select GNOME on Xorg as session type when logging in (you only see this screen if your user has a password defined):
Modifiers (shift, ctrl etc.) not applied to first character in passwords entered to GNOME Shell password dialogs (affects passwords starting with capital letters, pasting with ctrl-v...)
Some users have reported problems entering passwords in GNOME Shell password dialogs (which includes the login prompt to GNOME itself, and other password prompts produced by GNOME Shell, e.g. when unlocking the screen, or when prompted to enter an ssh key passphrase when attempting to ssh into a system via gnome-terminal, or when prompted to enter a GPG key passphrase to encrypt a mail in Evolution). The second attempt is usually successful. Further investigations have shown that the problem only occurs when trying to use a modifier on the first character entered into the password dialog. One common case for this is if the password starts with a capital letter. It may also be a problem if you try to paste a password into the prompt using- this may just type a 'v' - or the password starts with a non-ASCII character that requires use of the Alt Gr modifier.
The update linked above resolves this issue when installed. However, you might still encounter the issue when using the Workstation live image, and immediately after installing it and before updating the system for the first time. The bug only affects certain passwords, and is easy to work around. You can type any letter in the password field, delete that letter using backspace, and then you can write (or paste) the correct password. Alternatively, repeat the login attempt. Note, you can right-click on the password entry box and click 'Show Password' to see the text that is currently entered, though of course do not do this if anyone else can see your screen.
Right-click and middle-click by touchpad area no longer work by default
This issue is not actually a bug, but an intentional change; however it may well present as a bug to surprised users. If you use GNOME on Fedora on a laptop with a touchpad without dedicated mouse buttons and are accustomed to clicking the bottom-right of the touchpad to produce a right mouse button click and the bottom middle of the touchpad to produce a middle mouse button click, you may be surprised to find this no longer works in Fedora 28. This is because the default behaviour was changed by GNOME to what is referred to as 'clickfinger' behaviour, as seen on macOS. With 'clickfinger', to produce a right click you are intended to click the touchpad with two fingers in contact with it, and to produce a middle click you click the touchpad with three fingers in contact with it.
If you would prefer to go back to the previous area-based behaviour, you can configure this by using GNOME Tweak Tool. Install Tweak Tool (from GNOME Software or by running
dnf install gnome-tweak-tool), run it, and go to Keyboard & Mouse. Here, change the Mouse Click Emulation setting from Fingers to Area.
Totem and Cheese fail on Wayland in virtual machines
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.
Scroll events are not sent into virtual machines from touchpad/trackpoint under Wayland
Under Wayland, sending scroll events into a virtual machine works well when using the mouse, but doesn't work when using touchpad or trackpoint. As a workaround, switch to Xorg session on your host.
Some users have reported that, sometimes, the icon and text of the VPN entry in the GNOME status menu (the one that appears when you click the top-right of the screen) does not appear. Usually it will show a lock icon and the text 'VPN Off' (or information on any active VPN connection), but it appears that occasionally the icon and text do not appear; the menu just appears to contain an entirely empty row. The entry does function as intended.
No fix for this issue is yet known, but it has no functional impact - you can still use the 'empty' menu item.
If you access Samba (smb) shares using Nautilus, it's not possible to delete non-empty directories due to a bug. Current workaround is to delete files in that directory first (tedious), or try to use a different application for accessing that share (Dolphin has been reported to work correctly).
Keyboard layout in Login Screen (GDM) is ignored and US is used
Keyboard layout indicator in GDM is out of sync. As a workaround, you might need to choose English to get the correct (Czech, Spanish, etc) keyboard.
Plasma (KDE) issues
Power management does not work on KDE live images, initial install
Due to a bug, in the Fedora 28 KDE live images, the default configuration for the Powerdevil power management daemon is never generated. This means that just about everything controlled by powerdevil - including suspend on lid close for laptops, responding to power button presses, and so on - does not work.
The update linked above fixes this problem, but of course only takes effect after the system is installed and updated, so this issue will continue to affect the live environment and the installed system immediately after install from a live image, before the system is updated and rebooted for the first time.
A couple of testers so far have reported that attempting to configure a Fedora 28 system to use a printer shared from a Windows system on the same network fails. We are still investigating the details of this issue and thus any potential workarounds, but in the mean time if you are having trouble with this, you could possibly try connecting the printer to the Fedora 28 system, configuring it locally, and sharing it from Fedora for the Windows machine to use, or some other similar workaround, like using the printer's built-in network sharing ability if it has it.
Certain laptops (Lenovo) hang randomly
Certain laptops (so far, Lenovo G50-80, X250 and T450s were confirmed) completely freeze at random when using Fedora 28. This is caused by SATA LPM (link power management) being enabled in Fedora 28 in order to save battery, but apparently some vendors' firmware doesn't work well with it. If this happens to you, try booting with
ahci.mobile_lpm_policy=0 kernel command line. If that helps, please tell us in the bug report linked above, so that we can fix it permanently for your device.
Connecting or disconnecting Thunderbolt 3 dock causes a system crash
Multiple testers have reported that connecting or disconnecting a Thunderbolt 3 dock to or from a system can cause it to crash. The kernel update linked above should resolve this issue when installed and booted, but you may still encounter this issue during use of a live image, installation of Fedora 28, or on initial use of an installed system before the first update. There is no known workaround, so we recommend not connecting/disconnecting docks while installing or using a live environment, and updating newly installed systems immediately.
Firefox crashes on certain pages
Certain pages have been identified to make Firefox 59 (shipping in Fedora 28 on release day) crash. You can read more in the bug linked above. Firefox 60 should resolve this, and we will try to make it reach stable updates as soon as possible.
In Fedora 28, if you try to run a qemu virtual machine (including default virt-manager and GNOME Boxes virtual machines) with a disk image stored on an SMB share, it may fail to start with a 'Failed to get "write" lock' error.
Unfortunately, the only known workaround for this issue at present is to move the image to a local disk, or to a different type of network share.
The Raspberry Pi graphics driver intermittently crashes
link to this item - Bugzilla: #1387733 The VC4 graphics driver used on the Raspberry Pi intermittently crashes, often on boot which can result in a black screen. If left for a few minutes the system often recovers. Alternatively you can disconnect/reconnect the HDMI cable or reboot the board.
Initial-setup fails to run on ARM disk images in QEMU on x86_64 & BeagleBone hardware
The Initial-setup configuration utility does not run on the BeagleBone or when the disk images are run in QEMU. To configure the disk image for use you will first need to run
dnf install libguestfs-tools. Then to configure the image setting the root password to 'fedora' and copying your user ssh public key use
'virt-sysprep -a /path/to/image --root-password password:fedora --ssh-inject root:file:/path/to/ssh/key.pub' . Note for security reasons it is recommended to use the public key only.
Raspberry Pi B+ network errors in U-Boot
When using AArch64 disk images on the newly released Raspberry Pi 3 B+, there may repeated network errors (Rx: failed to receive: -5) in U-Boot. The system will eventually boot and once the Linux kernel takes over they will stop, often unplugging connected cables until the kernel is started can speed up the boot process. This has been reported upstream and will be fixed in an update.
Pine 64 intermittent boot errors
Intermittently during boot you may see 'error: failure reading sector 0x6cc88 from `hd0'.' or similar which often results in a kernel panic. Resetting the board should allow the system to boot successfully. Some media may perform better than others.
Fedora Server issues
Wifi, network sharing, Bluetooth network support not included in Fedora Server 64-bit ARM disk images
The Fedora 28 64-bit ARM (aarch64) Server disk images mistakenly do not include theand package groups. These include NetworkManager support for wifi networking and the firmware packages for many wifi adapters, connection sharing via NetworkManager, Bluetooth networking and various other things intended to be included in all Fedora images by default.
You can install the missing packages by running
dnf groupinstall hardware-support networkmanager-submodules after deploying the disk image, if you can access the network via a wired connection. Another workaround on hardware which supports it would be to install from the DVD installer image, which does not have this problem (it includes and will install the package groups). If neither of these are an option, you may have to download at least the `NetworkManager-wifi` package and any firmware packages needed by your device's wireless adapter to an SD card or USB stick and install them that way.
Fedora Cloud issues
Fedora Atomic issues
Cinnamon in QEMU/KVM
Cinnamon Beta 1.3 live.iso only runs openbox
How to install:
- liveuser login (no password)
- openbox-terminal (right click on blank screen for menu)
- su liveinst
- after install reboot in terminal
- su dnf update (349)
- reboot to cinnamon (defaults to fallback mode cinnamon)
Red Hat Bugzilla – Bug 1519042 soas starts in journal: This can be confusing for users
Fix by hitting f1 key then f3 key to get to main menu
VBox Guest Additions
- According to https://fedoraproject.org/wiki/Changes/VirtualBox_Guest_Integration , f28 is coming with guest additions prepacked
- this issue is thus only valid when Fedora is the gest system, not the host
- unluckily, the feature was not completely finished
- the vboxsf - driver for virtualbox shared folder did not make it to kernel in time (awaiting review)
- that say, your shared folders not work right now
- you can compile the driver on your own (as upstream do not support newest (F28's) kernel (yet)
git clone https://github.com/jwrdegoede/vboxsf/ make sudo make modules_install sudo depmod -a
- however self compiled vboxsf is suffering by unspecified bug in kernel, which is fixed in 4.17
- this issue is causing whole vboxsf module to fail, on VMs with more then 4GB of ram
- you can install fixed kernel on your own: https://koji.fedoraproject.org/koji/buildinfo?buildID=1077838
- as by https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt
Tahnx to Hans de Goede for all those info.