Description of problem: A Fedora 13 installation that has been upgraded to Fedora 14 by using the DVD installation media, when it boots, KDM reports a missing Laughlin theme file. Version-Release number of selected component (if applicable): How reproducible: Upgrade a Fedora 13 that uses KDM instead of GDM for graphical login Steps to Reproduce: 1. Upgrade a Fedora 13 using installation DVD media 2. Reboot the system when finished 3. Actual results: KDM fails to start and the following error pop-up message is displayed: "Cannot open theme file /usr/share/kde4/apps/kdm/themes/Laughlin" After pressing the "OK" button, a blank screen is displayed and you cannot login. Expected results: KDM should have been prompted for user's login Additional info: A workaround is to press CTRL-ALT-F2, login and issue the following command as super user: # yum install laughlin-kde-theme Then kill current kdm process running in order to respawn and to be able to login. Preupgrade method is free of this problem, as it includes the required package.
Does anything require this package?
The answer is yes! That package theme usage is declared in KDM configuration /etc/kde/kdm/kdmrc: ---------- # The theme to use for the greeter. Can point to either a directory or an XML # file. Default is "/usr/share/kde4/apps/kdm/themes/circles" Theme=/usr/share/kde4/apps/kdm/themes/Laughlin ---------- which is replaced by the package kde-settings-kdm-4.5-9.fc14.noarch that belongs to, and the dependency is out there: # yum deplist kde-settings-kdm-4.5-9.fc14.noarch Finding dependencies: package: kde-settings-kdm.noarch 4.5-9.fc14 ... dependency: system-kdm-theme provider: laughlin-kde-theme.noarch 14.0.0-1.fc14 ...
Can you attach /root/upgrade.log and /var/log/anaconda.yum.log from the finished system?
Created attachment 459173 [details] Upgrade log Log file /root/upgrade.log
Created attachment 459174 [details] Anaconda log Log file /var/log/anaconda.yum.log
*** Bug 651957 has been marked as a duplicate of this bug. ***
If you don't mind, can you also attach /root/install.log as well? This file should exist from your original F-13 installation.
Created attachment 459943 [details] Install Log Log file /root/install.log attached. Basically, it's a Fedora 11 clean installation with the minimal system option set (only 184 packages installed). If I hadn't changed the disk and format to ext4, it would have been still a Fedora CORE something installation.
(In reply to comment #8) > Basically, it's a Fedora 11 clean installation with the minimal system option > set (only 184 packages installed). If I hadn't changed the disk and format to > ext4, it would have been still a Fedora CORE something installation. Can you explain the history of installs and upgrades on this system? 1) From the install.log attached, you started with a Fedora 11 minimal installation. 2) At some point, you manually installed kde desktop packages 3) You then upgraded to F-12 4) Then upgraded to F-13 5) Then upgraded to F-14? Is that the correct order of operations?
I'm attempting to reproduce this behavior using the procedure in comment#9. Marking this bug as needinfo? one more time just to get some more feedbcak from Panos.
Hello James, That's totally correct! That system is used on my work as a development node and I upgraded to the next release starting from Fedora 11, without skipping any release cycle. The minimum installation was selected for the starting F11. Then "yum groupinstall 'KDE ...'" and all the rest packages that I've needed from time to time. To my understanding, a simple clean standard F13 with KDE option instead of gnome selected and then upgrade to F14 should be enough to reproduce the problem. I've also got the same problem when upgrading from F12 to F13 and it was solved by the "yum update". Older versions of Fedora were not affected by this problem, since kdm settings was declared probably as %config(noreplace) in the spec and it was emitted in the filesystem as .rpmnew. Then after upgrade we had to manually set KDM to the new release theme, since it was using the old one.
Similar to comment 2, can you do: yum whatprovides system-kdm-theme
I'm a little surprised to see neither goddard-kde-theme or laughlin-kde-theme get installed or upgraded. That combination is what spelled doom here. f13's goodard-kde-theme Provides: system-kde-theme , but the f14 version of it does not (laughlin-kde-theme Provides that).
Hello Rex, Here is your requested output: # yum whatprovides system-kdm-theme laughlin-kde-theme-14.0.0-1.fc14.noarch : Laughlin KDE Theme Repo : fedora Matched from: Other : system-kdm-theme laughlin-kde-theme-14.0.0-1.fc14.noarch : Laughlin KDE Theme Repo : installed Matched from: Other : Provides-match: system-kdm-theme
Weird, did people just suddenly stop hitting this? We haven't marked any dupes in quite a while now.
The bug requires someone to use KDM instead of the default GDM and use DVD upgrade method (preupgrade cannot reproduce it). It either requires "DISPLAYMANAGER=KDE" in /etc/sysconfig/desktop or to have only kdm installed. Otherwise, you will never notice it. You won't even notice it, if your kdmrc is changed, as it will be preserved and no laughlin theme will be needed. Not even if you switch later on to kdm, as it is solved automatically after a system update. A very few users can be affected by this problem and people are reluctant to report something that it is already solved in an update. Only the first shock that you get after upgrading your distribution, where you are unable to log in makes a big fuss about it. Minor importance for advanced users that can bypass GUI login and resolve the problem in a console though.
I've encountered this issue when upgrading from a clean F13 to F14. The workaround from the first comment does the trick but it needs additional tweaks, if no networking is available (I have a Dlink DWA-140 USB wireless adapter which requires rt3070 drivers on F14 instead of rt2870 on F13): - mount Fedora DVD: #mkdir /mnt/cdrom #mount /dev/dvd /mnt/cdrom - install missing packages: #cd /mnt/cdrom/Packages #yum localinstall laughlin-kde-theme-14.0.0-1.fc14.noarch.rpm laughlin-backgrounds-kde-14.1.0-1.fc14.noarch.rpm laughlin-backgrounds-single-14.1.0-1.fc14.noarch.rpm --disablerepo=\* --nogpg #reboot
I am still seeing this issue when upgrading from F15 to F16 RC2. F15 was installed from x86_64 live KDE spin, F16 RC2 was installed from DVD x86_64 while unchecking GNOME and selecting KDE. So KDM (and only KDM) was installed on both. As it was pointed out, 'yum install verne-kde-theme' works around the problem. However, this issue does not meet Beta Release Criteria: 9. The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria. (https://fedoraproject.org/wiki/Fedora_16_Beta_Release_Criteria) Therefore I am proposing this as a blocker.
No idea how/why this is still happening. On my f16 test box: repoquery --whatprovides \ system-kdm-theme system-ksplash-theme system-plasma-desktoptheme ====> verne-kde-theme-0.15.91.0.1.fc16.noarch Martin, on your box post-upgrade (if possible), can you do: rpm -q --whatprovides system-kdm-theme system-ksplash-theme
$ rpm -q --whatprovides system-kdm-theme system-ksplash-theme lovelock-kde-theme-14.91.0.1.fc15.noarch verne-kde-theme-15.91.0.1.fc16.noarch lovelock-kde-theme-14.91.0.1.fc15.noarch verne-kde-theme-15.91.0.1.fc16.noarch This is however after I installed verne-kde-theme manually.
Oh, evil, I think I know why upgrading via the DVD causes this: the DVD probably doesn't contain newer *-kde-theme packages, ones that no longer includes: Provides: system-kdm-theme (and friends). And, without that, verne-kde-theme doesn't get pulled into the upgrade transaction. I'll go poke some folks on irc, see what best solution we can come up with.
Discussed at 2011-10-31 QA meeting acting as blocker review meeting. Accepted as blocker per criterion "The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria." rex will build a fix for this asap, then we will spin rc3 with it included. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
As this is not an anaconda issue, re-assigning. Decided the best place to implement a fix was in kde-settings, to hard-code the default theme used.
kde-settings-4.7-13.fc16.1 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/kde-settings-4.7-13.fc16.1
As I explained of IRC, we're only papering over the symptoms here. It is well-known that a DVD upgrade will in general NOT result in a working system without running "yum update" once after completing the DVD upgrade. "yum update" also fixes this problem, so I don't see how it is a blocker. This is just yet another example showing that the way the DVD does upgrades is broken and unsupportable. Upgrades MUST include Everything and updates repositories. The fact that the DVD still doesn't do this (in fact doesn't even SUPPORT it for upgrades, as opposed to fresh installs) must be fixed. As an example what can go wrong, look at the Fedora 11 yum issue. AFTER the Fedora 11 release (so there was no way to address it through the Blocker Process, even its current version), yum in Fedora 10 got upgraded to a new upstream version which was newer than in Fedora 11 GA. As a result, Anaconda would keep Fedora 10's yum, which was built against an older Python than Fedora 11's Python. And as a result, you couldn't even run "yum update". The only solution which works is to have upgrades mandatorily include the Everything and updates repositories.
So, my proposal is, bump this back to Anaconda, and require them to fix it the proper way, i.e. by enabling the Everything and updates repositories for updates.
kde-settings-4.7-13.fc16.4, kdebase-workspace-4.7.2-14.fc16, kdelibs-4.7.2-5.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
Confirming that Fedora 16 Final RC3 solves this issue.