From Fedora Project Wiki

(qt5-scaling-too-aggresive|Certain QT5 apps (VLC, Calibre) are scaled up or down when they should not be|1381828)
(edit 1170803 to be more precise and less scary about the updates image (it's pretty safe))
Line 22: Line 22:
This does not affect other install media (KDE Live, DVD and netinst images).
This does not affect other install media (KDE Live, DVD and netinst images).


{{Common bugs issue|anaconda-fsck-slow|Disk initialization in installer can take a very long time on huge disks due to fsck being performed|1170803}}
{{Common bugs issue|anaconda-fsck-slow|Disk initialization in installer can take a very long time if large ext filesystems are present|1170803}}


When checking existing disks prior to installation, the installer runs <code>fsck</code> (filesystem consistency check) on all of them. For huge disks (several TBs or more) containing huge number of files, this can take hours to finish.
When checking existing disks prior to installation, the installer runs an {{code|e2fsck}} (filesystem consistency check) on all ext2/3/4 filesystems. For large (1TB+) filesystems, this can take hours to finish. There is no obvious indicator that this is occurring, but if you know your system has large ext filesystems and the installer pauses for a long time when starting up, this is likely the cause.


There is an [https://bugzilla.redhat.com/show_bug.cgi?id=1170803#c54 experimental update] which can completely skip the filesystem check, but you're using that on your risk.
In most cases this check is not necessary. If you are not planning to make any changes to the existing filesystems as part of your installation, or you already know they are clean, you can use an [[Anaconda/Updates|updates image]] which disables the check. To use it, boot the install media normally, but at the bootloader screen, edit the boot parameters and add {{code|inst.updates=<nowiki>https://www.happyassassin.net/updates/1170803.0.img</nowiki>}}.


{{Common bugs issue|grub-relocation-failed|Dual booting Windows fails with 'relocation failed' error on some UEFI systems|1347291}}
{{Common bugs issue|grub-relocation-failed|Dual booting Windows fails with 'relocation failed' error on some UEFI systems|1347291}}

Revision as of 16:36, 21 November 2016

This page documents common bugs in Fedora 25 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.

Pre-release version
Fedora 25 has not yet been released. During this pre-release period, this page will cover known issues in the Fedora 25 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 F25 general release announcement for specific information about changes in Fedora 25 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

Switching keyboard layout with key combo does not work in Wayland

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).

Disk initialization in installer can take a very long time if large ext filesystems are present

link to this item - Bugzilla: #1170803

When checking existing disks prior to installation, the installer runs an e2fsck (filesystem consistency check) on all ext2/3/4 filesystems. For large (1TB+) filesystems, this can take hours to finish. There is no obvious indicator that this is occurring, but if you know your system has large ext filesystems and the installer pauses for a long time when starting up, this is likely the cause.

In most cases this check is not necessary. If you are not planning to make any changes to the existing filesystems as part of your installation, or you already know they are clean, you can use an updates image which disables the check. To use it, boot the install media normally, but at the bootloader screen, edit the boot parameters and add {{{1}}}.

Dual booting Windows fails with 'relocation failed' error on some UEFI systems

link to this item - Bugzilla: #1347291

On some hardware, it's not possible to start Windows (possibly even some other OSes) from GRUB boot menu when booting over UEFI (it does not happen in BIOS mode). The message says error: relocation failed. The problem is still being investigated.

As a workaround, you can use your UEFI boot menu (the one-time boot menu is usually reachable via some hotkey like Esc, F8, F11, F12, etc) to boot Windows, which should work fine.

Advanced users can download and install grub2-2.02-0.25.fc23 (grub2 from Fedora 23), which should immediately fix the problem. However, when using this solution, the broken version of grub2 from Fedora 24 will be offered to you with every new system update, and you'll need to manually exclude it every time.

Windows entry is missing in grub when systems are installed on firmware RAID on UEFI system

link to this item - Bugzilla: #1347273

When Fedora is installed beside Windows on the firmware RAID and on UEFI it could happen that there will be Windows entry missing in grub menu.

This happens only with UEFI. User can use UEFI boot menu as a workaround (the one-time boot menu is usually reachable via some hotkey like Esc, F8, F11, F12, etc).

This bug appears just when UEFI and firmware RAID is used. So BIOS installations and normal disks (or with FW RAID turned off) shouldn't be affected.

Fedora fails to install on some RAID setups

link to this item - Bugzilla: #1333131 - Bugzilla: #1259953 - Bugzilla: #1382274

On some setups, installing Fedora over existing firmware or software RAID can cause anaconda to crash.

  • If you try to create a RAID array during setup on a system that has an existing RAID configuration using the drives from that previous RAID array, the newly-created one gets produced incorrectly and is unusable (and of course, the one you deleted is no longer there). User can restart and try again on the same selected drives (this time using free space) as workaround.
  • The installer might crash on startup with certain non-intel firmware RAIDs. No further details are known at the moment.

OS X volumes using Apple Core Storage are not recognized by the installer and shrinking them destroys all data

link to this item - Bugzilla: #1033778

The installer appears to support volume shrink for OS X volumes (Apple Core Storage) by offering a Shrink button and sizing slider in Automatic partitioning; and likewise allow numeric resizing in Manual partitioning. However, setting the installer to resize these volumes and proceeding with installation will result in complete data loss of the volume. Resize the volume in OS X's Disk Utility to create free space before proceeding with the installation of Fedora.


Upgrade issues

DNF upgrade might remove essential system packages if you used PackageKit (GNOME Software, KDE Apper) in the past

link to this item - Bugzilla: #1259865

There was an unfortunate situation in the past few Fedora releases where PackageKit and DNF didn't work well together. If you installed something via PackageKit (used by GNOME Software or KDE Apper), it didn't mark such packages as "user installed" in the DNF database (which is used to differentiate user-requested packages from other packages installed purely as a dependency, but not explicitly requested by the user). Similarly, if you updated your system using PackageKit (GNOME offline updates, Apper), it erased such "user installed" flags from all updated packages. DNF then tries to remove any unnecessary packages during its next transaction (or when specifically asked using sudo dnf autoremove). This might lead to removing core system packages because DNF no longer sees them as "user installed" and considers them a no-longer-needed dependency. It is also possible that this might happen to you when performing a system upgrade to Fedora 25.

Fedora 25 hasn't been affected by this bug at all, and it was fixed in Fedora 23 and 24 since libhif-0.2.2-3. Current use of PackageKit (GNOME Software, Apper) should be safe. However, if you have ever used these tools in the past, you're strongly advised to fix your "user installed" database before you try to upgrade to Fedora 25:

  1. First, make sure your libhif package version is the same as described above or newer:
    rpm -q libhif

    If not, update it, and check again:

    sudo dnf --refresh update libhif
    Reboot after update.
  2. Then, mark all your current packages as "user installed" using this command:
    rpm -qa --qf '%{NAME}\n' | xargs sudo dnf mark install

Please note that this solution is slightly excessive, because you're going to end up with all your packages considered either system essential or user requested, and none of them is ever going to be removed as a no-longer-needed dependency. However, this is the only way how to be absolutely sure that you're not going to be affected by this issue, at a relatively small cost (some packages might stay on your disk unnecessarily). Power users can tweak this solution according to their needs.

Frozen gray screen during logging in after upgrade

link to this item - Bugzilla: #1394755

In certain configurations, you might not be able to log in after upgrade from Fedora 24. Once you provide your password and confirm, the screen will stay gray and the mouse pointer will get stuck, and nothing else will happen. If this happens to you and you're moderately technically skilled, we would welcome your feedback in bug 1394755 and test mailing list (see the instructions).

The existing workaround is to select Xorg session in the session picker (see #Wayland issues) and log in at least once. Then it should be possible to log in even to Wayland session.

Core system issues

Wayland issues

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):

Vino server (remote desktop server) crashes on login under Wayland

link to this item - Bugzilla: #1394599

If you have configured a remote desktop server using vino-server (available e.g. in GNOME settings), you'll see a crash each time you log in into a Wayland session. Remote desktop functionality is not yet supported under Wayland. Either disable the remote desktop server (Settings -> Sharing -> Screen sharing) to avoid seeing the crash notifications or use Xorg session instead (if you require remote desktop functionality).

Most QT5 apps crash under Wayland when displaying a file dialog if you don't have qgnomeplatform installed

link to this item - Bugzilla: #1392605

If you've upgraded your system from Fedora 23 or older, you might not have qgnomeplatform package installed. As a consequence, QT5 apps crash when trying to display a file dialog under Wayland. The workaround is to install qgnomeplatform package:

$ sudo dnf install qgnomeplatform

GNOME issues

Many apps crash when logging out of GNOME

link to this item - Bugzilla: #1366897

If you log out from GNOME and have some apps started, you might see a notification on your next login that those apps crashed (at the time of your last logout). The bug is being investigated. In the mean time, be sure to save your work and close apps sensitive to incorrect termination before you log out.

Plasma (KDE) issues

Logging out second user kills first user's session on KDE in a virtual machine (QXL driver)

link to this item - Bugzilla: #1382001

When you live switch users, logging out the second user kills the first user's session. This only happens with QXL driver which is used in virtual machines by default (GNOME Boxes, virt-manager).

Network issues

Hardware issues

External displays are not disconnected after undocking

link to this item - Bugzilla: #1392885

If you use a docking station with an external display attached and undock your laptop, the system will think the external display is still connected and will not automatically make the screen disappear (but you won't be able to see its contents). You can manually disable the screen using your desktop's configuration tools.

This is only a problem for Live environment and clean installs (with kernel-4.8.6-300.fc25). It has been fixed in kernel-4.8.7-300.fc25, which is available as an update.

Application issues

Certain QT5 apps (VLC, Calibre) are scaled up or down when they should not be

link to this item - Bugzilla: #1381828

Certain QT5 apps like VLC or Calibre are configured to use window scaling for high DPI monitors. However, the implementation scales the applications even on some standard (Full HD) monitors. It also further adjust the scaling if you have several monitors attached. In the end you might see a very huge or a very tiny widgets/fonts.

There is no known workaround at the moment.

ARM issues

Fedora Server issues

Fedora Cloud issues

Other issues

Hibernation doesn't work from a standard install

link to this item - Bugzilla: #1206936

The systemd-hibernate generator used to handle resume from hibernate functionality expects a resume=/path/to/swap in the kernel args. Anaconda does not add this into /etc/default/grub and the dracut cmdline generator doesn't act in a way the systemd hibernate generator can locate the swap with the resume image.

To work around this, check the devmapper path to the swap via swapon -s command and add it to the GRUB_CMDLINE_LINUX entry in /etc/default/grub, then regenerate the grub.cfg file used:

  • Via grub2-mkconfig:
    • For BIOS systems:
      sudo grub2-mkconfig -o /boot/grub2/grub.cfg
    • For EFI systems:
      sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
  • Via grubby:
    sudo grubby --args=resume=/path/to/swap --update-kernel=$(grubby --default-kernel)


Booting other UEFI Linux distributions might not work from Fedora bootloader

link to this item - Bugzilla: #1353026

Certain people who have multiple Linux distributions installed (in UEFI mode on GPT disks) report they're not able to boot non-Fedora systems from Fedora bootloader. If this happens to you, please tell us in RHBZ #1353026. The workaround should be to use your UEFI firmware to display a one-time boot menu (often displayed with F8, F10, F11, F12 or Esc) and pick the system you want to boot. That will boot the system directly, without going through Fedora bootloader. If this is not available for you, you can try to select the OS you want to boot in the Fedora bootloader, hit e to edit the boot menu, and replace linux and initrd keywords with linuxefi and initrdefi, then press Ctrl+x or F10 to boot it.