Common F30 bugs: Difference between revisions

Latest revision as of 00:29, 17 March 2020

In other languages: English (en) português (pt) [edit]

This page documents common bugs in Fedora 30 and, if available, fixes or workarounds for these problems. If you find your problem in this page, please do not file a bug for it, unless otherwise instructed. Where appropriate, a reference to the current bug(s) in Bugzilla is included.

Release Notes

Read the Fedora 30 release announcement and the Fedora 30 release notes for specific information about changes in Fedora 30 and other general information.

My bug is not listed

Not every bug is listed in this page, but Bugzilla should be a comprehensive database of known bugs. This page is a sampling of the bugs most commonly discussed on our mailing lists and forums.

To see if your bug has already been reported, you can search Bugzilla. If it has not yet been reported, we encourage you to do so to help improve Fedora for yourself and others. A guide to Bugs and feature requests has been prepared to assist you.

If you believe an already-reported bug report should be added to this page because it is commonly encountered, you can:

Add it yourself, if you have wiki access. Common bugs instructions provides guidance on how to add an entry to the page correctly, but the most important thing is to make sure that the bug is listed - don't worry if you don't get the format quite right, we can clean it up later.
Or, add the CommonBugs keyword to the bug report. Someone from the QA team will then inspect the issue to determine whether the bug should be listed as a common bug. To expedite your request, please add a comment to the bug that includes
1. a summary of the problem
2. any known workarounds
3. an assessment on the impact to Fedora users

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

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

Core system issues

DNF logs very verbosely by default, leads to large log files

link to this item - Bugzilla: #1355764

By default, the DNF included with Fedora 30 does some very verbose logging. Especially the file /var/log/dnf.librepo.log contains very detailed logging of mirror selection and file download operations. Some operations, such as a system upgrade or reposync, can potentially cause multiple gigabytes of messages to be written to this log file. The DNF log files are configured for rotation, so they will be compressed and expired weekly so long as logrotate is installed, but this can be insufficient when a single operation can cause the files to grow very large.

If the DNF log files are filling up your disk and you need a solution urgently, it is safe to simply remove the log files (after copying them elsewhere if you need them for reference), this will not break anything. A future libdnf update is planned to reduce the dnf.librepo.log verbosity. Until then, if this is an ongoing problem for you, you can work around it by redirecting the log output to /dev/null - see this bug comment for one way to do that.

Multiple services fail to start with "status=226/NAMESPACE" in unusual cases

link to this item - Bugzilla: #1663040

Fedora 30's SELinux policy prevents systemd services with PrivateDevices=true from starting if some key mount points are not correctly labelled (/dev, /proc, /sys etc.) In most cases you should not run into this issue, but some users who have transferred existing installations to other systems or deployed Fedora in unusual ways may do so (for instance, Hans de Goede ran into this after transferring a Fedora system from one disk to another using cp -pr, which does not preserve these labels).

A 'normal' relabel will not solve this problem as the mount points have something mounted on them by the time it runs, and the relabelling is applied to the mounts, not the underlying mount points. To relabel the mount points, you must boot a live or rescue image, mount the installed system's root filesystem, change into the mounted directory, and run:

chcon -t device_t dev
chcon -t home_root_t home
chcon -t root_t proc sys
chcon -t var_run_t run

Then unmount the mounted directory and reboot to the installed system, and now things should be fixed.

Encrypted system does not resume from hibernation correctly if you wait more than 90 seconds to input encryption password

link to this item - Bugzilla: #1705522

If you install Fedora 30 with the system partitions encrypted, and then use the hibernate (suspend-to-disk) feature, you will be prompted to input the encryption password during system resume. If you wait longer than 90 seconds before inputting the password, the system will not resume from hibernation correctly - instead a fresh boot will be performed and your previous state will be lost.

There is currently no known workaround for this problem besides simply making sure you input the password soon enough to avoid it happening.

Workstation (GNOME) issues

Workstation shutdown menu does not prompt you to install prepared updates

link to this item - Bugzilla: #1805265

In Fedora Workstation, the shutdown/reboot menu is intended to alert you if system updates are prepared for installation and offer you the option of installing them before shutting down. This worked as intended in Fedora 28 and earlier. However, in Fedora 29 and later, a change to suspend PackageKit when it is not needed broke this feature: the notification almost never appears in the shutdown/reboot menu (it will only pop up if you happen to try and shut down very shortly after actively using PackageKit somehow).

