|
|
| Line 72: |
Line 72: |
|
| |
|
| == Upgrade issues == | | == Upgrade issues == |
| {{Anchor|fedup-fail-alpha}}
| |
| === [[FedUp]] to Fedora 21 fails at "A start job is running for udev Kernel Device Manager" ===
| |
| <small>[[#fedup-fail-alpha|link to this item]] - [[rhbug:1099299|Bugzilla: #1099299]]</small>
| |
|
| |
| Multiple testers have reported that using the [[FedUp]] tool to upgrade a system to Fedora 21 Alpha fails after the updated packages have been downloaded and the user has rebooted the system to start the upgrade. When booting into the upgrade environment, boot stops with the message "A start job is running for udev Kernel Device Manager". It times out after 90 seconds, but immediately tries again - it will constantly keep retrying, and never succeed, timing out after 90 seconds each time.
| |
|
| |
| One tester suggests switching to a console and running these commands as a workaround:
| |
|
| |
| systemctl stop systemd-udevd systemd-udevd-control.socket systemd-udevd-kernel.socket
| |
|
| |
| However, the consequences of disabling those units during the upgrade may be unpredictable, so we cannot entirely recommend this.
| |
|
| |
| If you encounter the bug, no harm is done to your existing system, and if you reboot, the existing Fedora installation will boot as usual.
| |
|
| |
| Please be aware that upgrading is not a part of the Alpha release criteria or [[QA:Release_validation_test_plan|release validation testing plan]], and it is quite common for it to be broken before the Beta release. The advice not to run Fedora pre-release, particularly Alphas, on production systems should also be borne in mind. With those disclaimers, you may possibly try [[Upgrading_Fedora_using_yum|upgrading with yum]], if you are aware of the risks and have a recovery/fallback plan if this results in your installation becoming unusable.
| |
|
| |
|
| == Boot issues == | | == Boot issues == |
| {{Anchor|grub-default-menu-entry}}
| |
| === Default boot menu (grub) entry is not updated with new kernels ===
| |
| <small>[[#grub-default-menu-entry|link to this item]] - [[rhbug:1141414|Bugzilla: #1141414]]</small>
| |
|
| |
| Fedora 21 Alpha installations currently configure the boot loader (grub) so that after installing a new {{package|kernel}} package, the default choice is not changed to the new kernel. The kernel installed with the system will still be selected by default during next boot, not the new kernel. To fix this issue, you can edit the file {{filename|/etc/sysconfig/kernel}} and change the line:
| |
|
| |
| DEFAULTKERNEL=kernel-core
| |
|
| |
| to read:
| |
|
| |
| DEFAULTKERNEL=kernel
| |
|
| |
| and subsequent new kernel packages should become the default when installed. To make a kernel you have already installed the default, you could use the {{command|grub2-set-default}} command, e.g. {{command|grub2-set-default 0}} to make the first kernel in the list at present the default. For more information about this issue, please read the Bugzilla comments.
| |
|
| |
| {{Anchor|haswell-microcode}}
| |
| === Boot fails or applications crash on systems with recent Intel processors (Haswell) particularly with encrypted storage ===
| |
| <small>[[#haswell-microcode|link to this item]] - [[rhbug:1146967|Bugzilla: #1146967]]</small>
| |
|
| |
| A processor feature called "TSX" (hardware transactional memory, Transactional Synchronization Extensions) was discovered to be faulty in recent Intel processors - so called 'Haswell' parts. This is known by Intel as errata "HSW136".
| |
|
| |
| As a result, Intel issued an update to the "microcode" of affected processors which disables the feature. Fedora duly shipped this update in its {{package|microcode_ctl}} package, which applies microcode updates at boot time. This is Fedora update [https://admin.fedoraproject.org/updates/FEDORA-2014-11178/microcode_ctl-2.1-8.fc21 FEDORA-2014-11178], package version microcode_ctl-2.1-8.fc21. The update has since been withdrawn and never reached [[Repositories#stable|''stable'' state]], but it would have been installed for users running updates with [[Repositories#updates-testing|''updates-testing'']] enabled (the default for pre-releases) between 2014-09-24 and 2014-09-26.
| |
|
| |
| Unfortunately, it turns out that some features of Fedora - at least including encrypted storage - both take advantage of the "TSX" feature, and are activated in the boot sequence before the microcode_ctl service. This means that on boot of an affected system with encrypted storage, Fedora notes that TSX support is available and uses it for access to the encrypted storage volumes, only for the microcode_ctl service to subsequently disable the processor feature, which has the effect of preventing access to the encrypted storage.
| |
|
| |
| There may also be other avenues for this issue to manifest itself. In general, it will result in processes failing with SIGILL (illegal instruction).
| |
|
| |
| There is no complete fix or simple workaround for this issue yet available other than not applying the microcode_ctl update if you have not already done so (and taking your chances with the fault in the TSX feature). If you have already installed the microcode_ctl update and encountered this issue, you may be able to boot with an older kernel and at least reach an emergency shell, where you may create a file {{filename|/etc/modprobe.conf.d/no_microcode.conf}} with the contents:
| |
|
| |
| blacklist microcode
| |
|
| |
| and then re-generate the initramfs files for all installed kernels (using {{command|dracut -f}}). This will prevent microcode_ctl from activating on boot. Again, the effect of this will be that your system will continue to use the faulty TSX feature, the results of which are beyond our control, but which at least seem to be less catastrophic than the results of microcode_ctl's attempts to disable it.
| |
|
| |
| {{Anchor|cloud-2nd-boot-failure}}
| |
| === Can't reboot cloud image ===
| |
| <small>[[#cloud-2nd-boot-failure|link to this item]] - [[rhbug:1147998|Bugzilla: #1147998]]</small>
| |
|
| |
| Fedora 21 Base Cloud images currently have an issue with growroot. In order to work around this for the time being, turn growroot off via user data:
| |
|
| |
| #cloud-config
| |
| growpart:
| |
| mode: off
| |
|
| |
| Once the image has booted, run the following command to properly write the boot record:
| |
|
| |
| dd if=/usr/share/syslinux/mbr.bin of=/dev/vda
| |
|
| |
| If you have a broken image on disk, you can use the following:
| |
|
| |
| To fix a qcow2 image on disk:
| |
|
| |
| # qemu-nbd -c /dev/nbd0 fedora-cloud-base.qcow2
| |
| # dd if=/usr/share/syslinux/mbr.bin of=/dev/nbd0
| |
| # qemu-nbd -d /dev/nbd0
| |
|
| |
| To fix a raw image on disk:
| |
|
| |
| # dd if=/usr/share/syslinux/mbr.bin of=fedora-cloud-base.img conv=notrunc
| |
|
| |
|
| == KDE issues == | | == KDE issues == |
| Line 157: |
Line 85: |
|
| |
|
| {{Anchor|kde-apper}} | | {{Anchor|kde-apper}} |
| === Graphical package manager does not work, missing PackageKit features === | | === Graphical package manager missing some PackageKit features === |
| <small>[[#kde-apper|link to this item]] - [[rhbug:1098735|Bugzilla: #1098735]]</small> | | <small>[[#kde-apper|link to this item]] - [[rhbug:1098735|Bugzilla: #1098735]]</small> |
|
| |
|
| Currently {{package|apper}} (default graphical package manager and update tool) does not work because of missing features in new PackageKit backed, old yum backed was removed from latest PackageKit. See bug report for more information on this issue.
| | In Fedora 21 Beta, {{package|apper}} (KDE's default graphical package manager and update tool) is missing some features, due to the replacement of the backend it previously used. Notably the ability to search within package groups is missing. |
| | |
| {{Anchor|kde-qt-packagekit}}
| |
| === PackageKit not included in default KDE installation ===
| |
| <small>[[#kde-qt-packagekit|link to this item]] - [[rhbug:1003122|Bugzilla: #1003122]]</small>
| |
| | |
| Due to a packaging error, default KDE installations of Fedora 21 Alpha do not include the {{package|PackageKit}} package, which is required for full functionality of KDE's graphical package tool Apper. To resolve this issue, simply install the package with e.g. {{command|su -c 'yum install PackageKit'}}, or update the system as usual after installation.
| |
|
| |
|
| == ARM issues == | | == ARM issues == |
| {{Anchor|arm-device-tree-grubby}}
| |
| === Grubby does not update or add Device tree entry in extlinux.conf on ARM ===
| |
| <small>[[#arm-device-tree-grubby|link to this item]] - [[rhbug:1088933|Bugzilla: #1088933]]</small>
| |
|
| |
| Support for [http://www.devicetree.org Device Tree] in {{package|grubby}} has not yet been added. For Fedora 21 Alpha disk image users will need to manually update the {{filename|/boot/extlinux/extlinux.conf}} with the correct kernel version after a new kernel has been installed. By default it will use the kernel version included in the Alpha release, once that kernel is removed the system will no longer boot. Anaconda installations will lack the 'fdtdir' entry and it will need to be manually added or the system will not boot. Recommended work around for Anaconda installations is with the use of a kickstart where the 'fdtdir' can be added in post.
| |
|
| |
|
| == Fedora Server Issues == | | == Fedora Server Issues == |
| Line 183: |
Line 100: |
|
| |
|
| # /usr/sbin/rngd -r /dev/urandom | | # /usr/sbin/rngd -r /dev/urandom |
|
| |
| {{Anchor|systemd-initscripts}}
| |
| === RPM conflict when installing Cockpit ===
| |
| <small>[[#systemd-inittab|link to this item]] - [[rhbug:1152183|Bugzilla: #1152183]]</small>
| |
|
| |
| When attempting to install Cockpit, yum complains about who owns /etc/inittab . You're likely to run into this issue if you're installing to a TC3 product other than [[Server]] (like a [[cloud]] instance). The workaround is to update the instance before attempting to install cockpit:
| |
|
| |
| # sudo yum upgrade
| |
| # sudo yum install cockpit
| |
|
| |
| This issue should be fixed with the next compose (TC4 or RC1).
| |
This page documents common bugs in Fedora 21 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 21 has not yet been released. During this pre-release period, this page will cover known issues in the Fedora 21 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 F21_Alpha_release_announcement for specific information about changes in Fedora 21 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
- 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)
Installation issues
Network install image offers all package groups
link to this item - Bugzilla: #1134524
This is no longer considered a bug, exactly, but remains documented here for clarity. Initial Fedora 21 plans envisaged Server and Workstation releases each having their own network install images which, by default, would offer only the package groups relevant to that Product. However, it became clear that this design was difficult to implement and not really particularly desired by anyone.
For Fedora 21 Beta and Final, there will be a single designated network install image, built from the Server tree, which defaults to the Fedora Server package set but allows installation of all package groups. In practical terms it is little different from the network install image shipped with Fedora 20 and earlier except that it defaults to the Server package group rather than the GNOME desktop (it may also have some degree of Server visual branding).
The details of exactly how this image will be described and promoted are undetermined as of yet (Beta release time), but in practice it is a universal network install image allowing deployment of all Fedora package sets. It can be used for doing network installs of the Workstation product in cases where this is preferable to installing from the live image (e.g. mass deployments).
link to this item - Bugzilla: #986731
If you have an existing UEFI-native operating system and do a UEFI-native install of Fedora alongside it, attempting to boot the previously existing OS from Fedora's bootloader may fail consistently. The reason for this failure is that os-prober currently fails to set the correct boot options for the previously existing OS in the GRUB menu.
You may be able to use your system firmware's interface to the UEFI boot manager to boot the previously existing OS directly. This boot menu is often accessible at reboot time by interrupting the boot process and choosing to boot from a different device, but implementations vary between firmwares. The Windows boot option is often named Windows Boot Manager.
Alternatively, you can use the efibootmgr command from Fedora to direct the system to boot a particular UEFI boot manager entry on the next reboot. efibootmgr should list all the UEFI boot manager entries. Identify the one for Windows, and run su -c 'efibootmgr -n XXXX', where XXXX is the (hexadecimal) number that follows the word Boot in the efibootmgr output for that entry. For instance, if efibootmgr showed:
[user@host ~]# efibootmgr
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0002
Boot0000* Fedora
Boot0002* Windows Boot Manager
then you could run su -c 'efibootmgr -n 0002' to instruct the system to boot Windows on the next startup.
You may also be able to manually edit the Fedora bootloader (GRUB) configuration to supply the parameters required to boot the previously existing OS from the Fedora boot menu.
Upgrade issues
Boot issues
KDE issues
Display sometimes does not update in KDE
link to this item - Bugzilla: #1142862
Some testers have reported an issue where the KDE desktop appears to freeze. However, it is only the display that is frozen; mouse clicks, keypresses and so on will take effect, and the display may unfreeze some time later. This issue has most often been seen during Fedora installation from the KDE live image, but some testers have reported seeing it in normal KDE use as well.
No reliable workaround is yet known for this bug besides working blind or waiting for the issue to resolve itself, although it may help to disable desktop effects with Alt+Shift+F12.
Graphical package manager missing some PackageKit features
link to this item - Bugzilla: #1098735
In Fedora 21 Beta, 
apper
ARM issues
Fedora Server Issues
Rolekit fails to deploy a Domain Controller on a VM, returning error 256
Creation of a Domain Controller role requires the system to have a sufficient amount of entropy available to securely create the keys for the included certificate authority and Kerberos key distribution center. It is very common when deploying on a virtual machine that has just been created that there will not be sufficient entropy available, which will result in the Domain Controller deployment timing out waiting on /dev/random and then failing with error code 256.
On VM hosts that support it (such as KVM on Fedora 20 and 21), it is recommended to create the VM using the virt-RNG device (which the Fedora Server 21 guest will automatically detect). This will allow it to collect entropy from the host machine and should reduce the likelihood of encountering this issue. As a workaround (if you do not have a host capable of providing entropy), you can also run the following command to make the system use the less-secure /dev/urandom entropy device:
# /usr/sbin/rngd -r /dev/urandom
apper