From Fedora Project Wiki

(DNF might pull many i686 packages for no apparent reason|1325471)
Line 53: Line 53:
 
{{Common bugs issue|some-raid-fail|Fedora fails to install on some RAID setups|1333131|1259953}}
 
{{Common bugs issue|some-raid-fail|Fedora fails to install on some RAID setups|1333131|1259953}}
  
On some setups, installing Fedora over existing firmware or software RAID can cause anaconda to crash. The crash itself messes the disks a little and renders the RAID unusable. User can restart and try again (this time using free space) as workaround.
+
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.
  
  

Revision as of 07:31, 11 May 2016

This page documents common bugs in Fedora 24 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 24 has not yet been released. During this pre-release period, this page will cover known issues in the Fedora 24 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).

Contents

Release Notes

Read the F24_Alpha_release_announcement for specific information about changes in Fedora 24 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

32-bit Intel images do not boot

link to this item - Bugzilla: #1302071

For Fedora 24, the 32-bit Intel architecture (i686 / x86_32) is no longer considered 'release blocking'. As it happens, this is very visible with Fedora 24 Alpha, as it seems to be the case that all 32-bit Intel images are unusable. A kernel and/or kernel build environment issue seems to result in any attempt to boot a 32-bit Intel kernel failing with the error Failed to allocate space for phdrs.

There is no known workaround for this issue. Although support for 32-bit Intel is now no longer guaranteed, there are several people working to fix this issue, and we do hope to provide usable 32-bit Intel Fedora 24 images for Beta and Final. This issue will be updated as soon as usable images are available.

Installer crashes on wireless network discovery

link to this item - Bugzilla: #1262556

Several testers have reported that the Fedora 24 Alpha installer may crash on wireless network discovery. This crash may occur when entering the NETWORK & HOST NAME spoke on a system with a wifi adapter and no wired network connection, or may even occur as soon as you reach the hub screen.

If you are affected by this issue, the known workaround is to connect to a wired network during installation. Installing from a live image or the Server DVD image rather than a network install image may also help.

Installed system fails to boot on some hardware

link to this item - Bugzilla: #1318067

Pre-release Alpha testing has shown that on some hardware, a Fedora 24 Alpha installation will not boot successfully. The boot process hangs at a flashing cursor before the boot menu is displayed. So far, hardware reported to be affected includes Lenovo Thinkpad T450s, Lenovo Thinkpad T400, Lenovo Thinkpad X200, Dell T1500, and Dell T1600. We are still in the process of investigating this issue. So far the only known workaround is to replace the bootloader with an older version. One way to do this is to boot from a Fedora 23 rescue image, allow it to mount the Fedora 24 system (default is /mnt/sysimage) and run grub2-install --boot-directory=/mnt/sysimage/boot/ /dev/sda (if the system is installed to another disk, adjust the /dev/sda portion of the command).

Live images have no rescue kernel

link to this item - Bugzilla: #1317709