There is no known practical workaround for this issue at present.

Upgrade issues

GRUB boot menu is not populated after an upgrade

link to this item - Bugzilla: #1652806

If you have a legacy BIOS installation (i.e. not UEFI), it is possible that after the upgrade process the GRUB bootloader will not populate the boot menu, and instead displays a GRUB prompt. This happens on systems that were originally installed using Fedora 20 or older.

This happens because the GRUB core and modules in legacy BIOS are never updated unless the grub2-install command is executed. In Fedora 30 the default GRUB configuration is changed to use BootLoaderSpec-style files by default, and the blscfg module is updated when the grub2-pc-modules package is upgraded. However, this module is only compatible with versions of the GRUB core up to Fedora 21.

If GRUB has not been updated since Fedora 20 or earlier, it is recommended to execute the grub2-install command before doing a system upgrade. This should not affect legacy BIOS installations since Fedora 21. UEFI installs are unaffected because during upgrade the GRUB EFI image, containing the core and modules, is updated.

If you hit this issue, the old GRUB configuration is stored in /boot/grub2/grub.cfg.rpmsave. So the system can be recovered by executing the following from the GRUB prompt:

grub> configfile /grub2/grub.cfg.rpmsave

And then execute the grub2-install /dev/X command (where X is the boot device, i.e sda) to update the GRUB core and the modules to the latest version installed by the grub2-pc-modules package.

Conflicts between fedora-release packages on upgrade

link to this item - Bugzilla: #1649921

When attempting to upgrade to Fedora 30, you may see conflicts between multiple fedora-release subpackages. If this happens, we recommend you remove one of the conflicting packages to unblock the upgrade. Leave installed the package that most closely matches how you want the system to identify itself - the one that most closely matches your primary use of the system.

Hardware issues

Broadcom wireless adapters using proprietary broadcom-wl driver do not work reliably

link to this item - Bugzilla: #1703745

Multiple users of wireless network adapters supported by the proprietary broadcom-wl driver have reported that it does not work reliably in Fedora 30. PLEASE NOTE that Fedora does not provide or support this proprietary driver; we are providing this note only as a courtesy as we are aware that many people acquire the driver from a third party and use it on Fedora.

The problem seems to be that a new feature in wpa_supplicant that was enabled in Fedora 30 confuses the broadcom-wl driver. As the driver is not open source we cannot provide a fixed version of it, and we will not disable a useful wpa-supplicant feature just to make a proprietary driver work correctly.

To help out folks with affected devices, Davide Caratti is providing unofficial rebuilds of wpa_supplicant with the feature in question disabled. You can enable his COPR repository by running sudo dnf copr enable dcaratti/wpa_supplicant, and then updating your system should install his rebuild, if it is currently up-to-date compared to the version in the official repositories. With this rebuild installed, the wireless adapter should work reliably.

Other software issues

Conflicts between fedora-release packages when installing package groups

link to this item - Bugzilla: #1649921

When trying to install package groups, you may run into a conflict between different fedora-release subpackages. This can happen for example if you install the server-product package group or several of the desktop groups after initial system installation. This error would look something like this:

Error: 
 Problem: problem with installed package fedora-release-workstation-30-0.24.noarch
  - package fedora-release-workstation-30-0.24.noarch conflicts with system-release provided by fedora-release-matecompiz-30-0.25.noarch
  - package fedora-release-matecompiz-30-0.25.noarch conflicts with system-release provided by fedora-release-workstation-30-0.24.noarch
  - package fedora-release-workstation-30-0.25.noarch conflicts with system-release provided by fedora-release-matecompiz-30-0.25.noarch
  - package fedora-release-matecompiz-30-0.25.noarch conflicts with system-release provided by fedora-release-workstation-30-0.25.noarch
  - conflicting requests
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages)

But with the package names depending on the package you already have installed, and the package coming in with the group you are trying to install.

You have four choices for how to resolve this issue. In each case we use the package names from the example above; obviously you should modify these to match the package names that are actually involved in the conflict on your system.

RECOMMENDED Pass --excludepkg fedora-release-matecompiz to DNF. This will remove just this package from the transaction and allow the rest of the group to be resolved normally. This option will retain your system's "identity" to what it was from initial installation.

Pass --excludepkg fedora-release-workstation to DNF. This will remove just this package from the transaction and allow the rest of the group to be resolved normally. This option will change your system identity such that it will now report as a MATE Compiz system rather than a Workstation one.

