No edit summary |
(add 1484130 (qemu failure to start with disk image on SMB share)) |
||
| (17 intermediate revisions by 5 users not shown) | |||
| Line 28: | Line 28: | ||
== Upgrade issues == | == Upgrade issues == | ||
{{Common bugs issue|wayland-frozen-login-after-upgrade|Frozen gray screen during logging in after upgrade|1394755}} | {{Common bugs issue|wayland-frozen-login-after-upgrade|Frozen gray screen during logging in after upgrade|1394755}} | ||
| Line 70: | Line 53: | ||
== Core system issues == | == Core system issues == | ||
{{Common bugs issue| | {{Common bugs issue|pulseaudio-start-delay|Pulseaudio fails to start if user logs out and back in again very quickly|1510301}} | ||
It has been reported that Pulseaudio (the default sound server for Fedora) sometimes fails to start correctly when a user logs out from a graphical session and logs back in immediately. The result of this is that sound playback and capture do not work as expected. | |||
{{ | This problem can be worked around by waiting a short time (about 30 seconds) between logins. It has also been suggested that changing the {{code|exit-idle-time}} setting in {{filename|/etc/pulse/daemon.conf}} to a lower value (e.g. 0) may prevent this problem occurring. | ||
{{Common bugs issue|selinux-non-ascii|''Non-ASCII characters found'' error messages appear during package update etc.|1502009}} | |||
The | While using Fedora 27, you may notice error messages like {{code|/etc/selinux/targeted/contexts/files/file_contexts.bin: line 1 error due to: Non-ASCII characters found}} during package updates, system boot or in other situations. These errors do not indicate any serious problem and can safely be ignored. The SELinux maintainers are aware of the cause of this problem and intend to fix it with a future update to the {{package|selinux-policy}} packages. | ||
{{Common bugs issue|27-update-bash|Shell behavior changes (prompt etc.) on update from some Fedora 27 pre-release installs|1193590}} <!--#SCRIPTIGNORE# this comment marks issue to be ignored by scripts --> | |||
Some people who installed Fedora 27 between the Beta and Final release, and subsequently updated to the Final package set, may notice undesired changes in shell behavior. The most obvious symptom is that the prompt no longer looks as it usually does in Fedora, but shows the upstream default prompt (something like {{code|bash-4.4$}}). However, the problem actually runs deeper: when this happens, the shell is not sourcing {{filename|/etc/bashrc}} as it usually would, meaning everything that is usually implemented via {{filename|/etc/bashrc}} does not happen (including loading of all profile scripts in {{filename|/etc/profile.d}}, which has many consequences including default aliases not being set up). | |||
This will only happen to user accounts created with version 4.4.12-11 of the {{package|bash}} package, when the system is updated to version 4.4.12-12. That version was in the updates-testing repository for Fedora 27 between 2017-09-11 and 2017-09-30, and was pushed to the stable repository on 2017-09-30. 4.4.12-12 was pushed to updates-testing on 2017-10-31 and to stable on 2017-11-08. So if you installed Fedora 27, or created user accounts on an installed Fedora 27 system, between 2017-09-11 and 2017-11-08, you ''may'' be affected by this issue (it will depend on factors including the install image you used, what repositories were enabled, and so on). | |||
'''No fresh install of Fedora 27 Final or upgrade to Fedora 27 performed after 2017-11-08 should be affected by this issue'''. | |||
If you are affected by this issue, you can resolve it simply by adding this text to the top of the {{filename|~/.bashrc}} for all affected user accounts (including root): | |||
# Source global definitions | |||
if [ -f /etc/bashrc ]; then | |||
. /etc/bashrc | |||
fi | |||
It usually appears between the lines {{code|# .bashrc}} and {{code|# User specific aliases and functions}}. This should fully resolve the problem. | |||
For the record, this issue was caused by a change to {{filename|/etc/bashrc}} sourcing which was not fully thought through. Prior to 4.4.12-11, the template for {{filename|~/.bashrc}} in Fedora included the lines above, causing bash shells launched by any user to source {{filename|/etc/bashrc}} via {{filename|~/.bashrc}}. 4.4.12-11 changed bash to source {{filename|/etc/bashrc}} directly on every startup, and changed the template for user {{filename|~/.bashrc}} files to not include the above lines. However, this change turned out to have several problematic consequences which were not understood before it was made, and which could not be fixed in time for the Fedora 27 release. | |||
We felt the only viable response was to revert the change, and this is what 4.4.12-12 does. However, since 4.4.12-11 changed the {{filename|~/.bashrc}} template, all user accounts created with that version of bash do not have those lines, and so with bash 4.4.12-12, nothing causes {{filename|/etc/bashrc}} to be sourced by bash shells run by those accounts. Fedora package scripts by policy may never touch files in a user's home directory, so it would be against our policies for the bash package to attempt to "fix" affected user accounts on update; even ignoring the policy, trying to do this would be a very bad idea as any such attempt could contain bugs which caused more severe problems, or could add the stanza to user accounts from which it had been intentionally removed for some reason. | |||
We do apologize to users affected by this issue for the inconvenience, and for being unable to come up with a better course of action. | |||
{{Common bugs issue|boot-random-block|Boot process is very slow or appears to hang with kernel 4.16.4 onwards|1572944}} | |||
From version 4.16.4, the kernel (upstream: this issue is not Fedora-specific) [https://lkml.org/lkml/2018/4/12/711 is stricter] in determining when the kernel is "ready" to supply random numbers. Previously it indicated it was "ready" when the RNG was able to provide only a limited degree of randomness; now it indicates it is "ready" only when the RNG is able to provide randomness sufficient for cryptographic purposes. This was considered a [https://access.redhat.com/security/cve/cve-2018-1108 security issue]. | |||
If any part of a system's boot process happens to involve blocking on this "readiness", the boot process will be delayed until the kernel indicates it is "ready", and of course with this change, that becomes more likely to happen. This is particularly likely to affect systems without access to a hardware random number generator and with only limited internal sources of entropy; in practice this means it commonly affects virtual machines and cloud instances. In particularly serious cases, the delay can be such that timeouts kick in and the system fails to boot fully. | |||
If your system seems to boot fine with kernel 4.16.3 or earlier, but is slow to boot or appears to hang during boot with 4.16.4 and later, you may well be affected by this issue. You can try simply hitting random keys on the keyboard when the boot process appears to hang: this acts as a source of entropy and allows the kernel to seed its RNG. If you can get the boot process to continue after several seconds of keyboard mashing, this indicates you are suffering from this issue. It can also be a viable workaround in some cases, though of course not all. | |||
For virtual machines and cloud instances, allowing the host to provide entropy to the VM/instance can help significantly, particularly if the host has a hardware RNG and this is configured as the source. The details of how to do this vary between virtualization systems and clouds. [https://wiki.openstack.org/wiki/LibvirtVirtioRng#Random_number_generator_device This page] documents how to do it in OpenStack. [[QA:Testcase_Virtualization_VirtioRNG|This test case]] includes some information on how to do it in libvirt. [https://wiki.qemu.org/Features/VirtIORNG This page] explains how to do it directly in qemu. Other virtualization systems may also support virtio-rng. | |||
A particularly severe form of this issue manifests itself if you boot with an initramfs generated while {{package|dracut-fips}} is installed. In this case the boot process will hang extremely early (at the time systemd starts up, so if any systemd activity has happened at all, you are already past this case), and the use of virtio-rng will not help (for VMs/cloud instances) as it is not yet loaded at this point. If you find yourself in this situation, it's probably best to remove {{package|dracut-fips}} and run {{command|sudo dracut -f}} to re-generate the initramfs for the current kernel. This form of the issue may potentially affect Fedora images generated with kernel 4.16.4 or later, but so far as we know, no official or semi-official images affected by this issue have yet been released. | |||
== GNOME issues == | == GNOME issues == | ||
| Line 95: | Line 113: | ||
[[File:gdm-pick-x11.png|500px]] | [[File:gdm-pick-x11.png|500px]] | ||
{{Common bugs issue| | {{Common bugs issue|shell-crash-wayland|User session dies if GNOME Shell crashes on Wayland|1494586|1469129}} <!--#SCRIPTIGNORE# this comment marks issue to be ignored by scripts --> | ||
One difference between GNOME on X.org and GNOME on Wayland lies in what happens if GNOME Shell itself crashes. When running GNOME on X.org, a Shell crash usually does not end the session; the Shell will be automatically restarted and the session will continue. For a one-off crash, all you (the user) will usually see is the panel and perhaps window titles suddenly disappear and reappear shortly afterwards, and a crash notification appear. This behaviour is possible because X.org is the display server, with GNOME Shell just an X application running on top of it. | |||
However, when running GNOME on Wayland, the Shell itself is effectively the display server. Thus, if it crashes, the entire user session is usually taken down with it. This can result in the loss of unsaved data, and so on. | |||
Efforts are afoot upstream to somehow separate the display server / compositor role from the rest of the Shell and make it as minimal and reliable as possible. Until this is complete, there is nothing really that Fedora can do about this limitation. | |||
During Fedora 27 testing, several GNOME Shell crasher bugs were reported by multiple users, including #[[rhbug:1494586|1494586]] and #[[rhbug:1469129|1469129]]. We cannot be entirely sure if Shell in Fedora 27 is significantly more crash-prone than in previous recent releases, but it appears at least possible that for some users and some configurations, this may be the case. Obviously, if you are affected by recurring Shell crashes, the consequence of losing the entire user session can be frustrating. | |||
We advise folks suffering from Shell crashes taking down their user session to first try disabling any extensions they have enabled, one by one, to see if one is the cause; Shell crashes can quite often be caused by misbehaving extensions. If you can avoid the crashes by disabling an extension, this may suffice (please report the issue to the extension author if you can isolate it to a specific extension). Otherwise, we advise that you may wish to consider using the GNOME on Xorg session (see above) rather than the default Wayland session; this should at least prevent the crashes from ending your GNOME session when they occur. We do apologize for any inconvenience and/or lost data caused by such Shell crashes. | |||
{{Common bugs issue|wayland-root-apps|Running graphical apps with root privileges (e.g. gparted) does not work on Wayland|1274451}} <!--#SCRIPTIGNORE# this comment marks issue to be ignored by scripts --> | {{Common bugs issue|wayland-root-apps|Running graphical apps with root privileges (e.g. gparted) does not work on Wayland|1274451}} <!--#SCRIPTIGNORE# this comment marks issue to be ignored by scripts --> | ||
| Line 149: | Line 168: | ||
To work around this issue in gedit you can just set a custom font in ''Preferences'' and make its point size larger than normal. A similar workaround may be available for other affected apps. | To work around this issue in gedit you can just set a custom font in ''Preferences'' and make its point size larger than normal. A similar workaround may be available for other affected apps. | ||
{{Common bugs issue|multi-display-positioning|Arrangement of multiple displays unreliable with more than two displays|1511638}} | |||
{{Common bugs update testing|FEDORA-2017-6d66333885}} | |||
The GNOME tool for configuring and arranging multiple displays (''Displays'') has been reported by several users to be unreliable on systems with more than two displays. This appears to be the case even when only two of the displays are active - a common affected configuration is a laptop with two external displays and the laptop screen closed. The symptoms are that when attempting to move the displays around in the tool, they simply fail to move, or immediately jump back to their original positions. | |||
Reporters have said that it's usually possible to achieve the desired result after trying several times, and sometimes moving the displays around in different directions. It has also been reported that clicking and releasing shortly (not dragging) one of the displays will make it jump out of the way, allowing movement of the others. | |||
{{Common bugs issue|gdm-missingcursor-qxl|Pointer invisible in GDM in virtual machines|1507931}} | |||
When booting Fedora 27 Workstation (or any other Fedora 27 install which uses GDM as the login manager) on a virtual machine using the QXL virtual video adapter (which is the default for ''virt-manager'' and GNOME Boxes in most cases), the mouse pointer will not appear in the login manager (GDM). Once you log in, the pointer will show up in the logged-in desktop session. Note the pointer is in fact present and active - if you can figure out where it is, you can click on things - it's just not ''visible''. | |||
It is quite easy to complete GDM using only the keyboard (to log in with the default user, you only have to hit 'enter', type their password, and hit 'enter' again). You can also work around this issue by switching to a different adapter in the virtual machine configuration, e.g. 'virtio'. | |||
{{Common bugs issue|vpn-statusmenu-missing|Content of VPN entry in GNOME status menu sometimes does not appear|1497897}} | |||
Some users of Fedora 27 have reported that, sometimes, the icon and text of the VPN entry in the GNOME status menu (the one that appears when you click the top-right of the screen) does not appear. Usually it will show a lock icon and the text 'VPN Off' (or information on any active VPN connection), but it appears that occasionally the icon and text do not appear; the menu just appears to contain an entirely empty row. The entry does function as intended. | |||
No fix for this issue is yet known, but it has no functional impact - you can still use the 'empty' menu item. | |||
== Plasma (KDE) issues == | == Plasma (KDE) issues == | ||
| Line 160: | Line 198: | ||
== Hardware issues == | == Hardware issues == | ||
{{Common bugs issue| | {{Common bugs issue|surface-book-microcode|Fedora 27 images may fail to boot on Surface Book|1501362}} | ||
Two users have reported that Fedora 27 images fail to boot on the Microsoft Surface Book (model uncertain), with some suggestion that this is due to an issue with processor microcode updating. If you are trying to boot or install Fedora 27 on a Surface Book and it is failing, you may try installing Fedora 26 and then upgrading to Fedora 27 as a workaround. You may also try a network installation of Fedora 27, or using one of the [https://dl.fedoraproject.org/pub/alt/live-respins/ unofficial post-release live respin images]. | |||
== Application issues == | == Application issues == | ||
| Line 171: | Line 207: | ||
Kerberos doesn't work in certain configurations on Fedora 27, probably on some upgraded systems and when {{package|sssd-kcm}} is installed. You'll see errors like <code>Internal credentials cache error while getting default ccache</code>. If you're affected, removing <code>/var/lib/sss/secrets/secrets.ldb</code> file and rebooting seems to help. | Kerberos doesn't work in certain configurations on Fedora 27, probably on some upgraded systems and when {{package|sssd-kcm}} is installed. You'll see errors like <code>Internal credentials cache error while getting default ccache</code>. If you're affected, removing <code>/var/lib/sss/secrets/secrets.ldb</code> file and rebooting seems to help. | ||
{{Common bugs issue|qemu-cifs-disk|Running qemu (virt-manager, gnome-boxes...) virtual machine with disk image on SMB share fails with 'Failed to get "write" lock' error|1484130}} | |||
In Fedora 27, if you try to run a qemu virtual machine (including default virt-manager and GNOME Boxes virtual machines) with a disk image stored on an SMB share, it may fail to start with a 'Failed to get "write" lock' error. | |||
Unfortunately, the only known workaround for this issue at present is to move the image to a local disk, or to a different type of network share. | |||
== ARM issues == | == ARM issues == | ||
{{Common bugs issue|aarch64-ifcfg-issue|Network configuration file from image creation | {{Common bugs issue|aarch64-ifcfg-issue|Network configuration file from image creation on AArch64 disk images|1507676}} <!--#SCRIPTIGNORE# this comment marks issue to be ignored by scripts --> | ||
A network configuration file from the disk image creation process is still present on the aarch64 disk images and can be safely removed to prevent any conflicts. | A network configuration file from the disk image creation process is still present on the aarch64 disk images and can be safely removed to prevent any conflicts. | ||
| Line 182: | Line 224: | ||
{{Common bugs issue|arm-kde-login|Unable to log in on the KDE disk image after completing Initial-Setup|1507926}} | {{Common bugs issue|arm-kde-login|Unable to log in on the KDE disk image after completing Initial-Setup|1507926}} | ||
After completing Initial-Setup on the armhfp KDE disk image you will need to install additional packages in order to log in to the desktop. Connect to tty2 and log in as root or ssh to the system from another computer and install 'KDE plasma desktop'. | After completing the Initial-Setup utility on the armhfp KDE disk image you will need to install additional packages in order to log in to the desktop. Connect to tty2 and log in as root or ssh to the system from another computer and install 'KDE plasma desktop'. | ||
dnf install plasma-desktop | dnf install plasma-desktop | ||
| Line 188: | Line 230: | ||
{{Common bugs issue|aarch64-root-password-set|Root password listed as 'set' in Initial-Setup TUI on AArch64 disk images|1507940}} | {{Common bugs issue|aarch64-root-password-set|Root password listed as 'set' in Initial-Setup TUI on AArch64 disk images|1507940}} | ||
For security, the root | For security, the root account is 'locked' during the aarch64 disk image creation. As a result, the initial-setup configuration utility incorrectly lists the password for the root account as 'set'. Users should take care to either set the root password or to create a user account with Administrator privileges. | ||
{{Common bugs issue|aarch64-nonetwork-pine64|There is no network on the Pine 64 with AArch64 disk images|}} | {{Common bugs issue|aarch64-nonetwork-pine64|There is no network on the Pine 64 with AArch64 disk images|}} | ||
| Line 201: | Line 243: | ||
== Fedora Atomic issues == | == Fedora Atomic issues == | ||
== Soas == | |||
Red Hat Bugzilla – Bug 1519042 | |||
soas starts in journal: | |||
This can be confusing for users | |||
Fix by hitting f1 key then f3 key to get to main menu | |||
== Other issues == | == Other issues == | ||
| Line 226: | Line 277: | ||
To work around this problem for now, modify the repository definition in your flattened kickstart to use a direct URL or a mirrorlist URL before starting your compose. | To work around this problem for now, modify the repository definition in your flattened kickstart to use a direct URL or a mirrorlist URL before starting your compose. | ||
[[Category:Common bugs]] | |||
Latest revision as of 23:52, 1 May 2018
This page documents common bugs in Fedora 27 and, if available, fixes or workarounds for these problems. If you find your problem on 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 27 release announcement and the Fedora 27 release notes for specific information about changes in Fedora 27 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
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).
macOS can't be booted from grub
link to this item - Bugzilla: #893179
If you install Fedora into dual-boot on a Mac, Fedora creates several "Mac OS X" menu items in grub that should allow you to boot macOS. These menu items are broken, however, and macOS can't be booted from grub. The available workaround is to press and hold down the ⌥ Opt (or right Alt) key when starting the computer, which will show you UEFI boot menu, and select macOS partition to boot from there.
Installer on several live images does not offer iSCSI support
link to this item - Bugzilla: #1395620 - Bugzilla: #1429132
On many or all Fedora Live images, the installer will not offer iSCSI functionality (the "Add iSCSI target" button will not appear in the 'Specialized & Network Disks' screen). You can avoid the problem by running sudo dnf install storaged-iscsi from a console before starting the install process, or by installing from a dedicated installer image rather than a live image.
Upgrade issues
Frozen gray screen during logging in after upgrade
link to this item - Bugzilla: #1394755
This happens if you have EasyScreenCast extension installed and upgrade. It is the same bug as #screen-recording-freezes-gnome, see that entry for a full description and a workaround.
Every second login attempt fails in certain configurations
link to this item - GNOME bug #775463
If you've upgraded your system, you might see an issue where every second login attempt fails and you're returned to the login screen (without any visible error). This happens for Wayland sessions, but not for X11 sessions. Currently it seems this might be caused by org.gnome.SessionManager auto-save-session gsettings value being true instead of default false. You can see your current value like this:
$ gsettings get org.gnome.SessionManager auto-save-session
and change it like this:
$ gsettings set org.gnome.SessionManager auto-save-session false
If you encounter this bug, you may see a crash notification that traces back to bug #1384508. This crash, and the bug report, actually cover a crash in the "Oh no!" screen which GNOME attempts to show when a core component crashes: the report doesn't actually cover the initial crash of the gnome-session component. This has caused some confusion, because the same "Oh no!" screen crash can be encountered in several other ways, and so several people with quite different bugs are all following the #1384508 bug report. See the entry for that crash for more details. GNOME bug #775463 is the bug report for this specific auto-save-session crash case.
GRUB update might fail if /boot is on XFS
link to this item - Bugzilla: #1227736
If you use XFS filesystem on /boot and upgrade your system, you might end up in a GRUB minimal prompt (just a command prompt, no kernel to choose from interactively) after the upgrade is complete. The problem is in the system rebooting while XFS is in dirty state and not all changes being saved to the filesystem yet.
In order to prevent this issue, you might try to disable plymouth (by removing rhgb kernel boot option) during the upgrade or uninstall it prior the upgrade (these workarounds were not tested).
If this already occurred to you, you should be able to fix the problem by booting a Live or rescue image, mounting the filesystem in question (which should replay the journal), perhaps running xfs_repair to make sure there are no more issues. In the worst case, you'll also need to fully re-install grub.
Core system issues
Pulseaudio fails to start if user logs out and back in again very quickly
link to this item - Bugzilla: #1510301
It has been reported that Pulseaudio (the default sound server for Fedora) sometimes fails to start correctly when a user logs out from a graphical session and logs back in immediately. The result of this is that sound playback and capture do not work as expected.
This problem can be worked around by waiting a short time (about 30 seconds) between logins. It has also been suggested that changing the exit-idle-time setting in /etc/pulse/daemon.conf to a lower value (e.g. 0) may prevent this problem occurring.
Non-ASCII characters found error messages appear during package update etc.
link to this item - Bugzilla: #1502009
While using Fedora 27, you may notice error messages like /etc/selinux/targeted/contexts/files/file_contexts.bin: line 1 error due to: Non-ASCII characters found during package updates, system boot or in other situations. These errors do not indicate any serious problem and can safely be ignored. The SELinux maintainers are aware of the cause of this problem and intend to fix it with a future update to the 
selinux-policy
Shell behavior changes (prompt etc.) on update from some Fedora 27 pre-release installs
link to this item - Bugzilla: #1193590
Some people who installed Fedora 27 between the Beta and Final release, and subsequently updated to the Final package set, may notice undesired changes in shell behavior. The most obvious symptom is that the prompt no longer looks as it usually does in Fedora, but shows the upstream default prompt (something like bash-4.4$). However, the problem actually runs deeper: when this happens, the shell is not sourcing /etc/bashrc as it usually would, meaning everything that is usually implemented via /etc/bashrc does not happen (including loading of all profile scripts in /etc/profile.d, which has many consequences including default aliases not being set up).
This will only happen to user accounts created with version 4.4.12-11 of the
No fresh install of Fedora 27 Final or upgrade to Fedora 27 performed after 2017-11-08 should be affected by this issue.
If you are affected by this issue, you can resolve it simply by adding this text to the top of the ~/.bashrc for all affected user accounts (including root):
# Source global definitions
if [ -f /etc/bashrc ]; then
. /etc/bashrc
fi
It usually appears between the lines # .bashrc and # User specific aliases and functions. This should fully resolve the problem.
For the record, this issue was caused by a change to /etc/bashrc sourcing which was not fully thought through. Prior to 4.4.12-11, the template for ~/.bashrc in Fedora included the lines above, causing bash shells launched by any user to source /etc/bashrc via ~/.bashrc. 4.4.12-11 changed bash to source /etc/bashrc directly on every startup, and changed the template for user ~/.bashrc files to not include the above lines. However, this change turned out to have several problematic consequences which were not understood before it was made, and which could not be fixed in time for the Fedora 27 release.
We felt the only viable response was to revert the change, and this is what 4.4.12-12 does. However, since 4.4.12-11 changed the ~/.bashrc template, all user accounts created with that version of bash do not have those lines, and so with bash 4.4.12-12, nothing causes /etc/bashrc to be sourced by bash shells run by those accounts. Fedora package scripts by policy may never touch files in a user's home directory, so it would be against our policies for the bash package to attempt to "fix" affected user accounts on update; even ignoring the policy, trying to do this would be a very bad idea as any such attempt could contain bugs which caused more severe problems, or could add the stanza to user accounts from which it had been intentionally removed for some reason.
We do apologize to users affected by this issue for the inconvenience, and for being unable to come up with a better course of action.
Boot process is very slow or appears to hang with kernel 4.16.4 onwards
link to this item - Bugzilla: #1572944
From version 4.16.4, the kernel (upstream: this issue is not Fedora-specific) is stricter in determining when the kernel is "ready" to supply random numbers. Previously it indicated it was "ready" when the RNG was able to provide only a limited degree of randomness; now it indicates it is "ready" only when the RNG is able to provide randomness sufficient for cryptographic purposes. This was considered a security issue.
If any part of a system's boot process happens to involve blocking on this "readiness", the boot process will be delayed until the kernel indicates it is "ready", and of course with this change, that becomes more likely to happen. This is particularly likely to affect systems without access to a hardware random number generator and with only limited internal sources of entropy; in practice this means it commonly affects virtual machines and cloud instances. In particularly serious cases, the delay can be such that timeouts kick in and the system fails to boot fully.
If your system seems to boot fine with kernel 4.16.3 or earlier, but is slow to boot or appears to hang during boot with 4.16.4 and later, you may well be affected by this issue. You can try simply hitting random keys on the keyboard when the boot process appears to hang: this acts as a source of entropy and allows the kernel to seed its RNG. If you can get the boot process to continue after several seconds of keyboard mashing, this indicates you are suffering from this issue. It can also be a viable workaround in some cases, though of course not all.
For virtual machines and cloud instances, allowing the host to provide entropy to the VM/instance can help significantly, particularly if the host has a hardware RNG and this is configured as the source. The details of how to do this vary between virtualization systems and clouds. This page documents how to do it in OpenStack. This test case includes some information on how to do it in libvirt. This page explains how to do it directly in qemu. Other virtualization systems may also support virtio-rng.
A particularly severe form of this issue manifests itself if you boot with an initramfs generated while sudo dracut -f to re-generate the initramfs for the current kernel. This form of the issue may potentially affect Fedora images generated with kernel 4.16.4 or later, but so far as we know, no official or semi-official images affected by this issue have yet been released.
GNOME 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):
User session dies if GNOME Shell crashes on Wayland
link to this item - Bugzilla: #1494586 - Bugzilla: #1469129
One difference between GNOME on X.org and GNOME on Wayland lies in what happens if GNOME Shell itself crashes. When running GNOME on X.org, a Shell crash usually does not end the session; the Shell will be automatically restarted and the session will continue. For a one-off crash, all you (the user) will usually see is the panel and perhaps window titles suddenly disappear and reappear shortly afterwards, and a crash notification appear. This behaviour is possible because X.org is the display server, with GNOME Shell just an X application running on top of it.
However, when running GNOME on Wayland, the Shell itself is effectively the display server. Thus, if it crashes, the entire user session is usually taken down with it. This can result in the loss of unsaved data, and so on.
Efforts are afoot upstream to somehow separate the display server / compositor role from the rest of the Shell and make it as minimal and reliable as possible. Until this is complete, there is nothing really that Fedora can do about this limitation.
During Fedora 27 testing, several GNOME Shell crasher bugs were reported by multiple users, including #1494586 and #1469129. We cannot be entirely sure if Shell in Fedora 27 is significantly more crash-prone than in previous recent releases, but it appears at least possible that for some users and some configurations, this may be the case. Obviously, if you are affected by recurring Shell crashes, the consequence of losing the entire user session can be frustrating.
We advise folks suffering from Shell crashes taking down their user session to first try disabling any extensions they have enabled, one by one, to see if one is the cause; Shell crashes can quite often be caused by misbehaving extensions. If you can avoid the crashes by disabling an extension, this may suffice (please report the issue to the extension author if you can isolate it to a specific extension). Otherwise, we advise that you may wish to consider using the GNOME on Xorg session (see above) rather than the default Wayland session; this should at least prevent the crashes from ending your GNOME session when they occur. We do apologize for any inconvenience and/or lost data caused by such Shell crashes.
Running graphical apps with root privileges (e.g. gparted) does not work on Wayland
link to this item - Bugzilla: #1274451
Running graphical applications with root privileges does not work on Wayland. This is not exactly a bug, but an intentional design, at least at present: it is part of a general plan to make Wayland safer than X (which is very vulnerable to exploitation by malicious applications). It is generally intended that apps which need root privileges to perform some operations should be designed such that the application itself does not need root privileges, but uses a mechanism like PolicyKit to have privileges granted to a restricted subset of itself which only handles the operations that actually need elevated privileges.
This means you cannot run, for example, sudo gedit /etc/someconfigfile.conf or sudo gvim /etc/someconfigfile.conf to edit a file which requires root privileges to save. It also stops
For applications which use the GTK+ Gvfs file access layer, there is an admin:/// resource indicator available. So you can, for example, run gedit admin:///etc/someconfigfile.conf to edit a file requiring root privileges to save. In future, this mechanism will be better integrated into applications so you do not have to manually invoke it. This will not work for applications which do not use Gvfs, though, like gvim.
In other cases, you may be able to use an alternative application. For instance, you may find the Disks application (gnome-disks from a console) can do what you wanted to do with
There is a workaround you can use to allow non-Wayland-native apps to run as root if you absolutely must: from a console as the regular user, run xhost +si:localuser:root. This will not work for Wayland-native applications, however, only apps which run via XWayland.
Finally, if none of these options is workable for you, you can switch back to using X.org instead of Wayland, as documented above.
Totem fails to play media on Wayland in virtual machines
link to this item - Bugzilla: #1467368
Totem (Videos) will fail to play media when using a Wayland session in virtual machines (applies to default libvirt VMs, but not VirtualBox). The audio will play, but neither video nor a totem window will appear. If you need to play media in this environment, please either use X11 session, or a different media player.
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).
Screen recording freezes GNOME in certain conditions
link to this item - Bugzilla: #1394755
If you start screen recording in GNOME (Ctrl+Alt+Shift+R) your session might freeze hard (you can only get out of it using SysRq or ssh in and kill your session). This is related to gstreamer registry cache file (~/.cache/gstreamer-1.0/registry.x86_64.bin) - when it is changed (might happen during a plugin update, or if you remove the file), this bug occurs. It is not only triggered by the integrated GNOME recorder, but also by extensions/tools like EasyScreenCast - in that case, the freeze occurs immediately during login.
The existing workaround is to select Xorg session in the session picker (see #Wayland issues) and log in at least once. That fixes the cache file and then it should be possible to log in even to Wayland session. It also helps to remove EasyScreenCast extension (if you have it installed), and remove clutter-gst2 package (but some of your apps might depend on it). If none of that helps for you, please continue using the Xorg session instead of the default Wayland session, until this bug is fixed.
Scroll events are not sent into virtual machines from touchpad/trackpoint under Wayland
link to this item - Bugzilla: #1386602
Under Wayland, sending scroll events into a virtual machine works well when using the mouse, but doesn't work when using touchpad or trackpoint. As a workaround, switch to Xorg session on your host.
Workstation login screen (GDM) does not show newly-installed desktops until system is rebooted or shut down
link to this item - Bugzilla: #1398770
If you install an additional desktop environment after installing Fedora Workstation, it will not appear on the session chooser in the login screen (GDM) if you simply log out from a user session and log in again. This is because gdm keeps running after logging you into your user session, and there is no signal to tell it that a new desktop has been installed; it will not notice until it is restarted. It is possible to restart GDM without restarting the system, but in practice rebooting or shutting down and starting up again is usually the easiest thing to do.
Some text views (gedit...) not properly scaled when Large Text or a text scaling factor set
Due to an issue with some specific text view widgets, when a 'text scaling factor' is set in GNOME, this scaling is not properly applied in a few specific cases. This makes text appear tiny. Setting the Large Text option in Universal Access sets a text scaling factor; it is also possible to set one manually in the gnome-tweak-tool application, so if you have set either of those options, you will likely see this bug.
This issue is known to affect gedit (the text in the document being edited, not the user interface), anjuta, and latexila.
To work around this issue in gedit you can just set a custom font in Preferences and make its point size larger than normal. A similar workaround may be available for other affected apps.
Arrangement of multiple displays unreliable with more than two displays
link to this item - Bugzilla: #1511638
A candidate fix for this issue has been submitted to the updates-testing repository for testing. Users experiencing this problem are encouraged to test this update and report to Bodhi whether it solves the problem. To test the update, run this command:
sudo dnf --enablerepo=updates-testing update --advisory=FEDORA-2017-6d66333885The GNOME tool for configuring and arranging multiple displays (Displays) has been reported by several users to be unreliable on systems with more than two displays. This appears to be the case even when only two of the displays are active - a common affected configuration is a laptop with two external displays and the laptop screen closed. The symptoms are that when attempting to move the displays around in the tool, they simply fail to move, or immediately jump back to their original positions.
Reporters have said that it's usually possible to achieve the desired result after trying several times, and sometimes moving the displays around in different directions. It has also been reported that clicking and releasing shortly (not dragging) one of the displays will make it jump out of the way, allowing movement of the others.
Pointer invisible in GDM in virtual machines
link to this item - Bugzilla: #1507931
When booting Fedora 27 Workstation (or any other Fedora 27 install which uses GDM as the login manager) on a virtual machine using the QXL virtual video adapter (which is the default for virt-manager and GNOME Boxes in most cases), the mouse pointer will not appear in the login manager (GDM). Once you log in, the pointer will show up in the logged-in desktop session. Note the pointer is in fact present and active - if you can figure out where it is, you can click on things - it's just not visible.
It is quite easy to complete GDM using only the keyboard (to log in with the default user, you only have to hit 'enter', type their password, and hit 'enter' again). You can also work around this issue by switching to a different adapter in the virtual machine configuration, e.g. 'virtio'.
link to this item - Bugzilla: #1497897
Some users of Fedora 27 have reported that, sometimes, the icon and text of the VPN entry in the GNOME status menu (the one that appears when you click the top-right of the screen) does not appear. Usually it will show a lock icon and the text 'VPN Off' (or information on any active VPN connection), but it appears that occasionally the icon and text do not appear; the menu just appears to contain an entirely empty row. The entry does function as intended.
No fix for this issue is yet known, but it has no functional impact - you can still use the 'empty' menu item.
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
Fedora 27 images may fail to boot on Surface Book
link to this item - Bugzilla: #1501362
Two users have reported that Fedora 27 images fail to boot on the Microsoft Surface Book (model uncertain), with some suggestion that this is due to an issue with processor microcode updating. If you are trying to boot or install Fedora 27 on a Surface Book and it is failing, you may try installing Fedora 26 and then upgrading to Fedora 27 as a workaround. You may also try a network installation of Fedora 27, or using one of the unofficial post-release live respin images.
Application issues
Kerberos might be broken in certain cases
link to this item - Bugzilla: #1494843
Kerberos doesn't work in certain configurations on Fedora 27, probably on some upgraded systems and when Internal credentials cache error while getting default ccache. If you're affected, removing /var/lib/sss/secrets/secrets.ldb file and rebooting seems to help.
link to this item - Bugzilla: #1484130
In Fedora 27, if you try to run a qemu virtual machine (including default virt-manager and GNOME Boxes virtual machines) with a disk image stored on an SMB share, it may fail to start with a 'Failed to get "write" lock' error.
Unfortunately, the only known workaround for this issue at present is to move the image to a local disk, or to a different type of network share.
ARM issues
Network configuration file from image creation on AArch64 disk images
link to this item - Bugzilla: #1507676
A network configuration file from the disk image creation process is still present on the aarch64 disk images and can be safely removed to prevent any conflicts.
rm /etc/sysconfig/network-scripts/ifcfg-enp1s0
Unable to log in on the KDE disk image after completing Initial-Setup
link to this item - Bugzilla: #1507926
After completing the Initial-Setup utility on the armhfp KDE disk image you will need to install additional packages in order to log in to the desktop. Connect to tty2 and log in as root or ssh to the system from another computer and install 'KDE plasma desktop'.
dnf install plasma-desktop
Root password listed as 'set' in Initial-Setup TUI on AArch64 disk images
link to this item - Bugzilla: #1507940
For security, the root account is 'locked' during the aarch64 disk image creation. As a result, the initial-setup configuration utility incorrectly lists the password for the root account as 'set'. Users should take care to either set the root password or to create a user account with Administrator privileges.
There is no network on the Pine 64 with AArch64 disk images
When booting the AArch64 disk images on the Pine 64 you will not have a network connection. To correct this issue create a symlink named 'dtb' pointing to the installed kernel dtb directory (dtb-4.13.9-300.fc27.aarch64) and reboot the system.
cd /boot; ln -sf dtb-4.13.9-300.fc27.aarch64 dtb
Fedora Server issues
Fedora Cloud issues
Fedora Atomic issues
Soas
Red Hat Bugzilla – Bug 1519042 soas starts in journal:
This can be confusing for users
Fix by hitting f1 key then f3 key to get to main menu
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
- For BIOS systems:
- 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.
livemedia-creator cannot create images from kickstarts using metalink repositories (including official kickstarts)
link to this item - Bugzilla: #1464843
If you try to use the official livemedia-creator tool to create a live image using a kickstart based on one of the official Fedora kickstarts (from the fedora-kickstarts repository, or the
This is because the livemedia-creator+anaconda combination does not currently correctly handle kickstarts that specify repositories using metalink URLs. If you're wondering "in that case, how were the official images built?", the answer is that the repository definitions from the kickstart files are actually modified on-the-fly by the Fedora compose system before the images are built (in order to use a local disk repository that's produced as part of the compose process).
To work around this problem for now, modify the repository definition in your flattened kickstart to use a direct URL or a mirrorlist URL before starting your compose.