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?
[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
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)…
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
I am using copr and cinnamon will see how mine upgrades later.
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.
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
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.
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 …
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.
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.
This link pretty much explains it: 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
I can confirm that LXDM works with RL 8.6!
Raven-release repo - raven-release-1.0-2.el8.noarch.rpm CentOS 8 Download
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!)
Update: copying from the upstream kernel bug:
“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.”
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.
So it’s not fixed in Rocky 8.6 using?
According to a comment in the upstream bug, a fix is expected before 8.7
I already installed 4.18.0-372.19.1.el8_6.x86_64, but is seems the problem persist also on this kernel :-/