I’ve been a die-hard Rocky Linux user since CentOS pulled the rug from under our feet (after a brief stint with Oracle Linux). I’m running it on all my server and desktop installations.
On the desktop I usually start from a minimal system and then install all the layers that build a desktop: X11, KDE from EPEL, handful of best-of-the-breed apps, etc.
One thing that’s a bit sad is the state of the Live KDE ISOs. Seems like they are never even beta-tested before they are published. After 9.5 has been released, I gave it a go again.
Anaconda instantly says “Installing software 100%” and then stays there for a few minutes, so you don’t know what’s going on.
And then you reboot, you connect in SDDM, and the first thing you are greeted with are a few windows with sad emojis informing you that KDE Connect crashed.
This is bad press for Linux in general and Rocky Linux in particular. I’d suggest: either do some very basic testing of these images or don’t publish them at all.
All of our images are tested before release. Live images are not an exception.
This is not the experience that either myself or any of the testers reported for both x86_64 and aarch64 live images, but that does not mean it is not an uncommon experience. Others will run into this too and is system dependent.
With that said, what you’re describing has everything to do with anaconda, and not the live images themselves.
This is a problem regardless of EL you use, whether that’s Rocky Linux or CentOS Stream, the end result is the same with KDE Connect.
KDE Connect is part of EPEL and not Rocky Linux. This means that the problem you’re describing is very likely happening to more than just our distribution.
As stated, we do plenty of testing before our releases. There have been numerous times I’ve recreated live images during regular testing to address SELinux issues, which are the most common problem.
My suggestion and recommendation is that if you believe you can provide insight, assistance, or any kind of help as it pertains to our releases and its testing, join our Mattermost and become part of the testing team.
I’ll just only add, let’s differentiate between two things here. Live CD and installation. The Live CD’s seem to work perfectly fine. Installation is another matter entirely, and as you already know, KDE is from EPEL and not maintained by the Rocky team which you also know. Therefore if EPEL release something that’s not working properly after installation, then that is a bug for EPEL to fix.
About the only thing that is a minor issue here is the “installing software 100%” and not knowing how far it has got. I wouldn’t really call that a “sad state”. Bit of an over-reaction really.
There are better ways of providing information to help get a problem fixed, and there is no need for things like “sad state”, “bad press for Linux” or “do basic testing or don’t publish at all”. You seem to use KDE a lot and complain here a lot about it, but don’t do much to assist in actually getting those problems solved.
Maybe think about being more constructive in the future than just complain
I’m sorry if that came out wrong. The more so since I’m really grateful for Rocky. Maybe Ian’s right: probably just an over-reaction. I’ll just go and file a couple bug reports.
I expect the KDE Connect issue could occur irrespective of the installation method. Eg: Live image install vs install Rocky with Gnome and then install KDE later. I don’t use KDE so unlikely to ever install and check/test that myself.
Is there a reason for using SDDM? For example, if you used GDM3 instead, does the system behave any better? I obviously realise GDM3 is Gnome Display Manager and therefore you may not wish to be installing that because it pulls in Gnome dependencies. With my Cinnamon Desktop install I use lightdm - so perhaps lightdm as an alternative to SDDM. However I don’t know if that will help with the KDE Connect issue or not. It would be strange for a login screen to have any influence on it. But then again, stranger things have happened.
When you use the installer and start from a minimal system and then install base-x, epel-release and KDE, things work perfectly on both 8.x and 9.x. On the other hand, you get these KDE Connect crash windows when you install from the KDE Live CD.
I use KDE and I love it! And I’m disappointed too.
I looked at the other options for KDE, using Neon, Fedora Spins or something else. The idea doesn’t appeal to me and I’ve built up resourced on Rocky, VMs etc.
Even paying Redhat isn’t a bad deal considering the quality of the troubleshooting resources.
At the start of this adventure it seemed like we needed “Bucky” the KDE version with more stuff that is up to date for graphics. Now… I’m getting beta software off flatpacks.
I can tell you this… unless you have a lot of skill and time, just stick to Plasma 5. Getting back to a working version of 5 after trying the various pathways to 6 have left me with problems that are in the “never seen that before” camp and a PITA.
The best option is likely a Fedora Spin of KDE6.
I know that KDE Connect and a USB cable is a waste of effort. Case that is what you are doing.
I’ve not seen past the paywall into those resources but they seem substantial. The comparison with Redhat has to be Microsoft. Not small downstream or upstream OSes.
