# 8.6 upgrade problems (still not resolved)

**URL:** <https://forums.rockylinux.org/t/8-6-upgrade-problems-still-not-resolved/6069>\
**Category:** Rocky Linux Help & Support\
**Created:** [May 17, 2022, 8:48pm UTC](https://forums.rockylinux.org/t/8-6-upgrade-problems-still-not-resolved/6069 "2022-05-17T20:48:14Z")\
**Posts on this page:** 19\
**Page:** 1

<div class="post-metadata">

**Author:** ![ValorCat](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/valorcat/32/1953_2.png) [@ValorCat](https://forums.rockylinux.org/u/ValorCat)\
**Post date:** [May 17, 2022, 8:48pm UTC](https://forums.rockylinux.org/t/8-6-upgrade-problems-still-not-resolved/6069/1 "2022-05-17T20:48:14Z")

</div>

I successfully updated to 8.6 (sudo dnf update --allowerasing --nobest -y) I got a cursor over a black background… I had to plug my headless server back into a monitor ☹ and switch back the last 8.5 kernel…

It also completely busted my redshift for maya - maxon one licence (which was very difficult to install in the first place…

I am also using sddm (maybe this is an epel-release delayed update situation? Whoever is maintaining the SDDM is the culprit (poor soul)?)

Maybe the 8.6 updates are being added to the Rocky Repo one-by-one? And the Rocky update is stilll incomplete? Therefore, breaking everyone’s delicate mission-critical server situation?

---

<div class="post-metadata">

**Author:** ![irisx](https://avatars.discourse-cdn.com/v4/letter/i/77aa72/32.png) [@irisx](https://forums.rockylinux.org/u/irisx)\
**Post date:** [May 17, 2022, 9:13pm UTC](https://forums.rockylinux.org/t/8-6-upgrade-problems-still-not-resolved/6069/2 "2022-05-17T21:13:37Z")

</div>

[With apologies for cross-posting, I am leaving this here for people who will start from this thread]

For anyone dealing with the sddm blackout after upgrading to 8.6, a temporary (and perhaps obvious) workaround is to switch to gdm. From a console or ssh, as root:

dnf install gdm  
systemctl stop display-manager  
systemctl disable sddm  
systemctl enable gdm  
systemctl start display-manager

The disable/enable commands do the actual work, so if they succeed you can just reboot and gdm will (hopefully) come up.

Don’t forget upon the first login to click on the “gear” icon and select Plasma as the preferred desktop.

The process _should_ be reversible once sddm (or whatever causes the problem) gets repaired…

This of course assumes that you are not actually in need of any fancy sddm features that are not present in gdm. And YMMV etc.

Note: in my case gdm spends a little while after entering the password apparently doing nothing, but I guess it’s better than staring into a black screen with a pointer 😉

---

<div class="post-metadata">

**Author:** ![ValorCat](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/valorcat/32/1953_2.png) [@ValorCat](https://forums.rockylinux.org/u/ValorCat)\
**Post date:** [May 17, 2022, 9:28pm UTC](https://forums.rockylinux.org/t/8-6-upgrade-problems-still-not-resolved/6069/3 "2022-05-17T21:28:31Z")

</div>

_and perhaps obvious_ 🤣  
Ouch! No, not to me haha  
But, I suppose that makes sense considering gdm is native, therefore, guaranteed most stable.  
I specifically chose sddm cause its lightweight (lxdm was borking on boot)…

---

<div class="post-metadata">

**Author:** ![ValorCat](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/valorcat/32/1953_2.png) [@ValorCat](https://forums.rockylinux.org/u/ValorCat)\
**Post date:** [May 18, 2022, 2:32am UTC](https://forums.rockylinux.org/t/8-6-upgrade-problems-still-not-resolved/6069/4 "2022-05-18T02:32:06Z")

</div>

> [@8.6 upgrade problems \[Resolved\]](https://forums.rockylinux.org/t/8-6-upgrade-problems-resolved/6057/15):
>
> So it appears it is indeed an upstream 8.6 kernel bug that affects both sddm and kscreenlocker: [https://bugzilla.redhat.com/show\_bug.cgi?id=2043771](https://bugzilla.redhat.com/show_bug.cgi?id=2043771)[https://bugzilla.redhat.com/show\_bug.cgi?id=2082719](https://bugzilla.redhat.com/show_bug.cgi?id=2082719) It’s currently unknown when it will be fixed and unfortunately the relevant tracker bug is private.

☝ Here is the solution… it is an EPEL compadibility problem… That’s what I get for wanting to use LXDE (via raven repo) over stock gnome, and sddm via epel over stock gdm 🥴

---

<div class="post-metadata">

**Author:** ![iwalker](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/iwalker/32/2599_2.png) [@iwalker](https://forums.rockylinux.org/u/iwalker)\
**Post date:** [May 18, 2022, 4:52am UTC](https://forums.rockylinux.org/t/8-6-upgrade-problems-still-not-resolved/6069/5 "2022-05-18T04:52:58Z")

</div>

I am using copr and cinnamon will see how mine upgrades later.

---

<div class="post-metadata">

**Author:** ![ValorCat](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/valorcat/32/1953_2.png) [@ValorCat](https://forums.rockylinux.org/u/ValorCat)\
**Post date:** [May 18, 2022, 6:06am UTC](https://forums.rockylinux.org/t/8-6-upgrade-problems-still-not-resolved/6069/6 "2022-05-18T06:06:49Z")

</div>

Good luck @iwalker !

---

<div class="post-metadata">

**Author:** ![irisx](https://avatars.discourse-cdn.com/v4/letter/i/77aa72/32.png) [@irisx](https://forums.rockylinux.org/u/irisx)\
**Post date:** [May 18, 2022, 6:15am UTC](https://forums.rockylinux.org/t/8-6-upgrade-problems-still-not-resolved/6069/7 "2022-05-18T06:15:09Z")

</div>

I guess this is also a price to pay for EPEL always providing recent[-ish] versions for Qt, kde and friends while having to patch for incompatibilities with the backported stuff in Base.

---

<div class="post-metadata">

**Author:** ![iwalker](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/iwalker/32/2599_2.png) [@iwalker](https://forums.rockylinux.org/u/iwalker)\
**Post date:** [May 18, 2022, 6:46am UTC](https://forums.rockylinux.org/t/8-6-upgrade-problems-still-not-resolved/6069/8 "2022-05-18T06:46:17Z")

</div>

I think a lot of it depends on what you are installing. I think installing desktops like KDE, or whatever that isn’t normally in the repositories and relies on a hell of a lot of dependencies can always be problematic. More so when they don’t keep up quick enough with the base OS. If for example 8.6 is released and then immediately updating and the other third party repos are still based on 8.5 dependencies, then it can can issues of course. And using `--allowerasing` and similar parameters in such a situation just makes things worse.

I think for such situations when the other repos need to catch up, it simply should be a case of just waiting a short while and then just updating once everything is consistent.

I forgot my Rocky Desktop VM is on my home machine, so will have to check that later on today when I get home from work 🙂

---

<div class="post-metadata">

**Author:** ![jlehtone](https://avatars.discourse-cdn.com/v4/letter/j/e9a140/32.png) [@jlehtone](https://forums.rockylinux.org/u/jlehtone)\
**Post date:** [May 18, 2022, 7:51am UTC](https://forums.rockylinux.org/t/8-6-upgrade-problems-still-not-resolved/6069/9 "2022-05-18T07:51:15Z")

</div>

> [@irisx](#):
>
> I guess this is also a price to pay for EPEL always providing recent[-ish] versions for Qt, kde and friends while having to patch for incompatibilities with the backported stuff in Base.

Qt 5 is in Appstream, “in Base”. However, EPEL has some additional subpackages for it. Same version, not clearly distinct. Therefore, those qt5-\* packages in EPEL must match the core in Base. Overall, EPEL does not replace what Base has – it provides _Extra Packages for Enterprise Linux_.

KDE is clearly one such case; RHEL 8 has none of it.

> [@iwalker](#):
>
> I think a lot of it depends on what you are installing. I think installing desktops like KDE, or whatever that isn’t normally in the repositories and relies on a hell of a lot of dependencies can always be problematic.

Indeed. KDE has plenty of packages and dependencies. Red Hat did introduce something new (backported into) 8.6’s kernel (and other packages). If that broke what upstream KDE depends on, then the upstream KDE (and/or Red Hat) should solve that regression before EPEL can try to build for RHEL 8.6 target.

Back when RHEL 8.5 was released, EPEL had all the sources ready for rebuild _before_ any of the clones (Rocky, Alma, CentOS Linux, Oracle, etc). However, EPEL has many “projects” and while that means “many maintainers”, that does not automatically mean that all those maintainers would immediately jump to rebuild all the projects. Rocky has more hands on “a project”, (although the project is larger than anything in EPEL.)

Another third-party repository that can affect updates is ELRepo, because they build kernel modules – drivers for devices. If ELRepo is delayed, then you can’t use the new kernel. If the ELRepo has packages for new point update quickly (as it did for RHEL 8.6), then you might have been able to update the driver _before_ you got Rocky 8.6’s kernel, which would have broken your 8.5’s kernels …

> [@iwalker](#):
>
> I think for such situations when the other repos need to catch up, it simply should be a case of just waiting a short while and then just updating once everything is consistent.

I agree. From moment RHEL 8.6 became GA to moment the packages _you_ use from third-party repos do catch up is a _twilight zone_.

---

<div class="post-metadata">

**Author:** ![desercat](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/desercat/32/1192_2.png) [@desercat](https://forums.rockylinux.org/u/desercat)\
**Post date:** [May 18, 2022, 9:51am UTC](https://forums.rockylinux.org/t/8-6-upgrade-problems-still-not-resolved/6069/10 "2022-05-18T09:51:52Z")

</div>

WOW!!! I did not know 8.6 is now out!! Next stop: Full disk Backup!!

Second: You got CINNAMON installed?!?! Pray tell, how did you do that?!? Please don’t tell me “dnf install cinnamon”, or 'groupinstall “Cinnamon” '(or “cinnamon” tried that too), no matter what I do I can’t install “Cinnamon” in RL 8.5. Or most I be running RL 8.6 to install Cinnamon?

As to DM, I _think_ I somehow got LightDM installed. SDDM was my goto DM as RedHat screwed me up so I switched to LightDM. GDM was a no-no as it lead to runaway processes that filled up the /tmp, and /var partitions.

---

<div class="post-metadata">

**Author:** ![iwalker](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/iwalker/32/2599_2.png) [@iwalker](https://forums.rockylinux.org/u/iwalker)\
**Post date:** [May 18, 2022, 10:46am UTC](https://forums.rockylinux.org/t/8-6-upgrade-problems-still-not-resolved/6069/11 "2022-05-18T10:46:03Z")

</div>

This link pretty much explains it: [https://www.addictivetips.com/ubuntu-linux-tips/install-the-cinnamon-desktop-on-rocky-linux-8-5/](https://www.addictivetips.com/ubuntu-linux-tips/install-the-cinnamon-desktop-on-rocky-linux-8-5/)

Enabling two repositories with `dnf copr` command, installing lightdm and cinnamon, disabling gdm and enabling lightdm was pretty much it in short. That said it was done on Rocky a week ago when I was on 8.5 so just need to see how it looks on update. Will find out tonight 🙂

---

<div class="post-metadata">

**Author:** ![ValorCat](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/valorcat/32/1953_2.png) [@ValorCat](https://forums.rockylinux.org/u/ValorCat)\
**Post date:** [May 18, 2022, 2:45pm UTC](https://forums.rockylinux.org/t/8-6-upgrade-problems-still-not-resolved/6069/12 "2022-05-18T14:45:17Z")

</div>

I can confirm that LXDM works with RL 8.6!

Raven-release repo - [raven-release-1.0-2.el8.noarch.rpm CentOS 8 Download](https://centos.pkgs.org/8/raven-x86_64/raven-release-1.0-2.el8.noarch.rpm.html)  
Has LXDM and LXDE (although for some reason you have to manually install most of the lxde components individually - its lightweight as hell and great for redshift rendering on my 3x-3080ti machine!)

---

<div class="post-metadata">

**Author:** ![iwalker](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/iwalker/32/2599_2.png) [@iwalker](https://forums.rockylinux.org/u/iwalker)\
**Post date:** [May 18, 2022, 2:49pm UTC](https://forums.rockylinux.org/t/8-6-upgrade-problems-still-not-resolved/6069/13 "2022-05-18T14:49:51Z")

</div>

Yup, mine upgraded OK:

```auto
dnf clean all
dnf update

```

nice little screenshot 🙂

 ![Screenshot from 2022-05-18 16-48-41](https://us1.discourse-cdn.com/flex020/uploads/rockylinux/original/2X/0/0afd6c7e15a18c078c72db07e18a6670e2cc9974.png)

---

<div class="post-metadata">

**Author:** ![irisx](https://avatars.discourse-cdn.com/v4/letter/i/77aa72/32.png) [@irisx](https://forums.rockylinux.org/u/irisx)\
**Post date:** [May 23, 2022, 4:52pm UTC](https://forums.rockylinux.org/t/8-6-upgrade-problems-still-not-resolved/6069/14 "2022-05-23T16:52:06Z")

</div>

Update: copying from [the upstream kernel bug](https://bugzilla.redhat.com/show_bug.cgi?id=2082719):

“The fixed kernel is in QA status. That doesn’t give us a timeline yet, there still might be regressions that need to be fixed. But at least now it’s in the intense testing.”

---

<div class="post-metadata">

**Author:** ![irisx](https://avatars.discourse-cdn.com/v4/letter/i/77aa72/32.png) [@irisx](https://forums.rockylinux.org/u/irisx)\
**Post date:** [July 14, 2022, 12:09pm UTC](https://forums.rockylinux.org/t/8-6-upgrade-problems-still-not-resolved/6069/15 "2022-07-14T12:09:52Z")

</div>

Update: as mentioned in the upstream bug comments, kernel 4.18.0-394 from CentOS stream seems to fix the problem.

Confirmed here to solve both the sddm/kscreenlocker blockage as well as startup problems with two Qt5 applications.

---

<div class="post-metadata">

**Author:** ![gerry666uk](https://avatars.discourse-cdn.com/v4/letter/g/dbc845/32.png) [@gerry666uk](https://forums.rockylinux.org/u/gerry666uk)\
**Post date:** [July 15, 2022, 12:31pm UTC](https://forums.rockylinux.org/t/8-6-upgrade-problems-still-not-resolved/6069/16 "2022-07-15T12:31:31Z")

</div>

So it’s not fixed in Rocky 8.6 using?

```auto
4.18.0-372.13.1.el8_6.x86_64

```

---

<div class="post-metadata">

**Author:** ![irisx](https://avatars.discourse-cdn.com/v4/letter/i/77aa72/32.png) [@irisx](https://forums.rockylinux.org/u/irisx)\
**Post date:** [July 15, 2022, 7:26pm UTC](https://forums.rockylinux.org/t/8-6-upgrade-problems-still-not-resolved/6069/17 "2022-07-15T19:26:47Z")

</div>

Unfortunately not…

According to a comment in the upstream bug, a fix is expected before 8.7

---

<div class="post-metadata">

**Author:** ![Sml112](https://avatars.discourse-cdn.com/v4/letter/s/48db29/32.png) [@Sml112](https://forums.rockylinux.org/u/Sml112)\
**Post date:** [August 30, 2022, 8:42am UTC](https://forums.rockylinux.org/t/8-6-upgrade-problems-still-not-resolved/6069/18 "2022-08-30T08:42:47Z")

</div>

I already installed 4.18.0-372.19.1.el8\_6.x86\_64, but is seems the problem persist also on this kernel :-/

---

<div class="post-metadata">

**Author:** ![brian](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/brian/32/5777_2.png) [@brian](https://forums.rockylinux.org/u/brian)\
**Post date:** [August 25, 2023, 3:41am UTC](https://forums.rockylinux.org/t/8-6-upgrade-problems-still-not-resolved/6069/19 "2023-08-25T03:41:37Z")

</div>

Closed on August 25, 2023, 3:41am UTC