Pass --skip-broken. This is similar to passing --excludepkg fedora-release-matecompiz except that it will also skip any other potential conflicts which may result in an incomplete group install. Make sure to carefully examine the transaction summary before proceeding. This option will retain your system's "identity" to what it was from initial installation.

Pass --allowerasing. This is similar to passing --excludepkg fedora-release-workstation except that it may also result in replacing other packages on your system unexpectedly. Make sure to carefully examine the transaction summary before proceeding. This option will change your system identity such that it will now report as a MATE Compiz system rather than a Workstation one.

Problems trying to install Eclipse, or upgrade a system with Eclipse installed

link to this item - Bugzilla: #1692089

Multiple users have reported that attempting to install Eclipse and/or related packages, or to upgrade a system with Eclipse installed to Fedora 30, fails with various dependency errors. This appears to be caused by mismatches between packages in some modules and packages in the non-modular repositories. The relevant packagers are working to investigate and resolve these issues as soon as possible. Please follow the bug report for specific details and possible workarounds.

repoview package cannot be installed

link to this item - Bugzilla: #1703668

The repoview package in Fedora 30 is not installable. This is because one of its dependencies (python2-kid) was retired due to lack of maintenance, and left out of Fedora 30.

As the dependency is essential (repoview does nothing useful without it) and the package is 'baked into' the frozen release tree, we cannot solve this except by reviving python2-kid. If this does not happen, the package will remain available but not installable. We apologize for the inconvenience.

Resolved issues

Upgrading bcache-based systems to Fedora 30 may result in severe storage corruption

link to this item - Bugzilla: #1708315

Earlier Fedora 30 kernels may severely corrupt system storage on systems that use bcache. To mitigate, you could disable (detach) cache devices before upgrading to Fedora 30.

This issue was been fixed in kernel version 5.1.12. Any upgrade to Fedora 30 performed presently should receive a kernel version later than this and should therefore not be affected by this bug.

@@ Line 1: / Line 1: @@
 <!--
-This header (down to the first "Issues" section below) is generated by '''SUBSTITUTING''' [[Template:Common_bugs_header_prerelease]] at the time of page creation: <nowiki>{{subst:Common_bugs_header_prerelease}}</nowiki>. Please do this rather than copy/pasting. At the time a release goes stable, replace this entire header with a '''SUBSTITUTION''' of [[Template:Common_bugs_header_stable_release]]: <nowiki>{{subst:Common_bugs_header_stable_release}}</nowiki>.If you are making improvements to the header text, please make them also in the [[Template:Common_bugs_header_stable_release]], [[Template:Common_bugs_header_prerelease]] and [[Template:Common_bugs_header_shared]] templates as appropriate, so future pages will contain the same improvements.
+This header (down to the first "Issues" section below) is generated by '''SUBSTITUTING''' [[Template:Common_bugs_header_stable_release]] at the time the release goes stable: <nowiki>{{subst:Common_bugs_header_stable_release<|release=XX>}}</nowiki>. This should replace the entire pre-release header text. Please do this rather than copy/pasting. If you are making improvements to the header text, please make them also in the [[Template:Common_bugs_header_stable_release]], [[Template:Common_bugs_header_prerelease]] and [[Template:Common_bugs_header_shared]] templates as appropriate, so future pages will contain the same improvements.
 -->
 {{autolang|base=yes}}
-This page documents common bugs in Fedora 30 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 30 and, if available, fixes or workarounds for these problems.  If you find your problem in this page, ''please do not file a bug for it, unless otherwise instructed.''  Where appropriate, a reference to the current bug(s) in Bugzilla is included.
-{{admon/note|Pre-release version|Fedora 30 has not yet been released. During this pre-release period, this page will cover known issues in the Fedora 30 pre-releases. Issues that are fixed will be removed from the page once a fix is available (for instance, an issue that affects the Beta but is fixed in the final release will be removed at the time of that release).}}
 == Release Notes ==
