(document default console font vs. arabic/cyrillic/hebrew issue (#1209460)) |
m (add category) |
||
(73 intermediate revisions by 14 users not shown) | |||
Line 1: | Line 1: | ||
<!-- | <!-- | ||
This header (down to the first "Issues" section below) is generated by '''SUBSTITUTING''' [[Template: | This header (down to the first "Issues" section below) is generated by '''SUBSTITUTING''' [[Template:Common_bugs_header_stable_release]] at the time the release goes stable: <nowiki>{{subst:Common_bugs_header_stable_release}}</nowiki>. This should replace the entire pre-release header text. Please do this rather than copy/pasting. If you are making improvements to the header text, please make them also in the [[Template:Common_bugs_header_stable_release]], [[Template:Common_bugs_header_prerelease]] and [[Template:Common_bugs_header_shared]] templates as appropriate, so future pages will contain the same improvements. | ||
--> | --> | ||
{{autolang|base=yes}} | {{autolang|base=yes}} | ||
This page documents common bugs in Fedora 22 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. | This page documents common bugs in Fedora 22 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. | ||
== Release Notes == | == Release Notes == | ||
Read the [[ | Read the [[F22_release_announcement|Fedora 22 release announcement]] and the [http://docs.fedoraproject.org/en-US/Fedora/22/html/Release_Notes/ Fedora 22 release notes] for specific information about changes in Fedora 22 and other general information. | ||
{{Common_bugs_header_shared}} | {{Common_bugs_header_shared}} | ||
== Installation issues == | == Installation issues == | ||
{{Common bugs issue|anaconda- | {{Common bugs issue|anaconda-not-on-desktop-kde|The installer icon is not shown on the desktop in KDE|1220862}} | ||
Unlike in previous Fedora releases, the installer launcher is no longer displayed on the desktop in KDE. You need to open the system menu to run the installer. | |||
{{Common bugs update released|FEDORA-2015-8453|noupdate}} | |||
{{Common bugs issue|anaconda-redraw-progress|Installer might not redraw its progress bar in KDE|1210042}} | |||
In certain environments (seen in KDE, might affect some others as well), sometimes the installer does not redraw its progress bar properly and seems stuck, even though the installation is making progress sucessfuly. This seems to be an issue with the widget toolkit or the display manager. | |||
If the progress bar seems stuck for a long time and there's no progress indicated elsewhere, you can try to open and close the root password dialog, visible from the installation overview screen. You can also try to Alt+Tab between the installer and some other windows, to force it to redraw. | |||
This bug will be | {{Common bugs issue|anaconda-minimal-partition-size-netinst|Installer does not correctly compute the minimal required partition size when using network installation|1224048}} | ||
If you use the network install image (netinst), the installer will not always correctly warn you when your root partition is too small to contain the installed system. If the disk space runs out during package installation, anaconda reboots the machine without a warning, and the partial Fedora installation is broken and unusable. If this happens, please repeat the installation, but assign more space to the root partiton. For example, the ''absolute minimum'' for a Workstation package set is 6 GiB. | |||
In the vast majority of cases, this issue does not affect Live or DVD (offline) installations. There is a very slight chance that if you set the partition to be almost exactly the same size as is the installed package set, the filesystem metadata will occupy enough space so that the installed system does not fit into the free space. | |||
To be safe from this issue, please don't try to set an extremely small root partition. | |||
{{Common bugs issue|two-fedoras-dualboot|GRUB boot loader doesn't list other Fedora installations when they are present on a separate harddisk|1223537}} | |||
If there are other Fedora systems installed on a different disk than was the destination of current installation, they won't be listed in GRUB during startup. You can use BIOS to boot from a particular disk to work around this. | |||
{{Common bugs issue|liveinst-on-kde-fails|Liveinst run from terminal emulator on Plasma fails to start|1222262}} <!--#SCRIPTIGNORE# this comment marks issue to be ignored by scripts --> | |||
Liveinst run from command line fails to start because LANGUAGE variable is empty. To run liveinst kickstart or --lang parameter must be provided. Installation can be also run by using graphical icon from menu. | |||
{{Common bugs issue|anaconda-hard-to-remove-snapshotted-partitions|Installer does not allow convenient removal of volumes including snapshots (btrfs, LVM) in manual partitioning|1185117}} | |||
If you enter manual partitioning in the installer (a dialog where you're able to create your own partition layout, as opposed to a automatic partitioning dialog where you can only remove partitions), and you have some existing partitions which include a large number of snapshots (usually related to btrfs or LVM), the installer displays every single such snapshot as a separate system tree. In certain cases, it might be very difficult and tiring to remove some of those partitions including snapshots and keep others intact, because it would involve clicking and manually removing each of those partitions. The installer is not currently able to let you conveniently work with snapshotted volumes, or disks with ten or hundreds of partitions. | |||
If you do not need to create your own partition layout and you don't need to preserve certain logical volumes/btrfs subvolumes, you can use the automatic partitioning dialog to delete unneeded partitions easily. In other cases, please use external tools to configure your disk layout to your needs first, and run Fedora installer after that. | |||
{{Common bugs issue|decryption-with-cyrillic-and-arabic-passphrases|Filesystem encrypted with cyrillic or arabic language passphrase can not be decrypted at boot time|681250}} <!--#SCRIPTIGNORE# this comment marks issue to be ignored by scripts --> | |||
Filesystem encrypted with cyrillic or arabic languages passphrase can not be decrypted at boot time. English (USA) keyboard layout (by default it is set as secondary layout for installation) is used for decryption, if you need to encrypt your system please use this layout for passphrase. | |||
{{Common bugs issue|btrfs-raid1-boot-fails|System installed on btrfs raid1 installed from live image fails to boot|1214441}} | |||
If the system is installed on btrfs raid1 it won't be bootable. This problem occurs just when live media is used for installation. If you need btrfs raid1 use another media for example netinst. | |||
{{Common bugs issue|firmware-raid-problems-with-leftovers|Problems with firmware RAID|1219264|1224045}} | |||
There are some bugs caused by firmware RAID. They are caused by the way how firmware RAID creates the RAID sets and by some remnants on used discs. This may cause RAID to not appear in '''INSTALLATION DESTINATION''' or anaconda to crash during installation. If you encounter any problems, try to format all used disks and recreate RAID. Sometimes it is enough to use different installation media (in case of RAID not appearing in Installation destination ({{bz|1219264}}) it should work with netinst or DVD). | |||
{{Common bugs issue|mdraid-devices-not-recognized|Software RAID (mdraid) from existing Fedora installations not recognized by live installs|1225671|1225184}} | |||
Installations from live images do not recognize software RAID (mdraid) devices from existing (e.g. previous) Fedora installations. Neither these devices nor the underlying disk partitions are offered in the device selection dialog which makes it basically impossible to install Fedora 22 or to keep existing data. | |||
However, non-live installer images correctly detect those devices. You can use the Server or Workstation network install image to install to affected systems. From the network install image, you can choose any package set you like (not just Server or Workstation). | |||
{{Common bugs issue|encrypted-lv-reformat|Failure when reformatting an encrypted LV|1212907}} | |||
When trying to reformat an encrypted LV (i.e. an LV having LUKS+filesystem on top of it) in the installation process, the installer fails with a traceback. A workaround is to remove such LV before even unlocking it with the LUKS passphrase and create it again (**which deletes data on the LV just like the reformat**) as encrypted. | |||
{{Common bugs issue|kickstart-deselect|De-selecting packages and groups via kickstart does not work|1234545}} <!--#SCRIPTIGNORE# this comment marks issue to be ignored by scripts --> | |||
Due to a bug in the installer, de-selecting packages and groups in a [[Anaconda/Kickstart|kickstart]] file does not work in Fedora 22. The kickstart will be read and the install will not fail, but the de-selections will not take effect. For instance, if you create a kickstart with a {{code|%packages}} section like this: | |||
%packages | |||
@^workstation-product-environment | |||
-gedit | |||
%end | |||
The install will succeed, but {{package|gedit}} will be installed despite the attempt to exclude it. | |||
There is no workaround for this problem besides avoiding the use of groups in your kickstart and listing only the precise set of packages you want to install. An [[Anaconda/Updates|updates image]] may be provided to fix it. | |||
== Upgrade issues == | == Upgrade issues == | ||
{{Common bugs issue|fedup-F20-to-F22-needs-new-fedora-release|Upgrade from Fedora 20 complains about missing GPG keys with an outdated fedora-release|1220358}} <!--#SCRIPTIGNORE# this comment marks issue to be ignored by scripts --> | |||
If you want to upgrade Fedora 20 to Fedora 22 using <code>fedup</code>, you need to update <code>fedora-release</code> package to version <code>fedora-release-20-4</code> first. Otherwise you'll encounter an error about missing GPG keys. | |||
Please note that you should ''always'' fully update your system before starting a distribution upgrade. | |||
{{Common bugs issue|fedup-hang-old-systemd|Upgrade from Fedora 21 hangs at boot with an outdated systemd|1223735}} | |||
If you want to upgrade Fedora 21 to Fedora 22 using <code>fedup</code>, you need to update <code>systemd</code> package to version <code>systemd-216-24.fc21</code> first. Otherwise the upgrade process will hang and not start. There is no data loss, just reboot, update systemd, and start <code>fedup</code> again. | |||
Please note that you should ''always'' fully update your system before starting a distribution upgrade. | |||
{{Common bugs issue|nautilus-segfault-old-config|Nautilus segfaults after upgrading from Fedora 20 or 21}} | |||
It is advised that you do not skip releases when upgrading, but instead, fully update your system and then upgrade to the very next release. To resolve Nautilus segfaults, ''''# rm -rf ~/.config/nautilus''''. If you notice this issue after upgrading as suggested, please file a bug: https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora | |||
== Core software issues == | |||
{{Common bugs issue|dnf-resize-crash|dnf crashes during install if terminal resized too small|1256531}} | |||
The version of the [[Dnf]] tool included in Fedora 22 contains a bug which may cause it to crash during some operations if it is running in a terminal window and that window is resized to a smaller size. This is a fairly unusual case, but as it can cause dnf to crash during a package operation, it can cause severe consequences (the system being left in an inconsistent state). This bug will be fixed as soon as possible, but until then we strongly recommend you ensure any terminal windows in which you run dnf are of a reasonable size (80x24 characters is known to be safe) and do not resize them while it is running. | |||
{{Common bugs update testing|FEDORA-2015-16429}} | |||
{{Common bugs issue|systemd-shutdown-kill|All user session processes killed on system shutdown|1170765}} | |||
systemd, as included in Fedora 22, contains an issue with scope management (which includes user sessions). On system shutdown (or reboot), processes running in scopes are killed (with SIGKILL) almost immediately. The practical effect of this is that if you shut down the system directly from a user session (e.g. a logged-in desktop), rather than logging out first, applications running within that session will be killed, rather than shutting down cleanly. | |||
The effects of this depend heavily on the application. Some known effects are: | |||
* Firefox will often display its recovery screen the next time you run it. | |||
* If any bash shells were running in the session, their history may not be properly appended (so you will not find commands run in that shell in the {{command|history}} output on subsequent boots), and if a particularly unfortunate timing is encountered, the bash history may be entirely destroyed. | |||
Other applications may display other effects; basically, applications cannot be relied upon to quit in an orderly fashion, so anything they would normally do when called upon to quit may not happen correctly. | |||
Logging out of the user session before shutting down the system should avoid this issue. | |||
This issue is being worked on as a high priority and a fix should be available soon. | |||
== GNOME issues == | == GNOME issues == | ||
{{Common bugs issue|gnome-inital-setup-hang-nomodeset|System hang when creating a user during GNOME first boot in basic graphics mode|1206404}} <!--#SCRIPTIGNORE# this comment marks issue to be ignored by scripts --> | |||
== KDE issues == | If you run the installer in "basic graphics" mode and do not create a user during the installation, you'll be offered to create the user the first time GNOME starts in the installed system. However, due to an issue with the basic graphics mode, the system will show you just an empty screen after the user is created, instead of logging you in or showing you the login screen. You'll need to reboot your computer, and then you'll be able to log in with your created user. | ||
{{Common bugs issue|hp-plugin-blank-window|hp-plugin shows a blank gray window|1219284}} | |||
In Fedora 22 the X.org server no longer runs under root. Due to this change hp-plugin shows a blank gray window. To workaround this run <code>hp-plugin -i</code> to get text mode. Another workaround is to run <code>QT_X11_NO_MITSHM=1 hp-plugin</code>. | |||
== Plasma (KDE) issues == | |||
{{Common bugs issue|text-initial-setup|Initial setup sometimes starts in text mode instead of in graphics mode|1185447}} | |||
Sometimes happens that initial setup starts in text mode instead of graphical mode. In that case you can proceed with text mode or disable initial-setup-text.service by running command {{command|systemctl disable initial-setup-text.service}} as root and restart. The graphical initial setup should be provided then. | |||
{{Common bugs issue|third-party-rpms-bundle-qt5|Some third-party application rpms bundle Qt5 erroneously (hipchat, viber)|1225749}} <!--#SCRIPTIGNORE# this comment marks issue to be ignored by scripts --> | |||
Some third-party application rpms bundle Qt5 libraries incorrectly, which can cause runtime failures for other applications that depend on them. Problematic vendor rpms identified include hipchat and viber. Each vendor has been notified of the problem. If you have problems (especially for during fedora upgrades), it is recommended you uninstall these problematic rpms prior to upgrading. | |||
== Network issues == | == Network issues == | ||
{{Common bugs issue|wired-not-enabled-on-boot|Wired network is not connected automatically on boot if installed without network cable during installation|963952}} <!--#SCRIPTIGNORE# this comment marks issue to be ignored by scripts --> | |||
If you install Fedora 22 without an ethernet cable connected during installation, the network card will be configured to be disabled by default. It means that your installed system will not automatically connect to a wired network after you plug your cable in. You'll need to enable the wired connection manually every time (in GNOME, that can be done using the system menu in upper right screen corner). | |||
In order to configure your wired connection to activate automatically, open your network preferences (in GNOME, that's in system menu -> Settings icon -> Network), go to Wired connection preferences -> Identity tab -> enable ''Connect automatically'' checkbox. Alternatively, you can edit <code>/etc/sysconfig/network-scripts/ifcfg-<interface_name></code> from console and replace <code>ONBOOT=no</code> with <code>ONBOOT=yes</code>. | |||
{{Common bugs issue|libvirt-no-network-in-guest-from-Live|No network connection in VM when both host and guest installed from a Live image|1146232}} | |||
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 <code>sudo virsh net-destroy default && sudo virsh net-undefine default</code>, 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 == | == Hardware issues == | ||
{{Common bugs issue|screen-corruption-intel|Massive screen corruption on older Intel graphics cards|1226531}} | |||
After upgrading to {{pkg|xorg-x11-drv-intel}} 2.99.917-9, certain older Intel chipsets display heavy screen corruption during common production tasks, like using the file explorer, browsing the web, working in terminal, etc. Both images and text are often distorted. | |||
The fix is being worked on. As a temporary workaround, you can either downgrade to <code>xorg-x11-drv-intel-2.99.917-6.20150211.fc22</code>: | |||
<pre> | |||
$ sudo dnf downgrade xorg-x11-drv-intel-2.99.917-6.20150211.fc22 | |||
</pre> | |||
and make sure you don't update that package, or you can create <code>/etc/X11/xorg.conf.d/20-intel.conf</code> and put this inside: | |||
<pre> | |||
# A workaround for https://bugzilla.redhat.com/show_bug.cgi?id=1226531 | |||
Section "Device" | |||
Identifier "card0" | |||
Driver "intel" | |||
Option "AccelMethod" "uxa" | |||
EndSection | |||
</pre> | |||
Please note that this can have other issues (like slower rendering) and that you should subscribe to the linked bug to be notified when this issue is resolved and remove this temporary workaround. | |||
{{Common bugs issue|wayland-gdm-dual-gpu-macbook|GNOME login screen doesn't appear on certain dual-GPU Macbooks after installation|1218787}} | |||
On certain Macbook laptops with dual graphics cards, Fedora 22 Live environment boots fine, but after installation there's just black screen and no boot splash followed by a GNOME login screen. There seems to be an issue with Wayland, an upcoming window system, which is used in GNOME login screen. | |||
It seems that users of affected laptops should be able to work around this issue by booting in a basic graphics mode (adding <code>nomodeset</code> to the boot command line in GRUB), and then editing <code>/etc/gdm/custom.conf</code> file and uncommenting the following line: | |||
<pre> | |||
#WaylandEnable=false | |||
</pre> | |||
That will disable Wayland for GNOME login screen in future boots. | |||
== ARM issues == | == ARM issues == | ||
Line 45: | Line 194: | ||
== Fedora Cloud issues == | == Fedora Cloud issues == | ||
{{Common bugs issue|cloud-init-packages-selinux|cloud-init fails to install packages from user-data|1227484}} | |||
{{Common bugs issue| | |||
When using the "packages" directive for {{package|cloud-init}} on Fedora 22, it fails with selinux denials. There are a couple ways to work around this: | |||
* Toggle SELinux while cloud-init sets up your instance by using "setenforce 0" in the [http://cloudinit.readthedocs.org/en/latest/topics/examples.html#run-commands-on-first-boot "bootcmd" directive] (then turn it back on in a "runcmd" directive). | |||
* Manually install packages | |||
* Use another tool to set up your instance (like [https://ansible.com ansible]) | |||
{{Common bugs issue|console-font|Arabic, Cyrillic, and Hebrew characters not displayed in console|1209460}} | {{Common bugs update released|FEDORA-2015-10299|noupdate}} | ||
== Other issues == | |||
{{Common bugs issue|console-font|Arabic, Cyrillic, and Hebrew characters not displayed in console|1209460}} <!--#SCRIPTIGNORE# this comment marks issue to be ignored by scripts --> | |||
The default console font in Fedora 22 [[Changes/NewDefaultConsoleFont|has been changed]] to one ('eurlatgr') which provides greater coverage for Latin and Greek characters, but at the cost of Arabic, Cyrillic and Hebrew characters being dropped. It was intended that installations in languages which use the Arabic, Cyrillic or Hebrew characters should get a more appropriate default console font, but this has not yet been implemented. | The default console font in Fedora 22 [[Changes/NewDefaultConsoleFont|has been changed]] to one ('eurlatgr') which provides greater coverage for Latin and Greek characters, but at the cost of Arabic, Cyrillic and Hebrew characters being dropped. It was intended that installations in languages which use the Arabic, Cyrillic or Hebrew characters should get a more appropriate default console font, but this has not yet been implemented. | ||
Line 59: | Line 212: | ||
This change applies only to new installations; the font used by existing installations will not be changed on upgrade. | This change applies only to new installations; the font used by existing installations will not be changed on upgrade. | ||
{{Common bugs issue|trace-yama|Attaching gdb or strace to your own process is blocked by Yama|1209492}} <!--#SCRIPTIGNORE# this comment marks issue to be ignored by scripts --> | |||
There's now a bit more work involved if you want to attach gdb or strace to a process running under your own user. You can either do that under root, or configure <code>/proc/sys/kernel/yama/ptrace_scope</code>. For more information, refer to the linked bug report and [https://www.kernel.org/doc/Documentation/security/Yama.txt Yama documentation in Linux kernel]. | |||
{{Common bugs issue|vim|Bad colors in gvim or terminals with light background|1159920|1225652}} | |||
For the workstation spin, the default background color for vim was configured to <nowiki>dark</nowiki> in <nowiki>/etc/vimrc</nowiki>. This makes vim use ugly colors in gvim or terminals with a light background. To work-around this, use <nowiki>set background=light</nowiki> in your <nowiki>~/.vimrc</nowiki> file. | |||
== Resolved issues == | |||
{{Common bugs issue|mouse-cursor-desync-vmware|Mouse cursor get ocassionally de-synced in VMware|1214474}} | |||
{{Common bugs update released|kernel-4.0.4-303.fc22}} | |||
If you run Fedora 22 in VMware, sometimes the host mouse and the guest mouse get out of sync and "ungrabbed". VMware seems to be working on a proper solution in Linux kernel. In the mean time, you can disable automatic mouse capture by editing <code>preferences.ini</code> in your VMware configuration directory and setting these values: | |||
<pre> | |||
pref.motionUngrab = "FALSE" | |||
pref.grabOnMouseClick = "TRUE" | |||
pref.motionGrab = "FALSE" | |||
</pre> | |||
You will then have to click to get the mouse cursor grabbed, and press Ctrl+Alt to have it ungrabbed. | |||
Alternatively, you can adjust vmmouse configuration and run Xorg as root in the guest, as explained in [https://bugzilla.redhat.com/show_bug.cgi?id=1214474#c41 bug 1214474#c41]. That is not recommended from a security standpoint, however. | |||
{{Common bugs issue|packagekit-ignores-kernel-module-updates-from-rpmfusion|PackageKit (GNOME Software, GNOME offline upgrades) ignores kernel modules updates from RPMFusion (VirtualBox, Nvidia driver, NDISwrapper, etc)|1205649}} | |||
{{Common bugs update released|FEDORA-2015-9675}} | |||
If you have installed a kernel module from RPMFusion repository (the most common are VirtualBox or the proprietary Nvidia graphics driver), you will not see updates to these kernel modules in PackageKit package manager, and therefore neither in GNOME Software application. This will also make main kernel updates ignored as well. | |||
In order to install latest Linux kernel (very recommended due to occasional security issue) and the relevant modules from RPMFusion, please regularly run <code>sudo dnf update</code> from a terminal. | |||
{{Common bugs issue|luc-blank-window|Liveusb-creator displays just a blank window on Fedora 22|1212180}} | |||
{{Common bugs update released|FEDORA-2015-8972}} | |||
In Fedora 22 the X.org server no longer runs under root. Due to this change liveusb-creator run on F22 Workstation shows just a blank window. To temporarily work around this issue run this command: <code>QT_GRAPHICSSYSTEM=native liveusb-creator</code>. | |||
{{Common bugs issue|autologin-logout-fail|Logging out does not work when autologin enabled|1245953}} | |||
{{Common bugs update released|FEDORA-2015-16055}} | |||
If you enabled autologin in GNOME in Fedora 22, trying to log out would fail to work correctly; instead of returning to the login screen, you would get stuck at a black screen. | |||
[[Category:Common bugs]] |
Latest revision as of 23:58, 14 March 2018
This page documents common bugs in Fedora 22 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.
Release Notes
Read the Fedora 22 release announcement and the Fedora 22 release notes for specific information about changes in Fedora 22 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
The installer icon is not shown on the desktop in KDE
link to this item - Bugzilla: #1220862
Unlike in previous Fedora releases, the installer launcher is no longer displayed on the desktop in KDE. You need to open the system menu to run the installer.
Installer might not redraw its progress bar in KDE
link to this item - Bugzilla: #1210042
In certain environments (seen in KDE, might affect some others as well), sometimes the installer does not redraw its progress bar properly and seems stuck, even though the installation is making progress sucessfuly. This seems to be an issue with the widget toolkit or the display manager.
If the progress bar seems stuck for a long time and there's no progress indicated elsewhere, you can try to open and close the root password dialog, visible from the installation overview screen. You can also try to Alt+Tab between the installer and some other windows, to force it to redraw.
Installer does not correctly compute the minimal required partition size when using network installation
link to this item - Bugzilla: #1224048
If you use the network install image (netinst), the installer will not always correctly warn you when your root partition is too small to contain the installed system. If the disk space runs out during package installation, anaconda reboots the machine without a warning, and the partial Fedora installation is broken and unusable. If this happens, please repeat the installation, but assign more space to the root partiton. For example, the absolute minimum for a Workstation package set is 6 GiB.
In the vast majority of cases, this issue does not affect Live or DVD (offline) installations. There is a very slight chance that if you set the partition to be almost exactly the same size as is the installed package set, the filesystem metadata will occupy enough space so that the installed system does not fit into the free space.
To be safe from this issue, please don't try to set an extremely small root partition.
GRUB boot loader doesn't list other Fedora installations when they are present on a separate harddisk
link to this item - Bugzilla: #1223537
If there are other Fedora systems installed on a different disk than was the destination of current installation, they won't be listed in GRUB during startup. You can use BIOS to boot from a particular disk to work around this.
Liveinst run from terminal emulator on Plasma fails to start
link to this item - Bugzilla: #1222262
Liveinst run from command line fails to start because LANGUAGE variable is empty. To run liveinst kickstart or --lang parameter must be provided. Installation can be also run by using graphical icon from menu.
Installer does not allow convenient removal of volumes including snapshots (btrfs, LVM) in manual partitioning
link to this item - Bugzilla: #1185117
If you enter manual partitioning in the installer (a dialog where you're able to create your own partition layout, as opposed to a automatic partitioning dialog where you can only remove partitions), and you have some existing partitions which include a large number of snapshots (usually related to btrfs or LVM), the installer displays every single such snapshot as a separate system tree. In certain cases, it might be very difficult and tiring to remove some of those partitions including snapshots and keep others intact, because it would involve clicking and manually removing each of those partitions. The installer is not currently able to let you conveniently work with snapshotted volumes, or disks with ten or hundreds of partitions.
If you do not need to create your own partition layout and you don't need to preserve certain logical volumes/btrfs subvolumes, you can use the automatic partitioning dialog to delete unneeded partitions easily. In other cases, please use external tools to configure your disk layout to your needs first, and run Fedora installer after that.
Filesystem encrypted with cyrillic or arabic language passphrase can not be decrypted at boot time
link to this item - Bugzilla: #681250
Filesystem encrypted with cyrillic or arabic languages passphrase can not be decrypted at boot time. English (USA) keyboard layout (by default it is set as secondary layout for installation) is used for decryption, if you need to encrypt your system please use this layout for passphrase.
System installed on btrfs raid1 installed from live image fails to boot
link to this item - Bugzilla: #1214441
If the system is installed on btrfs raid1 it won't be bootable. This problem occurs just when live media is used for installation. If you need btrfs raid1 use another media for example netinst.
Problems with firmware RAID
link to this item - Bugzilla: #1219264 - Bugzilla: #1224045
There are some bugs caused by firmware RAID. They are caused by the way how firmware RAID creates the RAID sets and by some remnants on used discs. This may cause RAID to not appear in INSTALLATION DESTINATION or anaconda to crash during installation. If you encounter any problems, try to format all used disks and recreate RAID. Sometimes it is enough to use different installation media (in case of RAID not appearing in Installation destination (RHBZ #1219264) it should work with netinst or DVD).
Software RAID (mdraid) from existing Fedora installations not recognized by live installs
link to this item - Bugzilla: #1225671 - Bugzilla: #1225184
Installations from live images do not recognize software RAID (mdraid) devices from existing (e.g. previous) Fedora installations. Neither these devices nor the underlying disk partitions are offered in the device selection dialog which makes it basically impossible to install Fedora 22 or to keep existing data.
However, non-live installer images correctly detect those devices. You can use the Server or Workstation network install image to install to affected systems. From the network install image, you can choose any package set you like (not just Server or Workstation).
Failure when reformatting an encrypted LV
link to this item - Bugzilla: #1212907
When trying to reformat an encrypted LV (i.e. an LV having LUKS+filesystem on top of it) in the installation process, the installer fails with a traceback. A workaround is to remove such LV before even unlocking it with the LUKS passphrase and create it again (**which deletes data on the LV just like the reformat**) as encrypted.
De-selecting packages and groups via kickstart does not work
link to this item - Bugzilla: #1234545
Due to a bug in the installer, de-selecting packages and groups in a kickstart file does not work in Fedora 22. The kickstart will be read and the install will not fail, but the de-selections will not take effect. For instance, if you create a kickstart with a %packages section like this:
%packages @^workstation-product-environment -gedit %end
The install will succeed, but gedit
will be installed despite the attempt to exclude it.
There is no workaround for this problem besides avoiding the use of groups in your kickstart and listing only the precise set of packages you want to install. An updates image may be provided to fix it.
Upgrade issues
Upgrade from Fedora 20 complains about missing GPG keys with an outdated fedora-release
link to this item - Bugzilla: #1220358
If you want to upgrade Fedora 20 to Fedora 22 using fedup
, you need to update fedora-release
package to version fedora-release-20-4
first. Otherwise you'll encounter an error about missing GPG keys.
Please note that you should always fully update your system before starting a distribution upgrade.
Upgrade from Fedora 21 hangs at boot with an outdated systemd
link to this item - Bugzilla: #1223735
If you want to upgrade Fedora 21 to Fedora 22 using fedup
, you need to update systemd
package to version systemd-216-24.fc21
first. Otherwise the upgrade process will hang and not start. There is no data loss, just reboot, update systemd, and start fedup
again.
Please note that you should always fully update your system before starting a distribution upgrade.
Nautilus segfaults after upgrading from Fedora 20 or 21
It is advised that you do not skip releases when upgrading, but instead, fully update your system and then upgrade to the very next release. To resolve Nautilus segfaults, '# rm -rf ~/.config/nautilus'. If you notice this issue after upgrading as suggested, please file a bug: https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora
Core software issues
dnf crashes during install if terminal resized too small
link to this item - Bugzilla: #1256531
The version of the Dnf tool included in Fedora 22 contains a bug which may cause it to crash during some operations if it is running in a terminal window and that window is resized to a smaller size. This is a fairly unusual case, but as it can cause dnf to crash during a package operation, it can cause severe consequences (the system being left in an inconsistent state). This bug will be fixed as soon as possible, but until then we strongly recommend you ensure any terminal windows in which you run dnf are of a reasonable size (80x24 characters is known to be safe) and do not resize them while it is running.
All user session processes killed on system shutdown
link to this item - Bugzilla: #1170765
systemd, as included in Fedora 22, contains an issue with scope management (which includes user sessions). On system shutdown (or reboot), processes running in scopes are killed (with SIGKILL) almost immediately. The practical effect of this is that if you shut down the system directly from a user session (e.g. a logged-in desktop), rather than logging out first, applications running within that session will be killed, rather than shutting down cleanly.
The effects of this depend heavily on the application. Some known effects are:
- Firefox will often display its recovery screen the next time you run it.
- If any bash shells were running in the session, their history may not be properly appended (so you will not find commands run in that shell in the
history
output on subsequent boots), and if a particularly unfortunate timing is encountered, the bash history may be entirely destroyed.
Other applications may display other effects; basically, applications cannot be relied upon to quit in an orderly fashion, so anything they would normally do when called upon to quit may not happen correctly.
Logging out of the user session before shutting down the system should avoid this issue.
This issue is being worked on as a high priority and a fix should be available soon.
GNOME issues
System hang when creating a user during GNOME first boot in basic graphics mode
link to this item - Bugzilla: #1206404
If you run the installer in "basic graphics" mode and do not create a user during the installation, you'll be offered to create the user the first time GNOME starts in the installed system. However, due to an issue with the basic graphics mode, the system will show you just an empty screen after the user is created, instead of logging you in or showing you the login screen. You'll need to reboot your computer, and then you'll be able to log in with your created user.
hp-plugin shows a blank gray window
link to this item - Bugzilla: #1219284
In Fedora 22 the X.org server no longer runs under root. Due to this change hp-plugin shows a blank gray window. To workaround this run hp-plugin -i
to get text mode. Another workaround is to run QT_X11_NO_MITSHM=1 hp-plugin
.
Plasma (KDE) issues
Initial setup sometimes starts in text mode instead of in graphics mode
link to this item - Bugzilla: #1185447
Sometimes happens that initial setup starts in text mode instead of graphical mode. In that case you can proceed with text mode or disable initial-setup-text.service by running command systemctl disable initial-setup-text.service
as root and restart. The graphical initial setup should be provided then.
Some third-party application rpms bundle Qt5 erroneously (hipchat, viber)
link to this item - Bugzilla: #1225749
Some third-party application rpms bundle Qt5 libraries incorrectly, which can cause runtime failures for other applications that depend on them. Problematic vendor rpms identified include hipchat and viber. Each vendor has been notified of the problem. If you have problems (especially for during fedora upgrades), it is recommended you uninstall these problematic rpms prior to upgrading.
Network issues
Wired network is not connected automatically on boot if installed without network cable during installation
link to this item - Bugzilla: #963952
If you install Fedora 22 without an ethernet cable connected during installation, the network card will be configured to be disabled by default. It means that your installed system will not automatically connect to a wired network after you plug your cable in. You'll need to enable the wired connection manually every time (in GNOME, that can be done using the system menu in upper right screen corner).
In order to configure your wired connection to activate automatically, open your network preferences (in GNOME, that's in system menu -> Settings icon -> Network), go to Wired connection preferences -> Identity tab -> enable Connect automatically checkbox. Alternatively, you can edit /etc/sysconfig/network-scripts/ifcfg-<interface_name>
from console and replace ONBOOT=no
with ONBOOT=yes
.
No network connection in VM when both host and guest installed from a Live image
link to this item - Bugzilla: #1146232
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
Massive screen corruption on older Intel graphics cards
link to this item - Bugzilla: #1226531
After upgrading to xorg-x11-drv-intel 2.99.917-9, certain older Intel chipsets display heavy screen corruption during common production tasks, like using the file explorer, browsing the web, working in terminal, etc. Both images and text are often distorted.
The fix is being worked on. As a temporary workaround, you can either downgrade to xorg-x11-drv-intel-2.99.917-6.20150211.fc22
:
$ sudo dnf downgrade xorg-x11-drv-intel-2.99.917-6.20150211.fc22
and make sure you don't update that package, or you can create /etc/X11/xorg.conf.d/20-intel.conf
and put this inside:
# A workaround for https://bugzilla.redhat.com/show_bug.cgi?id=1226531 Section "Device" Identifier "card0" Driver "intel" Option "AccelMethod" "uxa" EndSection
Please note that this can have other issues (like slower rendering) and that you should subscribe to the linked bug to be notified when this issue is resolved and remove this temporary workaround.
GNOME login screen doesn't appear on certain dual-GPU Macbooks after installation
link to this item - Bugzilla: #1218787
On certain Macbook laptops with dual graphics cards, Fedora 22 Live environment boots fine, but after installation there's just black screen and no boot splash followed by a GNOME login screen. There seems to be an issue with Wayland, an upcoming window system, which is used in GNOME login screen.
It seems that users of affected laptops should be able to work around this issue by booting in a basic graphics mode (adding nomodeset
to the boot command line in GRUB), and then editing /etc/gdm/custom.conf
file and uncommenting the following line:
#WaylandEnable=false
That will disable Wayland for GNOME login screen in future boots.
ARM issues
Fedora Server issues
Rolekit fails to deploy a Domain Controller on a virtual machine
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 later or RHEL 7.1 and later), it is recommended to create the VM using the virt-RNG device (which the Fedora Server 22 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 su -c '/usr/sbin/rngd -r /dev/urandom'
to make the system use the less-secure /dev/urandom entropy device.
For an in-depth explanation of entropy issues and how they can be resolved, see this excellent blog post.
Fedora Cloud issues
cloud-init fails to install packages from user-data
link to this item - Bugzilla: #1227484
When using the "packages" directive for cloud-init
on Fedora 22, it fails with selinux denials. There are a couple ways to work around this:
- Toggle SELinux while cloud-init sets up your instance by using "setenforce 0" in the "bootcmd" directive (then turn it back on in a "runcmd" directive).
- Manually install packages
- Use another tool to set up your instance (like ansible)
Other issues
Arabic, Cyrillic, and Hebrew characters not displayed in console
link to this item - Bugzilla: #1209460
The default console font in Fedora 22 has been changed to one ('eurlatgr') which provides greater coverage for Latin and Greek characters, but at the cost of Arabic, Cyrillic and Hebrew characters being dropped. It was intended that installations in languages which use the Arabic, Cyrillic or Hebrew characters should get a more appropriate default console font, but this has not yet been implemented.
Once the system is booted, the setfont
command can be used to change the console font - e.g. setfont latarcyrheb-sun16
to use the old default. The font can be changed permanently by editing the file /etc/vconsole.conf
and changing the line FONT="somefont" - e.g. change it from FONT="eurlatgr" to FONT="latarcyrheb-sun16".
This change applies only to new installations; the font used by existing installations will not be changed on upgrade.
Attaching gdb or strace to your own process is blocked by Yama
link to this item - Bugzilla: #1209492
There's now a bit more work involved if you want to attach gdb or strace to a process running under your own user. You can either do that under root, or configure /proc/sys/kernel/yama/ptrace_scope
. For more information, refer to the linked bug report and Yama documentation in Linux kernel.
Bad colors in gvim or terminals with light background
link to this item - Bugzilla: #1159920 - Bugzilla: #1225652
For the workstation spin, the default background color for vim was configured to dark in /etc/vimrc. This makes vim use ugly colors in gvim or terminals with a light background. To work-around this, use set background=light in your ~/.vimrc file.
Resolved issues
Mouse cursor get ocassionally de-synced in VMware
link to this item - Bugzilla: #1214474
If you run Fedora 22 in VMware, sometimes the host mouse and the guest mouse get out of sync and "ungrabbed". VMware seems to be working on a proper solution in Linux kernel. In the mean time, you can disable automatic mouse capture by editing preferences.ini
in your VMware configuration directory and setting these values:
pref.motionUngrab = "FALSE" pref.grabOnMouseClick = "TRUE" pref.motionGrab = "FALSE"
You will then have to click to get the mouse cursor grabbed, and press Ctrl+Alt to have it ungrabbed.
Alternatively, you can adjust vmmouse configuration and run Xorg as root in the guest, as explained in bug 1214474#c41. That is not recommended from a security standpoint, however.
PackageKit (GNOME Software, GNOME offline upgrades) ignores kernel modules updates from RPMFusion (VirtualBox, Nvidia driver, NDISwrapper, etc)
link to this item - Bugzilla: #1205649
If you have installed a kernel module from RPMFusion repository (the most common are VirtualBox or the proprietary Nvidia graphics driver), you will not see updates to these kernel modules in PackageKit package manager, and therefore neither in GNOME Software application. This will also make main kernel updates ignored as well.
In order to install latest Linux kernel (very recommended due to occasional security issue) and the relevant modules from RPMFusion, please regularly run sudo dnf update
from a terminal.
Liveusb-creator displays just a blank window on Fedora 22
link to this item - Bugzilla: #1212180
In Fedora 22 the X.org server no longer runs under root. Due to this change liveusb-creator run on F22 Workstation shows just a blank window. To temporarily work around this issue run this command: QT_GRAPHICSSYSTEM=native liveusb-creator
.
Logging out does not work when autologin enabled
link to this item - Bugzilla: #1245953
If you enabled autologin in GNOME in Fedora 22, trying to log out would fail to work correctly; instead of returning to the login screen, you would get stuck at a black screen.