Common F19 bugs

From FedoraProject

(Difference between revisions)
Jump to: navigation, search
(add 968951 (config leak from admin user to other created user accounts))
(46 intermediate revisions by 10 users not shown)
Line 2: Line 2:
  
 
This page documents common bugs in Fedora 19 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 19 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.
 
{{admon/note|Fedora 19 pre-release|Fedora 19 has not yet been released. During this pre-release period, this page will cover known issues in the Fedora 19 pre-releases. Issues that are fixed will be removed from the page once a fix is available (for instance, an issue that affects the Beta but is fixed in the final release will be removed at the time of that release).}}
 
  
 
== Release Notes ==
 
== Release Notes ==
Read the [[F19 Beta release announcement]] and the [http://fedorapeople.org/groups/docs/release-notes/en-US/ Fedora 19 Beta Release Notes] <!--[http://docs.fedoraproject.org/en-US/Fedora/19/html/Release_Notes/ Fedora 19 release notes]--> for specific information about changes in Fedora 19 and other general information.
+
Read the [[F19_release_announcement]] and the [http://docs.fedoraproject.org/en-US/Fedora/19/html/Release_Notes/ Fedora 19 release notes] for specific information about changes in Fedora 19 and other general information.
  
 
== My bug is not listed ==
 
== My bug is not listed ==
Line 51: Line 49:
 
-->
 
-->
  
== Resolved issues ==
+
== Installation issues ==
{{Anchor|uefi-upgrade-grub2}}
+
{{Anchor|installer-squish}}
=== Native UEFI Fedora installation fails to boot after upgrade to Fedora 19 ===
+
=== Installer screens sometimes do not appear at full screen width ===
<small>[[#uefi-upgrade-grub2|link to this item]] - [[rhbug:966586|Bugzilla: #966586]]</small>
+
<small>[[#installer-squish|link to this item]] - [[rhbug:869364|Bugzilla: #869364]]</small>
  
If you had a UEFI native installation of Fedora 18 with the default bootloader configuration, and you upgraded to a Fedora 19 package set that includes a version of {{package|grub2}} earlier than grub2-2.00-18.fc19, the upgraded system will likely fail to load grub correctly at boot. This is due to a bug which caused initialization of grub2 in graphical mode to fail on UEFI systems. The bug was worked around for fresh installs by having grub2 configured in console instead of graphical mode, but as upgraded systems use the old bootloader configuration, the bug still affected upgrades.
+
Sometimes when you visit a screen in the Fedora 19 Beta installer (a 'spoke') more than once, it will display incorrectly - it will be squeezed into an area less than the full width of the screen, and sometimes less than the full height also. We have been attempting to fix this bug for a while but it is a difficult one to pin down.
  
This issue was fixed in the updated ''grub2-2.00-18.fc19'' package. To solve the issue if you already upgraded and are affected, you can change grub2 to console mode. Boot a live or rescue image, mount the installed system (at least the /etc and EFI system partitions), edit {{filename|etc/default/grub}} within the mounted filesystem and change the line that starts ''GRUB_TERMINAL_OUTPUT'' to read ''GRUB_TERMINAL_OUTPUT="console"'' (or create such a line if none exists). Then run {{command|grub2-mkconfig}} with the -o parameter to specify the correct location for the updated configuration file within the EFI system partition. The system should now boot correctly.
+
Usually you can still use the screen in the reduced size version, though it may look very strange. If you get completely stuck, though, you will unfortunately be required to reboot and restart the installation process. We apologize for any inconvenience.
  
After updating to ''grub2-2.00-18.fc19'' you can return to a graphical grub2 configuration, if you like, and it should now work.
+
Sadly, we were unable to resolve this issue ahead of the final release of Fedora 19. We were unable to diagnose the cause of the issue, so without any idea how long it might take to fix or how difficult the fix may be, we could not consider adjusting the release schedule.  We will attempt to make sure the issue is fixed for the release of Fedora 20.
  
== Installation issues ==
+
{{Anchor|mac-uefi-esp}}
{{Anchor|deselect-litd-crash}}
+
=== Apple EFI Macs: EFI install alongside existing EFI installed OS (including OS X) results in ''you have not created a bootloader stage1 target device'' error ===
=== Installation crash if you de-select all hard disks and click Done when running from a USB stick ===
+
<small>[[#mac-uefi-esp|link to this item]] - [[rhbug:1010495|Bugzilla: #1010495]]</small>
<small>[[#deselect-litd-crash|link to this item]] - [[rhbug:959677|Bugzilla: #959677]]</small>
+
  
The Fedora 19 Beta installer has a bug which can cause it to crash with the error ''IndexError: list index out of range'' in a specific (but moderately commonly-encountered) circumstance. You will hit this crash if you:
+
If you try to do a native UEFI install of Fedora 19 alongside a native UEFI install of OS X and re-use the existing EFI system partition, the installer will incorrectly consider the existing EFI system partition as invalid and report that ''you have not created a bootloader stage1 target device''. Unfortunately, the Fedora automatic partitioning algorithm will actually attempt to re-use the EFI system partition, and so you will run into this bug in any Fedora 19 installation attempt where you use the automatic partitioning algorithm and do not choose to delete the existing EFI system partition.
  
* Boot the installer from a USB stick written with livecd-iso-to-disk or (possibly) liveusb-creator
+
Practically speaking, there are a few different approaches to dealing with this problem. If you do not mind losing your OS X installation, you can simply choose to delete it (including the EFI system partition), and let Fedora occupy the rest of the disk. Fedora should create a new EFI system partition and install successfully.
* Intentionally or otherwise de-select all hard disks on the Installation Destination screen and click ''Done''
+
  
It is quite easy to inadvertently do this in Fedora 19 Beta as the design used to indicate selected disks on the Installation Destination spoke is somewhat confusing. A relatively small check mark indicates disks that are selected as install targets, and if you only have a single disk, it will be pre-selected for you. It is quite easy to hit this bug if you don't notice this, click the disk to 'select' it (in fact de-selecting it) and then click Done.
+
If you wish to preserve your OS X installation, install Fedora 19 Final, and dual boot, you must use the installer's 'custom partitioning' path. Make sure to leave the existing EFI system partition intact, but do '''not''' set a mount point for it. Do '''not''' use the ''Create partitions for me'' button. Instead, manually create a new EFI system partition, and set it to be mounted at {{filename|/boot/efi}}. Manually create other partitions as usual. Complete custom partitioning, and your installation should proceed successfully. See the [https://docs.fedoraproject.org/en-US/Fedora/19/html/Installation_Guide/ Installation Guide] for general instructions on the partitioning process, if necessary.
  
If you do hit the bug, it is quite safe to simply reboot and re-try the installation. Note that this bug cannot lead to any loss of pre-existing data. This bug does not affect installs from optical media, or from USB sticks written with 'dd' or analogous methods. The status of the bug with regard to USB sticks written with third-party utilities such as unetbootin is unknown, but in general, the bug will not occur if the USB stick from which you are running the installer shows as a potential target disk on the Installation Destination screen (which should never happen, but at present does happen for dd-written sticks). It may occur if the USB stick from which you are installing is (correctly) suppressed from being shown as a possible target device.
+
You could also try installing Fedora 18 or Fedora 19 Beta. These should allow you to use automatic partitioning to install alongside OS X, assuming you do not run into any other bugs they may have contained. You could then upgrade to Fedora 19 Final - with [[FedUp]] from Fedora 18, or yum from Fedora 19 Beta. You will still wind up with two EFI system partitions in this case.
  
This issue should be resolved before the final release of Fedora 19.
+
We are investigating the possibility of producing an [[Anaconda/Updates|updates image]] to make it easier to deal with this bug. We apologize for any inconvenience it causes you.
  
{{Anchor|uefi-nvram-full}}
+
{{Anchor|mdraid-live}}
=== UEFI install fails with ''BootLoaderError: failed to set new efi boot target'' ===
+
<small>[[#uefi-nvram-full|link to this item]] - [[rhbug:949786|Bugzilla: #949786]]</small>
+
  
Some UEFI-native installations of Fedora 19 Beta may fail near the end of installation, with the error ''BootLoaderError: failed to set new efi boot target'' (or a similar error).
+
=== Intel firmware RAID-1+ sets not visible in live installer ===
 +
<small>[[#mdraid-live|link to this item]] - [[rhbug:975649|Bugzilla: #975649]]</small>
  
Systems with UEFI firmwares contain a small amount of NVRAM (non-volatile RAM) storage, into which certain UEFI configuration and other data can be written by the firmware or by UEFI-native operating systems. This error usually indicates that the kernel considers the NVRAM storage area to be full, and is refusing to write anything to it when the Fedora installer attempts to write an EFI boot manager entry for the newly installed Fedora system.
+
Fedora 19 testing indicates that Intel firmware RAID sets at level 1 and higher (so not level 0) fail to appear as potential target devices in the installer when running from a live image. They appear as normal when installing from a non-live image (the DVD or network installer).
  
In Fedora 19 Beta (in fact, in all recent kernel builds - this behaviour is not specific to Fedora, though it is very new), the kernel attempts not to write to the NVRAM storage when doing so may trigger the recently-publicised [http://mjg59.dreamwidth.org/22855.html bug in some Samsung firmwares], which causes the system firmware to fail if the NVRAM storage is more than 50% full. There are cases where this can interact badly with firmwares that do not do garbage collection very well, and you may therefore be affected by this problem even if your NVRAM storage area is not full and you do not use one of the affected Samsung firmwares. You may also, of course, actually have a full NVRAM storage area.
+
This issue appears to be caused by mdmon failing to start or being killed during the live image start up. It may be possible to work around it by starting mdmon manually prior to running the installer. The other 'workaround' for the issue is simply to install from the DVD or network install image rather than a live image if you wish to install to an affected firmware RAID device.
  
If you are affected by this problem, there are several things you can try. The Fedora 19 Beta installer attempts to delete non-essential data from the NVRAM prior to writing a boot manager entry. However, it cannot force the firmware to do garbage collection after requesting the deletion. In some cases, several reboots may be required to trigger garbage collection. So the first thing to try if you are affected by this is to reboot the system several times, and then re-try the installation.
+
{{Anchor|partial-kickstart-problems}}
 +
=== Problems with Installation Source and Installation Destination spokes when installing from a partially complete kickstart ===
 +
<small>[[#partial-kickstart-problems|link to this item]] - [[rhbug:972265|Bugzilla: #972265]] - [[rhbug:972266|Bugzilla: #972266]]</small>
  
If that does not help, you may try resetting the firmware to defaults, or updating or reinstalling the firmware. However, note that doing so can reset the EFI boot manager to its default state, which may remove entries for any UEFI native operating systems you have installed!
+
If you attempt to install Fedora 19 using a partially-complete kickstart - in particular, a kickstart which specifies a package set but no installation source or destination - you will find that the interactive process for setting those options behaves strangely. On the Installation Source spoke, you may not be able to use the default ''Closest mirror'' option. If you are affected by this problem, you can manually enter the URL of the Fedora 19 mirror list, and check the ''This URL refers to a mirror list.'' box. The URLs for the 64-bit and 32-bit mirror lists are <code>https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-19&arch=x86_64</code> and <code>https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-19&arch=i386</code> respectively.
  
If all else fails, you may be forced to install Fedora 19 Beta in BIOS emulation mode rather than UEFI native mode.
+
The Installation Destination spoke appears to require you to complete it multiple times to complete configuration: each time it will set another element of the configuration. Even after doing this, you may find a bootloader target disk is not selected. To set one, first enter the ''Full disk summary and bootloader...'' screen and select not to install a bootloader, and complete the spoke once again. Then complete the spoke one more time, this time selecting the correct target disk for the bootloader, and the configuration should now be complete.
  
We will continue to work on this issue to see if we can improve the situation in any way for the Final release.
+
As these issues take some effort to work around, it may be a better idea simply to use a complete kickstart, or at least one which specifies an installation source and destination. The [[Anaconda/Kickstart]] page should help you with the required syntax.
  
Note for journalists: this issue has ''nothing at all to do with Secure Boot''. Please be careful in distinguishing Secure Boot from UEFI.
+
{{Anchor|no-media-present}}
 +
=== Storage devices without media show as 0-byte partitions and can crash the installer ===
 +
<small>[[#no-media-present|link to this item]] - [[rhbug:960794|Bugzilla: #960794]]</small>
  
{{Anchor|nfsv3-nolock-fail}}
+
Several testers have reported an unusual case with certain storage devices in the Fedora 19 installer. Some devices report themselves to the kernel as drives with 'no media present'. Identified cases so far include an Android-based phone when plugged into the system but not set in USB storage mode, and a few types of card reader when no card is inserted.
=== NFS repositories fail to work ===
+
<small>[[#nfsv3-nolock-fail|link to this item]] - [[rhbug:968023|Bugzilla: #968023]]</small>
+
  
If you try to use an NFS repository as a package source for a Fedora 19 Beta installation, you may find it fails to work for no obvious reason. More specifically, NFSv4 mounts should work; NFSv3 mounts will fail. If you are not sure of the differences between v3 and v4, [http://www.vanemery.com/Linux/NFSv4/NFSv4-no-rpcsec.html this page] may be useful, though it contains some outdated information. Note that it is entirely possible to have an NFS server configured such that you can mount the same share via NFSv3 or NFSv4, possibly with a different path.
+
If such a device is present during installation, it will not be shown in the 'Installation Destination' screen's list of disks, but if you enter the custom partitioning mode, the device will appear as a single 0-byte partition. If you attempt to manipulate this partition in any way, the installer may crash with an error ''AttributeError: 'NoneType' object has no attribute 'type' ''.
  
To make NFSv3 mounts work, you must pass the ''nolock'' parameter. If you are configuring your NFS repository graphically in the installer, there is a field labelled ''NFS mount options:'' - simply type ''nolock'' into it. If you are using the ''inst.repo'' kernel command line parameter, you can enter ''inst.repo=nfs:nolock:host.name:/path/to/repo'' instead of ''inst.repo=nfs:host.name:/path/to/repo''.
+
There are two obvious workarounds for this issue. In most cases it should be possible simply to disconnect the offending device: there is no need to connect your phone or external card reader during installation. If the offending device is not easily removable, you can simply leave the bogus 0-byte 'partition' entirely alone, and your installation should proceed successfully.
  
This bug should be resolved before the final release of Fedora 19.
+
{{Anchor|texlive-ht-insanity}}
 +
=== Network installation with ''Authoring and Publishing'' group selected fails ===
 +
<small>[[#texlive-ht-insanity|link to this item]] - [[rhbug:959696|Bugzilla: #959696]]</small>
  
{{Anchor|installer-squish}}
+
Due to an unmarked conflict between two texlive-related packages ({{package|ht}} and {{package|texlive-tex4ht-bin}}), Fedora 19 installations with the ''Authoring and Publishing'' package group selected (and possibly with the ''Font design'' group selected) will fail.
=== Installer screens sometimes do not appear at full screen width ===
+
<small>[[#installer-squish|link to this item]] - [[rhbug:869364|Bugzilla: #869364]]</small>
+
  
Sometimes when you visit a screen in the Fedora 19 Beta installer (a 'spoke') more than once, it will display incorrectly - it will be squeezed into an area less than the full width of the screen, and sometimes less than the full height also. We have been attempting to fix this bug for a while but it is a difficult one to pin down.
+
The offending packages (and groups) are not present on the Fedora 19 DVD, so the bug is not present there. The issue affects only network installs. It will be resolved once the conflict between the two packages is fixed with an update, so long as you enable the ''updates'' repository in your installation.
  
Usually you can still use the screen in the reduced size version, though it may look very strange. If you get completely stuck, though, you will unfortunately be required to reboot and restart the installation process. We apologize for any inconvenience.
+
{{Anchor|uefi-msdos-label}}
  
We are aiming to try and fix this bug before the final release of Fedora 19, though as mentioned above, it is proving complex to pin down and fix for good.
+
=== UEFI install to ms-dos ('MBR') labelled disk fails with unclear errors ===
 +
<small>[[#uefi-msdos-label|link to this item]] - [[rhbug:978430|Bugzilla: #978430]]</small>
 +
 
 +
As veterans of the [https://docs.fedoraproject.org/en-US/Fedora/16/html/Release_Notes/sect-Release_Notes-Changes_for_Sysadmin.html Fedora 16 release] may remember, there are two commonly-used 'disk label' or 'partition table' formats known as 'gpt' and 'ms-dos' or 'mbr'.
 +
 
 +
Fedora 19's installer effectively requires that native UEFI installations be performed to a disk with the 'gpt' format (in fact, it requires that the EFI system partition be on such a disk). In fact, this is not a requirement of the official UEFI specification: it leaves open the possibility of an EFI system partition residing on an ms-dos labelled disk, though it is possible that some firmwares may not support such a configuration.
 +
 
 +
In any case, if you attempt to do a native UEFI install of Fedora 19 such that the EFI system partition will reside on an ms-dos labelled disk, this will fail. You are likely get an error of the form ''you have not created a bootloader stage1 target device'', possibly with the note that the volume backing the EFI system partition ''must have one of the following disklabel types: gpt.'' You may also observe unusual behaviour on the ''Reclaim space'' screen, if you use it in your installation attempt. Note that you can encounter this error message even when installing to a gpt-labelled disk if you use custom partitioning and fail to correctly configure an EFI system partition: when doing a UEFI install you must include a partition of the 'EFI system partition' type, and mount it at the path /boot/efi.
 +
 
 +
We have found that there appear to be some systems 'in the wild' with existing native UEFI operating system installations to an ms-dos labelled drive. Unfortunately, this bug means you cannot install Fedora 19 in a dual-boot configuration to the same drive as such an operating system. You would need to install to a second drive in order to dual boot.
 +
 
 +
If you wish to do a native UEFI installation of Fedora 19, it must be to a gpt-labelled disk, or you must configure your installation such that all existing partitions on the disk on which the EFI system partition will reside will be deleted (doing this will cause the installer to reformat it with a gpt disk label). Note that it is not possible to change the label format of a disk in a non-destructive way: it requires a complete re-format.
 +
 
 +
For Fedora 20, we intend to revise the installer to handle this situation in a better way. We apologize for any inconvenience it causes.
 +
 
 +
As a workaround, you can append "noefi" to the kernel boot options in the GRUB menu.
 +
 
 +
As for some laptops, there is an option in BIOS to set make it use Legacy mode instead of uefi, which makes it accept disks that aren't gpt-labelled (i.e [http://support.lenovo.com/ContentResources/Migrated%20Assets/pc/support/site_wss/77353_thinkpadsetup.gif some Lenovo models]).
 +
{{Anchor|usb-target-filter}}
 +
 
 +
=== USB stick from which install is running appears as a possible install target ===
 +
<small>[[#usb-target-filter|link to this item]] - [[rhbug:874381|Bugzilla: #874381]]</small>
 +
 
 +
In some circumstances, when you are installing Fedora 19 from a USB stick, the stick itself will show up as a possible 'target disk' on the Installation Destination screen where you choose which disk(s) to install onto. This is not intended to happen. It is not possible to install to the USB stick from which the installation is running: if you attempt to do this, the installation will fail. Naturally, therefore, we recommend you simply avoid selecting the stick on this screen.
 +
 
 +
{{Anchor|multipath-missing-second}}
 +
=== Multipath devices disappear from Installation Destination screen second time through ===
 +
<small>[[#multipath-missing-second|link to this item]] - [[rhbug:955664|Bugzilla: #955664]]</small>
 +
 
 +
If for any reason you visit the Installation Destination screen more than once during a Fedora 19 installation to a system with available multipath storage device(s), the multipath device(s) will show in the device list the first time through, but not on subsequent visits. You will still be able to find it by using the ''Add a disk...'' button, though, so you can continue with your installation.
 +
 
 +
{{Anchor|extlinux-package-missing}}
 +
=== Hidden ''extlinux'' install option works only with network install ===
 +
<small>[[#extlinux-package-missing|link to this item]] - [[rhbug:970184|Bugzilla: #970184]]</small>
 +
 
 +
The feature [[Features/SyslinuxOption]] provides the Fedora 19 installer with a hidden (mostly undocumented) boot parameter ''extlinux''. If you pass this parameter, the installer will attempt to install the extlinux bootloader instead of grub2. However, this obviously requires extlinux to be available to the installer. During live and DVD-sourced installations, extlinux is not available, and any attempt to install with this parameter will fail with the error ''No such file or directory: '/mnt/sysimage/boot/extlinux/extlinux.conf'''. The parameter will work correctly when performing a network installation. So, if you intend to use this hidden feature of Fedora 19, use the non-live installer, and ensure network repositories (or at least some repository containing the {{package|extlinux}} package) is available to the installer.
 +
 
 +
{{Anchor|reboot-delay}}
 +
=== Reboot after non-live install often delayed for a minute or so ===
 +
<small>[[#reboot-delay|link to this item]] - [[rhbug:974383|Bugzilla: #974383]]</small>
 +
 
 +
After successfully completing an installation of Fedora 19 from the DVD or network installation media, you will see a button to ''Reboot''. Sometimes, after you click this, the system will appear to hang at a console. In fact, the reboot process is just delayed; if you leave it for a minute or two, the system will reboot correctly. We do recommend you wait it out to avoid any possibility of filesystem damage, rather than forcing a reset.
  
 
{{Anchor|checkmark-disk-select}}
 
{{Anchor|checkmark-disk-select}}
Line 128: Line 166:
 
Add to this that if you only have a single hard disk it will be pre-selected as an install target when you enter the page, and it has become clear that this design is confusing people. Many users have entered the screen and clicked to 'select' their single disk - in fact de-selecting it, because it was already selected, but not noticing the mistake.
 
Add to this that if you only have a single hard disk it will be pre-selected as an install target when you enter the page, and it has become clear that this design is confusing people. Many users have entered the screen and clicked to 'select' their single disk - in fact de-selecting it, because it was already selected, but not noticing the mistake.
  
Please be aware that the check mark not the blue highlight indicates the disks selected as targets. We will endeavour to improve this interface before the final release of Fedora 19.
+
Please be aware that the check mark not the blue highlight indicates the disks selected as targets. We will endeavour to improve this interface before the release of Fedora 20.
  
 
{{Anchor|bootloader-password}}
 
{{Anchor|bootloader-password}}
Line 137: Line 175:
  
 
Lawrence Lowe [https://bugzilla.redhat.com/show_bug.cgi?id=840160#c14 suggests] that the --unrestricted parameter can be added to ''menuentry'' lines in the grub config file to make them available without the password being entered.
 
Lawrence Lowe [https://bugzilla.redhat.com/show_bug.cgi?id=840160#c14 suggests] that the --unrestricted parameter can be added to ''menuentry'' lines in the grub config file to make them available without the password being entered.
 
{{Anchor|initial-setup-everything}}
 
=== Non-GNOME initial setup utility always shows all actions ===
 
<small>[[#initial-setup-everything|link to this item]] - [[rhbug:963935|Bugzilla: #963935]]</small>
 
 
Fedora 19 includes a new {{package|initial-setup}} utility which replaces the old ''firstboot'' utility as the tool that runs on the first boot after installation to complete any necessary setup tasks before normal use of the system can commence. Note that there is an alternative - and completely different - {{package|gnome-initial-setup}} utility which is used instead of initial-setup on the Desktop spin and on installation of GNOME from the DVD or network install images; this bug does not affect GNOME installations, which use this other utility. (If you are not sure which one you are seeing, gnome-initial-setup is a wizard-type interface which starts by asking you to choose a language, while initial-setup looks almost identical to the installer interface).
 
 
In Fedora 19 Beta installations of any graphical desktop other than GNOME, the ''initial-setup'' utility always runs, and always displays all possible actions (set date and time, set root password, and create user accounts), no matter what actions you took during installation. It is intended that actions that are not necessary or useful should not be displayed; so for instance, if you created a root password and a user account, or an administrative user account, during installation, ''initial-setup'' should not really need to run at all, but this has not yet been implemented.
 
 
We recommend you use initial-setup only to create a user account if you did not create one during installation. If you did create a user account during installation, the best thing to do is simply to quit it as soon as it runs.
 
  
 
{{Anchor|initial-setup-user}}
 
{{Anchor|initial-setup-user}}
Line 152: Line 180:
 
<small>[[#initial-setup-user|link to this item]] - [[rhbug:965797|Bugzilla: #965797]]</small>
 
<small>[[#initial-setup-user|link to this item]] - [[rhbug:965797|Bugzilla: #965797]]</small>
  
In Fedora 19 Beta, the new initial-setup utility described in the [[#initial-setup-everything|previous entry]] does not present any kind of warning if you leave it without having created a user account either during installation or from initial-setup itself. Thus it is relatively easy to arrive at a graphical login screen without any user accounts available.
+
In Fedora 19, the new initial-setup utility (shown after a graphical install with any desktop other than GNOME if you do not create a user account during installation) does not present any kind of warning if you leave it without having created a user account. Thus it is relatively easy to arrive at a graphical login screen without any user accounts available.
  
 
The old utility would allow you to skip user account creation, but required you to click through a warning in order to do so, to ensure no-one did it inadvertently. This is also how initial-setup should behave.
 
The old utility would allow you to skip user account creation, but required you to click through a warning in order to do so, to ensure no-one did it inadvertently. This is also how initial-setup should behave.
  
We have tested that the desktops for which the new tool is used - KDE, Xfce, LXDE, MATE, and Sugar - all allow login as root; so this bug should not present any major roadblocks to accessing the installed system. However, if you do install without creating a user account, we '''strongly''' advise that you log in as root only in order to create a user account, and then immediately log out and in future always log in as the user account. Using a graphical desktop with root privileges can increase your vulnerability to remote attack, to simple mistakes having severe consequences, and to bugs caused by software not expecting to be run with root privileges.
+
We have tested that the desktops for which the new tool is used - KDE, Xfce, LXDE, MATE, and Sugar - all allow login as root, so this bug should not present any major roadblocks to accessing the installed system. However, if you do install without creating a user account, we '''strongly''' advise that you log in as root only in order to create a user account, and then immediately log out and in future always log in as the user account. Using a graphical desktop with root privileges can increase your vulnerability to remote attack, to simple mistakes having severe consequences, and to bugs caused by software not expecting to be run with root privileges.
  
 
This issue does not affect the GNOME initial setup utility: in fact, that utility will not allow you to skip user account creation at all.
 
This issue does not affect the GNOME initial setup utility: in fact, that utility will not allow you to skip user account creation at all.
  
This issue is expected to be resolved before the final release of Fedora 19.
+
{{Anchor|FedUp-boot-arguments}}
 +
=== Fedup: upgrade to F19 can't start without rd.luks.uuid/rd.lvm.lv/rd.md.uuid boot args ===
 +
<small>[[#FedUp-boot-arguments|link to this item]] - [[rhbug:974000|Bugzilla: #974000]]</small>
 +
 
 +
The system hangs during the reboot after running the command <code>fedup --network 19</code> from F18. F17 and F18 would boot without specifying 'rd.luks.uuid' or 'rd.lvm.lv' arguments, but F19 won't.
  
== Upgrade issues ==
+
Under normal circumstances, the installer sets up those arguments for you, but some people who migrated from GRUB to GRUB2 by hand have *dropped* those arguments - which works fine for F17 and F18, but fails for F19.
{{Anchor|fedup-reboot-hang}}
+
=== System hangs at the end of the process when upgrading to Fedora 19 with fedup ===
+
<small>[[#fedup-reboot-hang|link to this item]] - [[rhbug:957783|Bugzilla: #957783]]</small>
+
  
When upgrading to Fedora 19 using the recommended [[FedUp]] method, the system may hang at the end of the upgrade process, whereas it should automatically reboot into the upgraded system. The upgrade process has been completed at this point, and it is safe simply to force a reboot at this point. Barring unrelated issues, the upgraded system will be in place and working.
+
The recommended fix is to restore the rd.luks.uuid/rd.lvm.lv/etc. arguments from your old grub.cfg. In a pinch, you can add "rd.auto=1" to your boot arguments to make dracut try to automatically set up *every* disk it finds; this isn't recommended for general use though.
  
 
== Hardware issues ==
 
== Hardware issues ==
Line 182: Line 211:
 
The kernel developers plan to address this issue in a future kernel update by blacklisting X2APIC functionality on affected systems, when the NVIDIA adapter is in use.
 
The kernel developers plan to address this issue in a future kernel update by blacklisting X2APIC functionality on affected systems, when the NVIDIA adapter is in use.
  
== Software issues ==
+
{{Anchor|gdm-transition-fail}}
{{Anchor|gis-config-leak}}
+
=== Transition from GDM to desktop fails on systems with old or no 3D graphics adapters ===
=== First user account's settings may be applied to other user accounts ===
+
<small>[[#gdm-transition-fail|link to this item]] - [[rhbug:955779|Bugzilla: #955779]]</small>
<small>[[#gis-config-leak|link to this item]] - [[rhbug:968951|Bugzilla: #968951]]</small>
+
  
If you install Fedora 19 Beta with the GNOME desktop (either from the 'desktop' live image, or from the DVD or network install with the default package set), and do not create a user account during the installation process, then on first boot of the installed system you will see the ''gnome-initial-setup'' utility and it will require you to create a user account. This will be an administrative user account.
+
Several users have reported a problem with logging in from GDM on systems with an old, or no, 3D graphics adapter (including virtual machines). This seems to affect some virtual setups, and older graphics adapters that are blacklisted from being used for 3D acceleration of GNOME Shell: pre-i915 Intel adapters, pre-R300 (Radeon 9500) Radeon adapters, and pre-NV30 (GeForce FX) NVIDIA adapters. The effect of the bug is that, after entering a username and password, the screen remains blank grey, never transitioning to the desktop. Some testers do not seem to be affected by the problem; we are yet to pin down precisely what is causing it.
  
After completing gnome-initial-setup, you are immediately logged into GNOME with the newly-created user account. If you now immediately create other new user accounts, without rebooting the system first, these new user accounts will have various settings from the initial user account copied over to them, including the admin user account's online accounts if any were configured during initial setup (though not the associated passwords).
+
If you are affected by the problem, the simplest solution is to switch to a different login manager. The best options are likely KDM and LightDM, as they have received the most testing with the widest range of desktops besides GDM. To switch to kdm or lightdm, simply install the {{package|kdm}} or {{package|lightdm}} package and run {{command|su -c 'systemctl enable kdm.service'}} or {{command|su -c 'systemctl enable lightdm.service'}} then {{command|su -c 'systemctl disable gdm.service'}}, then reboot. You should see the new login manager, and you should be able to log in successfully with it.
  
You will not be affected by this issue if you create the initial user account in the installer rather than in gnome-initial-setup, or if you reboot after creating the admin user account and before creating any others.
+
== Software issues ==
 +
{{Anchor|rhel-qxl-crash}}
 +
=== System fails to start correctly (due to qxl driver crash) when booting Fedora 19 Beta as a virtual guest on a RHEL 6 or 7 host ===
 +
<small>[[#rhel-qxl-crash|link to this item]] - [[rhbug:952666|Bugzilla: #952666]]</small>
  
This is an inadvertent bug, it is not intended behaviour. It will be resolved before the final release of Fedora 19.
+
It has been reported that the {{package|xorg-x11-drv-qxl}} driver in Fedora 19 crashes during X startup when trying to boot a Fedora 19 Beta image in a virtual guest configured with qxl/SPICE graphics on a Red Hat Enterprise Linux 6.4 or 7 (pre-release) host. This likely affects earlier versions of RHEL 6, clones of RHEL 6 such as CentOS, and possibly very old (and unsupported) Fedora releases as well.
  
{{Anchor|llvmpipe-sse2}}
+
To work around this issue, configure your guest to use cirrus/VNC or vga/VNC instead of qxl/SPICE. This is really a bug on the host side rather than the guest side, and updates for RHEL should be made available soon after Fedora 19's release that should resolve this problem.
=== GDM and GNOME render incorrectly on older systems ===
+
<small>[[#llvmpipe-sse2|link to this item]] - [[rhbug:909473|Bugzilla: #909473]]</small>
+
  
Some testing has indicated that Fedora 19's llvmpipe-based software 3D rendering does not work properly on older CPUs (those without SSE2 or equivalent instructions; SSE2 was introduced by Intel with the Pentium 4 in 2001, and AMD added support for it with the introduction of the Opteron and Athlon 64 lines in 2003). If your graphics card is not sufficient for GNOME 3 - which may well be the case on older machines - Fedora will try and use software rendering to display GDM and GNOME, but due to this bug, it may fail entirely or render incorrectly. GNOME 3.8, as included in Fedora 19, no longer has a non-accelerated 'fallback mode' for use on systems where 3D acceleration does not work correctly.
+
{{Anchor|qxl-19on19-crash}}
 +
=== X may crash when using the qxl driver in a Fedora 19 virtual machine on a Fedora 19 host ===
 +
<small>[[#qxl-19on19-crash|link to this item]] - [[rhbug:978612|Bugzilla: #978612]]</small>
  
At present the only workaround for this problem is to use a non-3D accelerated login manager and desktop. KDM is probably the most robust alternative login manager. The KDE, Xfce, LXDE and MATE desktops all work without 3D acceleration and would be possible alternatives to GNOME.
+
Some testers have reported X.org crashes in Fedora 19 KVM virtual machines running on Fedora 19 hosts when using the qxl graphics driver. The issue seems to be triggered by a resolution change in the guest, but some testers have observed it happening during an installation from the KDE live image: we are not yet sure why. This issue does not seem to affect all testers, and seems to affect some worse than others.
  
{{Anchor|i686-qxl-crash}}
+
If you find yourself suffering from this issue, there are a couple of possible workarounds. You can configure your virtual machine to use the cirrus video adapter rather than qxl and the VNC display method rather than SPICE (though this may cause issues with GNOME Shell), or you can use the ''Basic graphics mode'' option from the Fedora 19 bootloader menu (or simply pass the parameter ''nomodeset'' on the kernel command line).
=== System fails to start correctly (due to qxl driver crash) when booting 32-bit image in Fedora virtualization ===
+
<small>[[#i686-qxl-crash|link to this item]] - [[rhbug:965101|Bugzilla: #965101]]</small>
+
  
Several testers have reported that, using Fedora's official virtualization stack (qemu-kvm/libvirt) with the virtual machine's video adapter set as 'qxl', if you boot a 32-bit Fedora 19 Beta image, the system will fail to boot correctly due to a crash in the {{package|xorg-x11-drv-qxl}} video driver.
+
An updated [https://admin.fedoraproject.org/updates/FEDORA-2013-11937/xorg-x11-drv-qxl-0.1.1-0.10.20130514git77a1594.fc19 xorg-x11-drv-qxl] package has been submitted to the updates-testing repository for testing. Users experiencing this problem are encouraged to test this update and [https://admin.fedoraproject.org/updates/FEDORA-2013-11937/xorg-x11-drv-qxl-0.1.1-0.10.20130514git77a1594.fc19 report to Bodhi] whether it solves the problem. To test the update, run this command:
 +
<pre>su -c 'yum --enablerepo=updates-testing update xorg-x11-drv-qxl'</pre> and then reboot the guest system. Of course, this will not be useful for the initial installation of a Fedora 19 virtual machine: for that phase, try one of the workarounds mentioned above.
  
As we do not support 32-bit systems as virtual hosts at all, there is a very simple workaround for this bug in all supported (i.e. 64-bit host) configurations: configure your guest with a 64-bit processor and boot a 64-bit Fedora 19 Beta image. If you absolutely must boot a 32-bit image for some reason, you can re-configure your virtual machine to use a different video adapter; the 'cirrus' or 'vga' models ought to work, although performance will likely be poor and there may be glitches in rendering of the GNOME desktop.
+
{{Anchor|gnome-video-crash}}
 +
=== Crash when GNOME introductory video attempts to play ===
 +
<small>[[#gnome-video-crash|link to this item]] - [[rhbug:962092|Bugzilla: #962092]]</small>
  
{{Anchor|rhel-qxl-crash}}
+
When a user logs into GNOME 3.8 (as included in Fedora 19) for the first time, a short introductory video is intended to play. Fedora 19 testing has indicated that, sometimes, there is a crash, and the video fails to play. On first login to a user account, you may notice a crash report for the ''/usr/libexec/gnome-initial-setup-player'' process. Aside from the crash report and the failure of the video to play, this bug appears to have no further consequences. We have not yet identified the circumstances under which the crash occurs.
=== System fails to start correctly (due to qxl driver crash) when booting Fedora 19 Beta as a virtual guest on a RHEL 6 host ===
+
<small>[[#rhel-qxl-crash|link to this item]] - [[rhbug:967679|Bugzilla: #967679]]</small>
+
 
+
It has been reported that the {{package|xorg-x11-drv-qxl}} driver in Fedora 19 Beta crashes during X startup when trying to boot a Fedora 19 Beta image in a virtual guest configured with qxl/SPICE graphics on a Red Hat Enterprise Linux 6.4 host. This likely affects earlier versions of RHEL 6, clones of RHEL 6 such as CentOS, and possibly very old (and unsupported) Fedora releases as well.
+
 
+
To work around this issue, configure your guest to use cirrus/VNC or vga/VNC instead of qxl/SPICE. Developers are currently considering how this issue can be resolved before the final release of Fedora 19.
+
  
 
{{Anchor|update-notification-online}}
 
{{Anchor|update-notification-online}}
Line 223: Line 249:
 
<small>[[#update-notification-online|link to this item]] - [[rhbug:863592|Bugzilla: #863592]]</small>
 
<small>[[#update-notification-online|link to this item]] - [[rhbug:863592|Bugzilla: #863592]]</small>
  
Fedora 18 introduced a feature called [[Features/OfflineSystemUpdates|offline system updates]]. Its description suggests that 'offline' updates - updates performed across a system reboot - are now the default method for graphical updating in Fedora 18, at least when using GNOME. However, the feature's implementation is still somewhat incomplete: GNOME will still pop up notifications of available updates, and if you click on these notifications as you are encouraged to do, the 'online' update process (updates installed within the running system) will be launched.
+
Fedora 18 introduced a feature called [[Features/OfflineSystemUpdates|offline system updates]]. Its description suggests that 'offline' updates - updates performed across a system reboot - are now the default method for graphical updating in Fedora 18 and later, at least when using GNOME. However, the feature's implementation is still somewhat incomplete: GNOME will still pop up notifications of available updates, and if you click on these notifications as you are encouraged to do, the 'online' update process (updates installed within the running system) will be launched.
  
 
This is not a major bug - the online update system still works, and while there are valid reasons why offline updates are slightly more robust, online updates are what Fedora used from Fedora Core 1 through Fedora 17 so there is no pressing reason to believe the use of online updates will be a disaster. Both mechanisms perform as intended in Fedora 19, and you can use the online update mechanism as safely in Fedora 19 as you ever did in a previous Fedora release. This note is included simply to explain the situation, in case you are confused as to what's going on.
 
This is not a major bug - the online update system still works, and while there are valid reasons why offline updates are slightly more robust, online updates are what Fedora used from Fedora Core 1 through Fedora 17 so there is no pressing reason to believe the use of online updates will be a disaster. Both mechanisms perform as intended in Fedora 19, and you can use the online update mechanism as safely in Fedora 19 as you ever did in a previous Fedora release. This note is included simply to explain the situation, in case you are confused as to what's going on.
  
 
If you want to trigger an offline update, use the "Install Updates and Restart" entry on the User menu.
 
If you want to trigger an offline update, use the "Install Updates and Restart" entry on the User menu.
 +
 +
{{Anchor|biosdevname-vs-systemd}}
 +
=== ''biosdevname'' rather than systemd network interface names used by default ===
 +
<small>[[#biosdevname-vs-systemd|link to this item]] - [[rhbug:965718|Bugzilla: #965718]]</small>
 +
 +
The [[Features/SystemdPredictableNetworkInterfaceNames|Systemd predictable network interface names]] Feature of Fedora 19 is supposed to mean that network interface names will be set by systemd/udev following the upstream [http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ feature], rather than by the ''biosdevname'' tool which was introduced as part of the Fedora 15 [[Features/ConsistentNetworkDeviceNaming|consistent network device naming]] feature. The two systems have similar goals, but use different naming schemes.
 +
 +
In practice, as things have turned out with the final Fedora 19, the Fedora installer still uses ''biosdevname'', and writes the interface names produced by biosdevname into the configuration files for each interface. The {{package|biosdevname}} package is also still installed by default. We therefore expect that Fedora 19 will in fact mostly behave as if biosdevname is still the system in use, both on new installations and upgrades.
 +
 +
This should not cause any problems, but we felt the issue was worth noting in case the question arose as to why the new feature does not seem to be working, or in case certain corner cases appear in which the two systems conflict in some way.
  
 
{{Anchor|mate-caja-desktop}}
 
{{Anchor|mate-caja-desktop}}
 +
 
=== Several x-caja-desktop windows pop up on login to MATE desktop ===
 
=== Several x-caja-desktop windows pop up on login to MATE desktop ===
 
<small>[[#mate-caja-desktop|link to this item]] - [[rhbug:886029|Bugzilla: #886029]]</small>
 
<small>[[#mate-caja-desktop|link to this item]] - [[rhbug:886029|Bugzilla: #886029]]</small>
  
Sometimes (the bug is due to a race condition and hence unpredictable), on boot of the Fedora 19 Beta MATE live image or first login with a user account to the MATE desktop, several useless windows labelled ''x-caja-desktop'' will open up on the desktop.
+
Sometimes (the bug is due to a race condition and hence unpredictable), on boot of the Fedora 19 MATE live image or first login with a user account to the MATE desktop, several useless windows labelled ''x-caja-desktop'' will open up on the desktop.
 +
 
 +
The bug has no further consequences and it is quite safe to simply close the windows and continue using the system. The MATE maintainer is currently working to resolve this issue with updated packages.
 +
 
 +
{{Anchor|lxde-low-battery}}
 +
=== Low battery warnings not showing up in LXDE ===
 +
<small>[[#lxde-low-battery|link to this item]] - [[rhbug:975826|Bugzilla: #975826]]</small>
 +
 
 +
Fedora 19's original LXDE build relied on the {{command|xmessage}} tool for printing 'low battery' notifications. However, this tool is not included by default in an LXDE installation (or the LXDE live image). This means that these notifications will not show up unless you manually install the {{package|xorg-x11-apps}} package.
 +
 
 +
An updated [https://admin.fedoraproject.org/updates/FEDORA-2013-12350/lxpanel-0.5.12-3.fc19 lxpanel] package has been submitted to the updates-testing repository for testing. Users experiencing this problem are encouraged to test this update and [https://admin.fedoraproject.org/updates/FEDORA-2013-12350/lxpanel-0.5.12-3.fc19 report to Bodhi] whether it solves the problem. To test the update, run this command:
 +
<pre>su -c 'yum --enablerepo=updates-testing update lxpanel'</pre>
 +
 
 +
This update will not solve the problem with live images. If it is important to you that you get low battery notifications when running the LXDE live image, please manually install the {{package|xorg-x11-apps}} package.
 +
 
 +
{{Anchor|vbox-32-guest}}
 +
=== X crashes on Fedora 19 32-bit VirtualBox guests with Guest Additions installed ===
 +
<small>[[#vbox-32-guest|link to this item]] - [[rhbug:972095|Bugzilla: #972095]]</small>
 +
 
 +
Several testers have reported that if you install a 32-bit edition of Fedora 19 to a VirtualBox virtual machine and install the Guest Additions, X will no longer start up successfully.
 +
 
 +
Please note that Fedora does not officially support or recommend the use of the VirtualBox platform. A fix for this issue is unlikely to come from the Fedora project, but the VirtualBox developers may address it in future releases. To work around the issue, do not install the Guest Additions, or install a 64-bit edition of Fedora 19 rather than a 32-bit edition.
 +
 
 +
{{Anchor|php-mysqlnd}}
 +
=== PHP cannot connect to MariaDB/MySQL using old password ===
 +
<small>[[#php-mysqlnd|link to this item]] - [[rhbug:991070|Bugzilla: #991070]]</small>
 +
 
 +
When a MariaDB/MySQL database contains old users, created with old unsecure passwords, PHP (using [http://php.net/mysqlnd mysqlnd] driver) won't be able to connect:
 +
 
 +
<pre>PHP Warning:  mysqli::mysqli(): (HY000/2000): mysqlnd cannot connect to MySQL 4.1+
 +
using the old insecure authentication. Please use an administration tool to reset your
 +
password with the command SET PASSWORD = PASSWORD('your_existing_password'). This will
 +
store a new, and more secure, hash value in mysql.user. If this user is used in other
 +
scripts executed by PHP 5.2 or earlier you might need to remove the old-passwords flag
 +
from your my.cnf file ...</pre>
 +
 
 +
Which means, you MUST remove old_password=1 from /etc/my.cnf, restart MariaDB/MySQL service and set a new password for each user.
 +
 
 +
Old passwords are stored as 16 char hash (in mysql.user table), while new passwords are stored as 41 char hash (starting with a *).
  
The bug has no further consequences and it is quite safe to simply close the windows and continue using the system.
+
{{Anchor|remmina}}
 +
=== Remmina - Don't permit selection of share folder on KDE Desktop Environment ===
 +
<small>[[#remmina|link to this item]] - [[rhbug:997592|Bugzilla: #997592]]</small>
  
This bug should be resolved for the final release of Fedora 19.
+
After you start Remmina when you tried to select a local folder to share that folder on your rdp connection, the program closes every time.

Revision as of 17:03, 7 October 2013

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

Contents

Release Notes

Read the F19_release_announcement and the Fedora 19 release notes for specific information about changes in Fedora 19 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. Please follow the style and guidelines explained in the comments in the page source.
  • Or, add the CommonBugs keyword to the bug report. Someone from the QA team will then inspect the issue to determine whether the bug should be listed as a common bug. To expedite your request, please add a comment to the bug that includes
    1. a summary of the problem
    2. any known workarounds
    3. an assessment on the impact to Fedora users

For reference, you can query Bugzilla for bugs tagged CommonBugs:

  • CommonBugs? (bugs with CommonBugs keyword, but do not yet have a link to this page)
  • CommonBugs+(bugs with CommonBugs keyword and contain a link to this page)


Installation issues

Installer screens sometimes do not appear at full screen width

link to this item - Bugzilla: #869364

Sometimes when you visit a screen in the Fedora 19 Beta installer (a 'spoke') more than once, it will display incorrectly - it will be squeezed into an area less than the full width of the screen, and sometimes less than the full height also. We have been attempting to fix this bug for a while but it is a difficult one to pin down.

Usually you can still use the screen in the reduced size version, though it may look very strange. If you get completely stuck, though, you will unfortunately be required to reboot and restart the installation process. We apologize for any inconvenience.

Sadly, we were unable to resolve this issue ahead of the final release of Fedora 19. We were unable to diagnose the cause of the issue, so without any idea how long it might take to fix or how difficult the fix may be, we could not consider adjusting the release schedule. We will attempt to make sure the issue is fixed for the release of Fedora 20.

Apple EFI Macs: EFI install alongside existing EFI installed OS (including OS X) results in you have not created a bootloader stage1 target device error

link to this item - Bugzilla: #1010495

If you try to do a native UEFI install of Fedora 19 alongside a native UEFI install of OS X and re-use the existing EFI system partition, the installer will incorrectly consider the existing EFI system partition as invalid and report that you have not created a bootloader stage1 target device. Unfortunately, the Fedora automatic partitioning algorithm will actually attempt to re-use the EFI system partition, and so you will run into this bug in any Fedora 19 installation attempt where you use the automatic partitioning algorithm and do not choose to delete the existing EFI system partition.

Practically speaking, there are a few different approaches to dealing with this problem. If you do not mind losing your OS X installation, you can simply choose to delete it (including the EFI system partition), and let Fedora occupy the rest of the disk. Fedora should create a new EFI system partition and install successfully.

If you wish to preserve your OS X installation, install Fedora 19 Final, and dual boot, you must use the installer's 'custom partitioning' path. Make sure to leave the existing EFI system partition intact, but do not set a mount point for it. Do not use the Create partitions for me button. Instead, manually create a new EFI system partition, and set it to be mounted at /boot/efi. Manually create other partitions as usual. Complete custom partitioning, and your installation should proceed successfully. See the Installation Guide for general instructions on the partitioning process, if necessary.

You could also try installing Fedora 18 or Fedora 19 Beta. These should allow you to use automatic partitioning to install alongside OS X, assuming you do not run into any other bugs they may have contained. You could then upgrade to Fedora 19 Final - with FedUp from Fedora 18, or yum from Fedora 19 Beta. You will still wind up with two EFI system partitions in this case.

We are investigating the possibility of producing an updates image to make it easier to deal with this bug. We apologize for any inconvenience it causes you.

Intel firmware RAID-1+ sets not visible in live installer

link to this item - Bugzilla: #975649

Fedora 19 testing indicates that Intel firmware RAID sets at level 1 and higher (so not level 0) fail to appear as potential target devices in the installer when running from a live image. They appear as normal when installing from a non-live image (the DVD or network installer).

This issue appears to be caused by mdmon failing to start or being killed during the live image start up. It may be possible to work around it by starting mdmon manually prior to running the installer. The other 'workaround' for the issue is simply to install from the DVD or network install image rather than a live image if you wish to install to an affected firmware RAID device.

Problems with Installation Source and Installation Destination spokes when installing from a partially complete kickstart

link to this item - Bugzilla: #972265 - Bugzilla: #972266

If you attempt to install Fedora 19 using a partially-complete kickstart - in particular, a kickstart which specifies a package set but no installation source or destination - you will find that the interactive process for setting those options behaves strangely. On the Installation Source spoke, you may not be able to use the default Closest mirror option. If you are affected by this problem, you can manually enter the URL of the Fedora 19 mirror list, and check the This URL refers to a mirror list. box. The URLs for the 64-bit and 32-bit mirror lists are https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-19&arch=x86_64 and https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-19&arch=i386 respectively.

The Installation Destination spoke appears to require you to complete it multiple times to complete configuration: each time it will set another element of the configuration. Even after doing this, you may find a bootloader target disk is not selected. To set one, first enter the Full disk summary and bootloader... screen and select not to install a bootloader, and complete the spoke once again. Then complete the spoke one more time, this time selecting the correct target disk for the bootloader, and the configuration should now be complete.

As these issues take some effort to work around, it may be a better idea simply to use a complete kickstart, or at least one which specifies an installation source and destination. The Anaconda/Kickstart page should help you with the required syntax.

Storage devices without media show as 0-byte partitions and can crash the installer

link to this item - Bugzilla: #960794

Several testers have reported an unusual case with certain storage devices in the Fedora 19 installer. Some devices report themselves to the kernel as drives with 'no media present'. Identified cases so far include an Android-based phone when plugged into the system but not set in USB storage mode, and a few types of card reader when no card is inserted.

If such a device is present during installation, it will not be shown in the 'Installation Destination' screen's list of disks, but if you enter the custom partitioning mode, the device will appear as a single 0-byte partition. If you attempt to manipulate this partition in any way, the installer may crash with an error AttributeError: 'NoneType' object has no attribute 'type' .

There are two obvious workarounds for this issue. In most cases it should be possible simply to disconnect the offending device: there is no need to connect your phone or external card reader during installation. If the offending device is not easily removable, you can simply leave the bogus 0-byte 'partition' entirely alone, and your installation should proceed successfully.

Network installation with Authoring and Publishing group selected fails

link to this item - Bugzilla: #959696

Due to an unmarked conflict between two texlive-related packages (Package-x-generic-16.pnght and Package-x-generic-16.pngtexlive-tex4ht-bin), Fedora 19 installations with the Authoring and Publishing package group selected (and possibly with the Font design group selected) will fail.

The offending packages (and groups) are not present on the Fedora 19 DVD, so the bug is not present there. The issue affects only network installs. It will be resolved once the conflict between the two packages is fixed with an update, so long as you enable the updates repository in your installation.

UEFI install to ms-dos ('MBR') labelled disk fails with unclear errors

link to this item - Bugzilla: #978430

As veterans of the Fedora 16 release may remember, there are two commonly-used 'disk label' or 'partition table' formats known as 'gpt' and 'ms-dos' or 'mbr'.

Fedora 19's installer effectively requires that native UEFI installations be performed to a disk with the 'gpt' format (in fact, it requires that the EFI system partition be on such a disk). In fact, this is not a requirement of the official UEFI specification: it leaves open the possibility of an EFI system partition residing on an ms-dos labelled disk, though it is possible that some firmwares may not support such a configuration.

In any case, if you attempt to do a native UEFI install of Fedora 19 such that the EFI system partition will reside on an ms-dos labelled disk, this will fail. You are likely get an error of the form you have not created a bootloader stage1 target device, possibly with the note that the volume backing the EFI system partition must have one of the following disklabel types: gpt. You may also observe unusual behaviour on the Reclaim space screen, if you use it in your installation attempt. Note that you can encounter this error message even when installing to a gpt-labelled disk if you use custom partitioning and fail to correctly configure an EFI system partition: when doing a UEFI install you must include a partition of the 'EFI system partition' type, and mount it at the path /boot/efi.

We have found that there appear to be some systems 'in the wild' with existing native UEFI operating system installations to an ms-dos labelled drive. Unfortunately, this bug means you cannot install Fedora 19 in a dual-boot configuration to the same drive as such an operating system. You would need to install to a second drive in order to dual boot.

If you wish to do a native UEFI installation of Fedora 19, it must be to a gpt-labelled disk, or you must configure your installation such that all existing partitions on the disk on which the EFI system partition will reside will be deleted (doing this will cause the installer to reformat it with a gpt disk label). Note that it is not possible to change the label format of a disk in a non-destructive way: it requires a complete re-format.

For Fedora 20, we intend to revise the installer to handle this situation in a better way. We apologize for any inconvenience it causes.

As a workaround, you can append "noefi" to the kernel boot options in the GRUB menu.

As for some laptops, there is an option in BIOS to set make it use Legacy mode instead of uefi, which makes it accept disks that aren't gpt-labelled (i.e some Lenovo models).

USB stick from which install is running appears as a possible install target

link to this item - Bugzilla: #874381

In some circumstances, when you are installing Fedora 19 from a USB stick, the stick itself will show up as a possible 'target disk' on the Installation Destination screen where you choose which disk(s) to install onto. This is not intended to happen. It is not possible to install to the USB stick from which the installation is running: if you attempt to do this, the installation will fail. Naturally, therefore, we recommend you simply avoid selecting the stick on this screen.

Multipath devices disappear from Installation Destination screen second time through

link to this item - Bugzilla: #955664

If for any reason you visit the Installation Destination screen more than once during a Fedora 19 installation to a system with available multipath storage device(s), the multipath device(s) will show in the device list the first time through, but not on subsequent visits. You will still be able to find it by using the Add a disk... button, though, so you can continue with your installation.

Hidden extlinux install option works only with network install

link to this item - Bugzilla: #970184

The feature Features/SyslinuxOption provides the Fedora 19 installer with a hidden (mostly undocumented) boot parameter extlinux. If you pass this parameter, the installer will attempt to install the extlinux bootloader instead of grub2. However, this obviously requires extlinux to be available to the installer. During live and DVD-sourced installations, extlinux is not available, and any attempt to install with this parameter will fail with the error No such file or directory: '/mnt/sysimage/boot/extlinux/extlinux.conf'. The parameter will work correctly when performing a network installation. So, if you intend to use this hidden feature of Fedora 19, use the non-live installer, and ensure network repositories (or at least some repository containing the Package-x-generic-16.pngextlinux package) is available to the installer.

Reboot after non-live install often delayed for a minute or so

link to this item - Bugzilla: #974383

After successfully completing an installation of Fedora 19 from the DVD or network installation media, you will see a button to Reboot. Sometimes, after you click this, the system will appear to hang at a console. In fact, the reboot process is just delayed; if you leave it for a minute or two, the system will reboot correctly. We do recommend you wait it out to avoid any possibility of filesystem damage, rather than forcing a reset.

'Selected' state for disks is indicated with a small and easily missed check mark

link to this item - Bugzilla: #967682

On the installer screen where you choose which disks will be used for Fedora 19 installation, disks that are selected as installation targets are marked with a fairly small black check mark in the lower right hand corner; disks that are not selected do not have the check mark.

This has been changed since Fedora 18, when disks that were selected were highlighted in blue, and now the blue highlight simply means the UI element is selected. So if you click on a disk that was previously selected as an install target, then you have just de-selected it - so the check mark goes away - but the UI element is active, so it is highlighted in blue.

Add to this that if you only have a single hard disk it will be pre-selected as an install target when you enter the page, and it has become clear that this design is confusing people. Many users have entered the screen and clicked to 'select' their single disk - in fact de-selecting it, because it was already selected, but not noticing the mistake.

Please be aware that the check mark not the blue highlight indicates the disks selected as targets. We will endeavour to improve this interface before the release of Fedora 20.

Bootloader password is required on each boot

link to this item - Bugzilla: #840160

If you set a bootloader password during installation of Fedora 19 (which is only possible when doing a kickstart-based install), the password will be required at each boot of the system. This is a change in behaviour from Fedora 15 and earlier, where the password was required only to change settings from within the bootloader.

Lawrence Lowe suggests that the --unrestricted parameter can be added to menuentry lines in the grub config file to make them available without the password being entered.

Non-GNOME initial setup utility does not warn of failure to create a user account

link to this item - Bugzilla: #965797

In Fedora 19, the new initial-setup utility (shown after a graphical install with any desktop other than GNOME if you do not create a user account during installation) does not present any kind of warning if you leave it without having created a user account. Thus it is relatively easy to arrive at a graphical login screen without any user accounts available.

The old utility would allow you to skip user account creation, but required you to click through a warning in order to do so, to ensure no-one did it inadvertently. This is also how initial-setup should behave.

We have tested that the desktops for which the new tool is used - KDE, Xfce, LXDE, MATE, and Sugar - all allow login as root, so this bug should not present any major roadblocks to accessing the installed system. However, if you do install without creating a user account, we strongly advise that you log in as root only in order to create a user account, and then immediately log out and in future always log in as the user account. Using a graphical desktop with root privileges can increase your vulnerability to remote attack, to simple mistakes having severe consequences, and to bugs caused by software not expecting to be run with root privileges.

This issue does not affect the GNOME initial setup utility: in fact, that utility will not allow you to skip user account creation at all.

Fedup: upgrade to F19 can't start without rd.luks.uuid/rd.lvm.lv/rd.md.uuid boot args

link to this item - Bugzilla: #974000

The system hangs during the reboot after running the command fedup --network 19 from F18. F17 and F18 would boot without specifying 'rd.luks.uuid' or 'rd.lvm.lv' arguments, but F19 won't.

Under normal circumstances, the installer sets up those arguments for you, but some people who migrated from GRUB to GRUB2 by hand have *dropped* those arguments - which works fine for F17 and F18, but fails for F19.

The recommended fix is to restore the rd.luks.uuid/rd.lvm.lv/etc. arguments from your old grub.cfg. In a pinch, you can add "rd.auto=1" to your boot arguments to make dracut try to automatically set up *every* disk it finds; this isn't recommended for general use though.

Hardware issues

Boot hangs when using NVIDIA discrete graphics on some Thinkpad models (W520, T420)

link to this item - Bugzilla: #752613 Kernel bugzilla: #43054

Multiple testers have reported that various Thinkpad models - including at least the W520 and T420 - that have hybrid Intel/NVIDIA graphics will fail to boot Fedora 19 when using the discrete NVIDIA graphics adapter. Using the onboard Intel adapter, Fedora will boot successfully.

Further testing indicates that this bug is an interaction between several features of these systems and of Fedora: the VT-d advanced virtualization feature, the X2APIC level APIC, and the NVIDIA adapter. If all three of these things are used together, boot fails. If any one is removed from the equation, boot succeeds.

So if you are affected by this bug, you can choose to boot with any two of those things, but not all three together. You can disable the VT-d feature and select which graphics adapter to use through the system firmware. You can disable X2APIC functionality by passing the kernel parameter nox2apic. In this way, you should be able to determine which of the features you want to use.

The kernel developers plan to address this issue in a future kernel update by blacklisting X2APIC functionality on affected systems, when the NVIDIA adapter is in use.

Transition from GDM to desktop fails on systems with old or no 3D graphics adapters

link to this item - Bugzilla: #955779

Several users have reported a problem with logging in from GDM on systems with an old, or no, 3D graphics adapter (including virtual machines). This seems to affect some virtual setups, and older graphics adapters that are blacklisted from being used for 3D acceleration of GNOME Shell: pre-i915 Intel adapters, pre-R300 (Radeon 9500) Radeon adapters, and pre-NV30 (GeForce FX) NVIDIA adapters. The effect of the bug is that, after entering a username and password, the screen remains blank grey, never transitioning to the desktop. Some testers do not seem to be affected by the problem; we are yet to pin down precisely what is causing it.

If you are affected by the problem, the simplest solution is to switch to a different login manager. The best options are likely KDM and LightDM, as they have received the most testing with the widest range of desktops besides GDM. To switch to kdm or lightdm, simply install the Package-x-generic-16.pngkdm or Package-x-generic-16.pnglightdm package and run su -c 'systemctl enable kdm.service' or su -c 'systemctl enable lightdm.service' then su -c 'systemctl disable gdm.service', then reboot. You should see the new login manager, and you should be able to log in successfully with it.

Software issues

System fails to start correctly (due to qxl driver crash) when booting Fedora 19 Beta as a virtual guest on a RHEL 6 or 7 host

link to this item - Bugzilla: #952666

It has been reported that the Package-x-generic-16.pngxorg-x11-drv-qxl driver in Fedora 19 crashes during X startup when trying to boot a Fedora 19 Beta image in a virtual guest configured with qxl/SPICE graphics on a Red Hat Enterprise Linux 6.4 or 7 (pre-release) host. This likely affects earlier versions of RHEL 6, clones of RHEL 6 such as CentOS, and possibly very old (and unsupported) Fedora releases as well.

To work around this issue, configure your guest to use cirrus/VNC or vga/VNC instead of qxl/SPICE. This is really a bug on the host side rather than the guest side, and updates for RHEL should be made available soon after Fedora 19's release that should resolve this problem.

X may crash when using the qxl driver in a Fedora 19 virtual machine on a Fedora 19 host

link to this item - Bugzilla: #978612

Some testers have reported X.org crashes in Fedora 19 KVM virtual machines running on Fedora 19 hosts when using the qxl graphics driver. The issue seems to be triggered by a resolution change in the guest, but some testers have observed it happening during an installation from the KDE live image: we are not yet sure why. This issue does not seem to affect all testers, and seems to affect some worse than others.

If you find yourself suffering from this issue, there are a couple of possible workarounds. You can configure your virtual machine to use the cirrus video adapter rather than qxl and the VNC display method rather than SPICE (though this may cause issues with GNOME Shell), or you can use the Basic graphics mode option from the Fedora 19 bootloader menu (or simply pass the parameter nomodeset on the kernel command line).

An updated xorg-x11-drv-qxl package 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:

su -c 'yum --enablerepo=updates-testing update xorg-x11-drv-qxl'
and then reboot the guest system. Of course, this will not be useful for the initial installation of a Fedora 19 virtual machine: for that phase, try one of the workarounds mentioned above.

Crash when GNOME introductory video attempts to play

link to this item - Bugzilla: #962092

When a user logs into GNOME 3.8 (as included in Fedora 19) for the first time, a short introductory video is intended to play. Fedora 19 testing has indicated that, sometimes, there is a crash, and the video fails to play. On first login to a user account, you may notice a crash report for the /usr/libexec/gnome-initial-setup-player process. Aside from the crash report and the failure of the video to play, this bug appears to have no further consequences. We have not yet identified the circumstances under which the crash occurs.

"Updates available" notification runs online updater

link to this item - Bugzilla: #863592

Fedora 18 introduced a feature called offline system updates. Its description suggests that 'offline' updates - updates performed across a system reboot - are now the default method for graphical updating in Fedora 18 and later, at least when using GNOME. However, the feature's implementation is still somewhat incomplete: GNOME will still pop up notifications of available updates, and if you click on these notifications as you are encouraged to do, the 'online' update process (updates installed within the running system) will be launched.

This is not a major bug - the online update system still works, and while there are valid reasons why offline updates are slightly more robust, online updates are what Fedora used from Fedora Core 1 through Fedora 17 so there is no pressing reason to believe the use of online updates will be a disaster. Both mechanisms perform as intended in Fedora 19, and you can use the online update mechanism as safely in Fedora 19 as you ever did in a previous Fedora release. This note is included simply to explain the situation, in case you are confused as to what's going on.

If you want to trigger an offline update, use the "Install Updates and Restart" entry on the User menu.

biosdevname rather than systemd network interface names used by default

link to this item - Bugzilla: #965718

The Systemd predictable network interface names Feature of Fedora 19 is supposed to mean that network interface names will be set by systemd/udev following the upstream feature, rather than by the biosdevname tool which was introduced as part of the Fedora 15 consistent network device naming feature. The two systems have similar goals, but use different naming schemes.

In practice, as things have turned out with the final Fedora 19, the Fedora installer still uses biosdevname, and writes the interface names produced by biosdevname into the configuration files for each interface. The Package-x-generic-16.pngbiosdevname package is also still installed by default. We therefore expect that Fedora 19 will in fact mostly behave as if biosdevname is still the system in use, both on new installations and upgrades.

This should not cause any problems, but we felt the issue was worth noting in case the question arose as to why the new feature does not seem to be working, or in case certain corner cases appear in which the two systems conflict in some way.

Several x-caja-desktop windows pop up on login to MATE desktop

link to this item - Bugzilla: #886029

Sometimes (the bug is due to a race condition and hence unpredictable), on boot of the Fedora 19 MATE live image or first login with a user account to the MATE desktop, several useless windows labelled x-caja-desktop will open up on the desktop.

The bug has no further consequences and it is quite safe to simply close the windows and continue using the system. The MATE maintainer is currently working to resolve this issue with updated packages.

Low battery warnings not showing up in LXDE

link to this item - Bugzilla: #975826

Fedora 19's original LXDE build relied on the xmessage tool for printing 'low battery' notifications. However, this tool is not included by default in an LXDE installation (or the LXDE live image). This means that these notifications will not show up unless you manually install the Package-x-generic-16.pngxorg-x11-apps package.

An updated lxpanel package 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:

su -c 'yum --enablerepo=updates-testing update lxpanel'

This update will not solve the problem with live images. If it is important to you that you get low battery notifications when running the LXDE live image, please manually install the Package-x-generic-16.pngxorg-x11-apps package.

X crashes on Fedora 19 32-bit VirtualBox guests with Guest Additions installed

link to this item - Bugzilla: #972095

Several testers have reported that if you install a 32-bit edition of Fedora 19 to a VirtualBox virtual machine and install the Guest Additions, X will no longer start up successfully.

Please note that Fedora does not officially support or recommend the use of the VirtualBox platform. A fix for this issue is unlikely to come from the Fedora project, but the VirtualBox developers may address it in future releases. To work around the issue, do not install the Guest Additions, or install a 64-bit edition of Fedora 19 rather than a 32-bit edition.

PHP cannot connect to MariaDB/MySQL using old password

link to this item - Bugzilla: #991070

When a MariaDB/MySQL database contains old users, created with old unsecure passwords, PHP (using mysqlnd driver) won't be able to connect:

PHP Warning:  mysqli::mysqli(): (HY000/2000): mysqlnd cannot connect to MySQL 4.1+
using the old insecure authentication. Please use an administration tool to reset your
password with the command SET PASSWORD = PASSWORD('your_existing_password'). This will
store a new, and more secure, hash value in mysql.user. If this user is used in other
scripts executed by PHP 5.2 or earlier you might need to remove the old-passwords flag
from your my.cnf file ...

Which means, you MUST remove old_password=1 from /etc/my.cnf, restart MariaDB/MySQL service and set a new password for each user.

Old passwords are stored as 16 char hash (in mysql.user table), while new passwords are stored as 41 char hash (starting with a *).

Remmina - Don't permit selection of share folder on KDE Desktop Environment

link to this item - Bugzilla: #997592

After you start Remmina when you tried to select a local folder to share that folder on your rdp connection, the program closes every time.