-Read the [[F30_Beta_release_announcement]] <!--and the [http://fedorapeople.org/groups/docs/release-notes/en-US/ Fedora {{<includeonly>safesubst:</includeonly>#expr: {{<includeonly>safesubst:</includeonly>CurrentFedoraVersion}} + 1}} Beta Release Notes] <!--[http://docs.fedoraproject.org/en-US/Fedora/{{<includeonly>safesubst:</includeonly>#expr: {{<includeonly>safesubst:</includeonly>CurrentFedoraVersion}} + 1}}/html/Release_Notes/ Fedora {{<includeonly>safesubst:</includeonly>#expr: {{<includeonly>safesubst:</includeonly>CurrentFedoraVersion}} + 1}} release notes]--> for specific information about changes in Fedora 30 and other general information.
+Read the [https://fedoramagazine.org/announcing-fedora-30/ Fedora 30 release announcement] and the [https://docs.fedoraproject.org/en-US/fedora/f30/release-notes/ Fedora 30 release notes] for specific information about changes in Fedora 30 and other general information.
 {{Common_bugs_header_shared}}
-== Upgrade issues ==
+== Core system issues ==
+{{Common bugs issue|dnf-verbose-logs|DNF logs very verbosely by default, leads to large log files|1355764}}
+By default, the DNF included with Fedora 30 does some very verbose logging. Especially the file `/var/log/dnf.librepo.log` contains very detailed logging of mirror selection and file download operations. Some operations, such as a system upgrade or `reposync`, can potentially cause multiple gigabytes of messages to be written to this log file. The DNF log files are configured for rotation, so they will be compressed and expired weekly so long as {{package|logrotate}} is installed, but this can be insufficient when a single operation can cause the files to grow very large.
+If the DNF log files are filling up your disk and you need a solution urgently, it is safe to simply remove the log files (after copying them elsewhere if you need them for reference), this will not break anything. A future libdnf update is planned to reduce the `dnf.librepo.log` verbosity. Until then, if this is an ongoing problem for you, you can work around it by redirecting the log output to {{filename|/dev/null}} - see [https://bugzilla.redhat.com/show_bug.cgi?id=1355764#c8 this bug comment] for one way to do that.
+{{Common bugs issue|1=selinux-private-devices-unlabelled|2=Multiple services fail to start with "status=226/NAMESPACE" in unusual cases|3=1663040}}
+Fedora 30's SELinux policy prevents systemd services with {{code|1=PrivateDevices=true}} from starting if some key mount points are not correctly labelled ({{filename|/dev}}, {{filename|/proc}}, {{filename|/sys}} etc.) In most cases you should not run into this issue, but some users who have transferred existing installations to other systems or deployed Fedora in unusual ways may do so (for instance, Hans de Goede [https://hansdegoede.livejournal.com/20910.html ran into this] after transferring a Fedora system from one disk to another using {{command|cp -pr}}, which does not preserve these labels).
+A 'normal' relabel will not solve this problem as the mount points have something mounted on them by the time it runs, and the relabelling is applied to the mounts, not the underlying mount points. To relabel the mount points, you must boot a live or rescue image, mount the installed system's root filesystem, change into the mounted directory, and run:
+ chcon -t device_t dev
+ chcon -t home_root_t home
+ chcon -t root_t proc sys
+ chcon -t var_run_t run
+Then unmount the mounted directory and reboot to the installed system, and now things should be fixed.
+{{Common bugs issue|encrypted-resume-delay|Encrypted system does not resume from hibernation correctly if you wait more than 90 seconds to input encryption password|1705522}}
+If you install Fedora 30 with the system partitions encrypted, and then use the hibernate (suspend-to-disk) feature, you will be prompted to input the encryption password during system resume. If you wait longer than 90 seconds before inputting the password, the system will not resume from hibernation correctly - instead a fresh boot will be performed and your previous state will be lost.
+There is currently no known workaround for this problem besides simply making sure you input the password soon enough to avoid it happening.
+== Workstation (GNOME) issues ==
-{{Common bugs issue|upgrade-29-hang|Upgrade from Fedora 29 hangs at end of upgrade process, showing "Upgrade complete! Cleaning up and rebooting..."|1674045}}
+{{Common bugs issue|shutdown-no-offline|Workstation shutdown menu does not prompt you to install prepared updates|1805265}}
-If you upgrade from Fedora 29 to Fedora 30, it is likely that after the upgrade completes, instead of rebooting to Fedora 30 automatically, the system will stop at a screen saying "Upgrade complete! Cleaning up and rebooting..."
+In Fedora Workstation, the shutdown/reboot menu is intended to alert you if system updates are prepared for installation and offer you the option of installing them before shutting down. This worked as intended in Fedora 28 and earlier. However, in Fedora 29 and later, a change to suspend PackageKit when it is not needed broke this feature: the notification almost never appears in the shutdown/reboot menu (it will only pop up if you happen to try and shut down very shortly after actively using PackageKit somehow).
-If this happens, the upgrade has completed successfully and it is safe to simply reset the system. Fedora 30 should boot automatically and work correctly.
+There is no known practical workaround for this issue at present.
-{{Common bugs issue|upgrade-module-platform|Upgrade fails due to dependency issues related to modules|1688462}}
+== Upgrade issues ==
-It is quite common when upgrading to Fedora 30 Beta (especially from Fedora 29, less so from Fedora 28) to encounter dependency issues related to packages from modules. The errors will look something like this:
+{{Common bugs issue|blscfg-fail|GRUB boot menu is not populated after an upgrade |1652806}}
- Problem 1: conflicting requests
+If you have a legacy BIOS installation (i.e. not UEFI), it is possible that after the upgrade process the GRUB bootloader will not populate the boot menu, and instead displays a GRUB prompt. This happens on systems that were originally installed using Fedora 20 or older.
-   - nothing provides module(platform:f30) needed by module stratis:1:20181215204600:a5b0195c-0.x86_64
-This occurs because a specific item of configuration related to how the module system is implemented is not known by dnf. To avoid the problem, you must include an argument which tells dnf about this in the upgrade commands. Where previously you would have run just:
+This happens because the GRUB core and modules in legacy BIOS are never updated unless the {{command|grub2-install}} command is executed. In Fedora 30 the default GRUB configuration is changed to use BootLoaderSpec-style files by default, and the blscfg module is updated when the {{package|grub2-pc-modules}} package is upgraded. However, this module is only compatible with versions of the GRUB core up to Fedora 21.
- sudo dnf system-upgrade download --refresh --releasever=30
+If GRUB has not been updated since Fedora 20 or earlier, it is recommended to execute the {{command|grub2-install}} command before doing a system upgrade. This should not affect legacy BIOS installations since Fedora 21. UEFI installs are unaffected because during upgrade the GRUB EFI image, containing the core and modules, is updated.
-You must now run:
+If you hit this issue, the old GRUB configuration is stored in /boot/grub2/grub.cfg.rpmsave. So the system can be recovered by executing the following from the GRUB prompt:
-  sudo dnf system-upgrade download --refresh --releasever=30 --setopt='module_platform_id=platform:f30'
+  grub> configfile /grub2/grub.cfg.rpmsave
-This should allow the upgrade to proceed correctly (also note the other entries in this section). We intend to improve things before the release of Fedora 30 Final such that explicitly passing this option will no longer be necessary, but for now please use it! Especially please do not use the {{code|--allowerasing}} argument to work around this problem: it will lead to packages being unnecessarily removed.
+And then execute the {{command|grub2-install /dev/X}} command (where X is the boot device, i.e sda) to update the GRUB core and the modules to the latest version installed by the {{package|grub2-pc-modules}} package.
 {{Common bugs issue|upgrade-fedora-release-conflict|Conflicts between fedora-release packages on upgrade|1649921}}
@@ Line 42: / Line 66: @@
 When attempting to upgrade to Fedora 30, you may see conflicts between multiple {{package|fedora-release}} subpackages. If this happens, we recommend you remove one of the conflicting packages to unblock the upgrade. Leave installed the package that most closely matches how you want the system to identify itself - the one that most closely matches your primary use of the system.
-== Workstation issues ==
+== Hardware issues ==
-{{Common bugs issue|basic-graphics-fails|'Basic graphics' mode will often fail on Workstation|1691909|1683197}}
-Due to at least two different problems, trying to boot a Fedora 30 Workstation live image or installed system using the 'basic graphics' option will often fail; when doing a BIOS native boot it will probably always fail, with a UEFI native boot it may work.
+{{Common bugs issue|broadcom-wl-mesh|Broadcom wireless adapters using proprietary ''broadcom-wl'' driver do not work reliably|1703745}}
-Fortunately this option is less commonly needed than it used to be. If you have a system on which it is necessary, you may need to install a different Fedora edition until fixes or workarounds for the problems are available.
+Multiple users of wireless network adapters supported by the proprietary ''broadcom-wl'' driver have reported that it does not work reliably in Fedora 30. '''PLEASE NOTE''' that Fedora does not provide or support this proprietary driver; we are providing this note only as a courtesy as we are aware that many people acquire the driver from a third party and use it on Fedora.
-{{Common bugs issue|dash-top-icon-missing|Top icon often disappears from dash|1690429}}
+The problem seems to be that a new feature in {{package|wpa_supplicant}} that was enabled in Fedora 30 confuses the ''broadcom-wl'' driver. As the driver is not open source we cannot provide a fixed version of it, and we will not disable a useful {{package|wpa-supplicant}} feature just to make a proprietary driver work correctly.
-A bug in GNOME in Fedora 30 Beta means that the icon that should appear at the top of the 'dash' in the overview (the panel of icons for running and/or favorite applications, on the left hand side) does not appear. Only a small horizontal bar will appear - you can interact with this bar as if it were the icon. (Technically, the icon is present, but has been assigned a height of 0, which is why it is not shown). The GNOME developers are working to fix this issue, and we will provide the fix as soon as it is available.
+To help out folks with affected devices, Davide Caratti is providing unofficial rebuilds of {{package|wpa_supplicant}} with the feature in question disabled. You can enable his [https://copr.fedorainfracloud.org/coprs/dcaratti/wpa_supplicant/ COPR repository] by running {{command|sudo dnf copr enable dcaratti/wpa_supplicant}}, and then updating your system should install his rebuild, if it is currently up-to-date compared to the version in the official repositories. With this rebuild installed, the wireless adapter should work reliably.
 == Other software issues ==
@@ Line 75: / Line 97: @@
 * '''RECOMMENDED''' Pass {{command|--excludepkg fedora-release-matecompiz}} to DNF. This will remove just this package from the transaction and allow the rest of the group to be resolved normally. This option will retain your system's "identity" to what it was from initial installation.
-* Pass {{command|--excludepkg fedora-release-workstation}} to DNF. This will remove just this package from the transaction and allow the rest of the group to be resolved normally. This option will *change your system identity* such that it will now report as a MATE Compiz system rather than a Workstation one.
+* Pass {{command|--excludepkg fedora-release-workstation}} to DNF. This will remove just this package from the transaction and allow the rest of the group to be resolved normally. This option will '''change your system identity''' such that it will now report as a MATE Compiz system rather than a Workstation one.
 * Pass {{command|--skip-broken}}. This is similar to passing {{command|--excludepkg fedora-release-matecompiz}} except that it will also skip any other potential conflicts which may result in an incomplete group install. Make sure to carefully examine the transaction summary before proceeding. This option will retain your system's "identity" to what it was from initial installation.
-* Pass {{comand|--allowerasing}}. This is similar to passing {{command|--excludepkg fedora-release-workstation}} except that it may also result in replacing other packages on your system unexpectedly. Make sure to carefully examine the transaction summary before proceeding. This option will retain your system's "identity" to what it was from initial installation.
+* Pass {{command|--allowerasing}}. This is similar to passing {{command|--excludepkg fedora-release-workstation}} except that it may also result in replacing other packages on your system unexpectedly. Make sure to carefully examine the transaction summary before proceeding. This option will '''change your system identity''' such that it will now report as a MATE Compiz system rather than a Workstation one.
+{{Common bugs issue|eclipse-module-conflicts|Problems trying to install Eclipse, or upgrade a system with Eclipse installed|1692089}}
+Multiple users have reported that attempting to install Eclipse and/or related packages, or to upgrade a system with Eclipse installed to Fedora 30, fails with various dependency errors. This appears to be caused by mismatches between packages in some modules and packages in the non-modular repositories. The relevant packagers are working to investigate and resolve these issues as soon as possible. Please follow the bug report for specific details and possible workarounds.
+{{Common bugs issue|repoview-not-installable|repoview package cannot be installed|1703668}}
+The {{package|repoview}} package in Fedora 30 is not installable. This is because one of its dependencies (python2-kid) was retired due to lack of maintenance, and left out of Fedora 30.
+As the dependency is essential (repoview does nothing useful without it) and the package is 'baked into' the frozen release tree, we cannot solve this except by reviving python2-kid. If this does not happen, the package will remain available but not installable. We apologize for the inconvenience.
+== Resolved issues ==
+{{Common bugs issue|bcache-corruption|Upgrading bcache-based systems to Fedora 30 may result in severe storage corruption|1708315}}
+Earlier Fedora 30 kernels may severely corrupt system storage on systems that use bcache. To mitigate, you could disable (detach) cache devices before upgrading to Fedora 30.
+This issue was been fixed in kernel version 5.1.12. Any upgrade to Fedora 30 performed presently should receive a kernel version later than this and should therefore not be affected by this bug.
+[[Category:Common bugs]]

Search