Due to a change in the image compose process, Fedora 24 Alpha live media contain no 'rescue' kernel. This means a system installed from a Fedora 24 Alpha live image will also have no 'rescue' kernel available for boot. The 'rescue' kernel's purpose is to provide a known-good fallback boot entry which also has a generic initramfs, rather than one tailored to the installed system's hardware (so if you change the system's hardware so much that the regular kernel no longer boots, the rescue kernel still should). If you would like to add a rescue kernel to a Fedora 24 Alpha system after installation from a live image, try this:

sudo dnf install dracut-config-rescue
sudo /etc/kernel/postinst.d/51-dracut-rescue-postinst.sh $(uname -r) /boot/vmlinuz-$(uname -r)
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

For UEFI, the final command should be sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg. Thanks to Andre Robatino for working out this procedure.

Initial setup utility displays in a small corner of the screen

link to this item - Bugzilla: #1160891

Fedora has a initial-setup tool which is run on first system boot in some cases. It does not run on minimal installations or GNOME (Workstation) installations (GNOME has its own separate tool called gnome-initial-setup), but does run on installs of most other desktops.

If you encounter this tool in graphical mode in Fedora 24 Alpha, you may notice it appears strangely - it initially appears very small and occupies only a corner of the screen, and the main interactions (setting a root password and creating a user account) are not immediately visible. You can find them by scrolling the window down. When you enter any spoke, the utility will become somewhat bigger, though still will not occupy the full screen.

This bug is purely cosmetic and the tool will work correctly as long as you manage to navigate it. We are working to resolve this issue for Fedora 24 Beta and Final.

Fedora Media Writer shows no writing progress on Fedora 22

link to this item - Bugzilla: #1328462

If you use Fedora Media Writer (formerly liveusb-creator) on Fedora 22 to create a new bootable USB drive, no progress is displayed during the writing process. You need to wait until the dialog says "Finished".

Fedora fails to install on some RAID setups

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

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.


Dual-booting other OS's via GRUB2 chainloading on UEFI systems fails with an "out of memory" error

link to this item - Bugzilla: #1320273

On UEFI systems, dual-booting other OS's via chainloading in GRUB2 fails with an "out of memory" error. The GRUB2 maintainers are aware of this issue and are working to resolve it. For now you can boot other OS's using the Boot Manager offered by the firmware on your machine. Alternatively you can try this workaround RHBZ1320273#c23


Upgrade issues

DNF 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 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 that 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 24.

This is now fixed in Fedora 24 (since libhif-0.2.2-3.fc24) and Fedora 23 (since libhif-0.2.2-3.fc23, currently in updates-testing). Future 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 start using DNF:

  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 update libhif --enablerepo=updates-testing
    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.

GNOME issues

GNOME Settings Daemon crash on startup

link to this item - Bugzilla: #1288850

On some systems, the GNOME configuration manager, gnome-settings-daemon, crashes during system startup. This may prevent expected settings from being applied to the session (this can manifest in many ways, like fonts not appearing as expected). A crash notification will usually appear. If you are affected by this, you should be able to launch the daemon manually from a console with /usr/libexec/gnome-settings-daemon &. This issue is likely resolved in GNOME 3.20, which arrived too late for inclusion in Fedora 24 Alpha, and so should be addressed after install and update of the Alpha, and in the Beta release.

Crash on shutdown or restart

link to this item - Bugzilla: #1316311

Several Fedora 24 Alpha testers have reported a GNOME crash on session end (usually shutdown or restart). This crash may be somewhat hardware-specific. The issue is resolved in an upstream release that arrived too late for inclusion in Fedora 24 Alpha, so the crash should no longer occur on installed systems after an update. The crash does not have any known serious consequences and can be ignored.

Webkit crash when entering online account credentials or browsing GNOME Shell extensions

link to this item - Bugzilla: #1314658

Several Fedora 24 Alpha testers have reported crashes in the Webkit HTML rendering engine while using various GNOME desktop features that use it. Specific cases known to be affected include configuring online accounts (one reporter suggests a crash occurs when enabling caps lock while entering Facebook account credentials) and browsing GNOME Shell extensions.

At least some of the bugs have been resolved upstream, but the fixes have not yet worked their way downstream into Fedora yet.

Network Manager IPv4 and IPv6 dialogs incorrectly displayed, unusable with mouse

link to this item - Bugzilla: #1326047

The network properties dialog of network manager in Gnome display has issue with controls on IPv4 and IPv6 configuration screens. The controls are not placed properly and the dialog is not sized correctly. It is not possible to click on the buttons with mouse, although it works with TAB key on keyboard. The problem occurs for all types of connections.

This bug is fixed in gtk3-3.20.3, just update the package by running command dnf update gtk3.


Plasma (KDE) issues

Fedora 24 background not used in Plasma

link to this item - Bugzilla: #1320666

The intended Fedora 24 background is not used in the Fedora 24 Alpha Plasma spin. Instead an upstream default background is used. The Fedora KDE / Plasma team is aware of this issue and working to resolve it with an update and for Fedora 24 Beta.

Network issues

No network connection in VM when both host and guest installed from a Live image

link to this item - Bugzilla: #1146232 - Bugzilla: #1146284

If you install Fedora from a Live image, and then create a virtual machine on it and install another Fedora from a Live image as a guest, your networking in guest will probably not work. The is reason is that libvirt virtual network address ranges are the same both in the host and the guest and clash. This does not happen if you install the libvirt packages in guest manually at some point later (it is detected during package installation), just when you install from a LiveCD.

If you don't need libvirt to work in the VM, you can remove libvirt networking there by running sudo virsh net-destroy default && sudo virsh net-undefine default, and then renewing the network connection in NetworkManager. If you need libvirt to work in VM, you need to edit its configuration files and assign a different IP range to it.

Hardware issues

Application issues

DNF might pull many i686 packages for no apparent reason

link to this item - Bugzilla: #1325471

There seems to be a bug in DNF which pulls many (unneeded) i686 package dependencies when installing certain x86_64 packages which use the Supplements RPM tag. An investigation is still ongoing. If you see such transaction and you believe those dependencies should not be pulled, please report it to us. You might be able to work around this bug by adding --exclude='*.i686' parameter to DNF command line.

Firefox no longer plays H264 content using gstreamer, uses ffmpeg now

link to this item - Bugzilla: #1331496

Since Firefox 46, it no longer uses gstreamer to play non-free multimedia content (most often represented by H264 video codec), but uses ffmpeg instead. Instead of having gstreamer1-libav, now you need to have ffmpeg-libs installed if you want to be able to play such content in Firefox. Please note that ffmpeg is not distributed by Fedora and you need to obtain it yourself, if you wish to use it.

Docker fails to run anything

link to this item - Bugzilla: #1322909

There has been reporten an issue with docker-1.10.3-3, which results in unusable docker. This issue persists even if docker is updated. Sufficient workaround should be to stop docker, remove directory /var/lib/docker and install newer docker. Users with lvm thin pool must recreate the pool since the removal of /var/lib/docker breaks it. For more, see RHBZ1322909#c21.

ARM issues

bananapi: unable to pxe boot

link to this item - Bugzilla: #1329613

Some people are experiencing a problem with graphical PXE installation on Banana Pi. They are probably running into memory issues when 1G of RAM is not enough. The workaround is to append inst.text to kernel cmdline and proceed with text installation or install the system via VNC.

Fedora Server issues

FreeIPA/Active Directory enrollment fails the first time

link to this item - Bugzilla: #1330766

If you try to enroll as a client of FreeIPA/Active Directory using the realm command or Cockpi, it might fail the first time, especially when some additional packages need to be installed. It should work when you try the same action the second time. A bug investigation is still ongoing.

Fedora Cloud issues

LXDE issues

Default LXDE browser (Midori) is broken

link to this item - Bugzilla: #1319516 - Bugzilla: #1306144

The default browser on the Fedora 24 Alpha LXDE spin, Midori, does not launch (it will crash) when run normally. It can be launched from a console with midori --plain. You may also choose to install Firefox or another browser into the live environment, with sudo dnf install firefox; this will use some extra RAM.

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 in /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 and add this to the GRUB_CMDLINE_LINUX entry in /etc/default/grub then regenerate the grub.cfg file used:

Via grub2-mkconfig:
  For BIOS systems:
  grub2-mkconfig -o /boot/grub/grub.cfg

  For EFI systems:
  grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

Via grubby:
  grubby --args=resume=/path/to/swap --update-kernel=$(grubby --default-kernel)


Error and timeout on command rpm-ostree status

link to this item - Bugzilla: #1330318

Several testers have reported that command rpm-ostree status fails after 30 seconds hang. Updating to selinux-policy-3.13.1-185 fixes this issue.