Yeah I run KDE X11, but may run Xfce… ASSUMING I can somehow manage to rollover ocelot to 8.6. … maybe by running the rollover from within GNOME or Xfce.
D’ Cat
@desercat No, they won’t have problems simply because Gnome is by default provided in RHEL/Rocky. The reason everyone is having problems with KDE, is because it’s not natively available in Rocky. I rolled over my machine which has Cinammon, which is a variant of Gnome so probably uses some dependencies here. It worked, but I also know that it may fail. It’s not available by default in RHEL/Rocky so the chances for it to break are there. So I can have the same problems with Cinammon that people have with KDE. However, maybe I was just luckier than those with KDE.
The problems with KDE are not Rocky’s or RHEL’s fault. They don’t include it. So all these posts blaming Rocky are uncalled for. If you wish to use something outside of Rocky’s repositories, don’t blame Rocky. That blame lies with the repositories that provided KDE, as well as the people who chose to use it, rather than stick with what is provided by default in Rocky/RHEL.
If my Cinammon desktop fails after an update, then I only have myself to blame for choosing to use it. As is always also stated, third-party repositories are not responsible for breakage to your system if you choose to use them. That indemnity is almost always stated in the site or by whoever provides that repository.
Basically you use it at your own risk.
The issue is that RHEL is not “mainstream”. Red Hat had KDE in earlier RHEL – they also had btrfs as technology preview – but for some reason chose to “focus their resources” and therefore RHEL 8 does not have those technologies. RHEL is closer to “no more than necessary*” than “something for everyone”.
EPEL is a something for everyone collection because RHEL is not.
*Red Hat’s view on “necessary on Enterprise Linux” is not the same as casual users’.
That bug lists two issues. One is with GDM lockscreen in Plasma. The other is that SDDM is just blank. We obviously can’t tell whether SDDM would have a lockscreen issue if it was not blank.
There is only one Rocky (8). It is currently based on RHEL 8.6 sources. The 8.4 and 8.5 content is now only packages that once were. Unsupported, because never versions have been released. The 8.4 content has known security vulnerabililties. Later versions of packages have fixes for them but those you get only by installing them.
The current Rocky repos have content built from RHEL 8.6 sources. There are no 8.4’s nor 8.5’s packages in the repo. (Well, some might be identical, because they have not received any updates.)
It might still be possible to get the 8.5 content from somewhere but essentially the option to “move to 8.5” did vanish the moment 8.6 was released.
Rocky can’t support past point releases because Red Hat does not publish patches for them any more; 8.6 is the “patch” for previous content. All the RHEL rebuilds/clones have the same issue and have always had. Even RHEL 8.5 has that issue as it does not have EUS, so users of RHEL 8.5 must update to RHEL 8.6 just like us.
The latest and greatest RHEL 8 kernel has bugs despite there having been CentOS Stream 8 with that kernel (presumably) and the RHEL 8.6 beta. That is normal. The crucial thing is that correct parties get useful bug reports. With kernel/sddm Rocky is not the correct party – Rocky reproduces the bugs in kernel “perfectly”.
…and find that’s broke when you get to 8.7
Cheers, All GTK. I was thinking the 8.5 stuff in the repos’d be there for a while (dunno why) but I have the 8.5 iso and not too worried about vulnerabilites at the moment. Really don’t want to give up KDE…this is a bit $*** really… maybe it’s time to admit defeat, buy a canoe and disappear up the Amazon.
Great!! SDDM is broken too!! But that does not totally surprise me as I ran into that in CentOS 7.8 (??) GDM leads to runaway processes that start filling up your disk with useless Audits. I then found SDDM, which fixed the problem, but then Red Hat broke that too leading to a BLACK SCREEN. I then switched to LightDM which is the DM I am currently using, including in 8.5.
I just finished rolling back ocelot to 8.5, after I rolled-over to 8.6, but discovered that 8.6 broke my KDE install. So I too am back to running 8.5 for the next week or two before I try to do the rollover again and see if someone has fixed the KDE problem.
“But alas we will always have openSUSE 15.3 Leap to remember.” – Anyone recognize riffed quote from Casablanca? ( But seriously also one of the reasons we have both a Primary and a Secondary OS fully tricked out – we always have an immediate backup in case the Primary goes south. )
D’ Cat
There are clearly two distinct user groups. One is not worried about security. The other is so paranoid that they end up breaking their system unless educated.
“Know thine system and know the risks and thou can thwart a hundred incidents without restore from backups.”
Not sure that’s entirely true. The bug report ends on “Turns out this was a RHEL 8.6 kernel bug after all” …so not KDE’s fault at any rate…but yeah they can’t be held accountable as it isn’t officially supported - can’t argue with that.
iwalker First this is NOT the fault of Rocky; that said I DO lay the blame on Red Hat. All Rocky Linux, Alma Linux, et. al. are “Bug for bug” COPIES of RHEL, thus what ever is in RHEL will show up in Rocky Linux, et. al. Given that KDE is the Largest or Second Largest DE (depends on who you ask) for Red Hat NOT to choose to make sure their stuff works on KDE is snoppery at its worst. Just because Red Hat is a 10,000 lb gorilla does not mean they should not play nicely with others. Especially given that Red Hat itself recently supported both GNOME and KDE up until I think CentOS 7.8 when they decided to drop KDE. Fine they did it for whatever reason; that said for Red Hat to ignore KDE is to do so at their own risk.
Ah!! But I forgot that Red Hat Supported CentOS, until recently, like KDE, they decided to CentOS loose. Red Hat was also one of the first adopters of GRUB2, which nobody really likes to this day, but people have learned to live with, now Red Hat breaks GRUB2 by moving functions in GRUB2 to /boot/loader/entries. Then there is the issue of Wayland, a technology that while far better than it was, is still full of known bugs, so WHY include it in RHEL 8.5? To give USERS who want the choice to play with WAYLAND that option, rather than sticking with X11, even though by including BOTH Wayland is likely to break or disable aspects of X11?? But WAIT!!! Red Hat once supported KDE, until they arbitrarily decided NOT to support it, leaving their KDE users up in the air. By far the worst thing they did was to suddenly cut CentOS off at the knees.
The CentOS community provided Red Hat more real world testing, and real world solutions than they could have hoped for. Red Hat is behaving more like a school yard bully than a responsible corporate citizen. They are starting to alienate a HUGE swath of their USER BASE. Linux has come a L-O-N-G ways from its early days, and Red Hat is NO LONGER the ONLY Game in Town. There is nothing that prevents say a Rocky Linux, or Alma Linux, et. al. from breaking away from this “Bug-for-Bug” copy of RHEL, if RHEL breaks so many things and introduces so many bugs, that RHEL is no better than Windows.
Red Hat succeeds only because it had invested in creating a strong, and technologically savvy Community, in return they bought loyalty to their brand and way of doing things. They created a lot of good will. Remember the ad campaign of IBM 
Linux that was spray painted on sidewalks everywhere?
Red Hat needs a time out. Instead of forcing itself on its users, it needs to start slowing down a bit and allow users to catch up. It needs to ensure that RHEL plays well with KDE even if they now only OFFICIALLY support GNOME – you simply don’t turn your back on a DE the size of KDE, a DE that YOU once supported until rather recently. Red also needs to rebuild its bridges to its formerly vast communities. I can forgive Red Hat many things, but I can not forgive them of their recent treatment of the CentOS Community.
1 Like
OK, let’s put it another way. I buy a car from Ford, Opel, GM, whoever. I then decided to modify it by chipping it and increasing the power. Because of modifying/customising it, and now my engine management light comes on and I have errors - does that mean it’s Ford, Opel, GM’s fault? Or is it my fault for chipping the car and increasing the power when it wasn’t designed for that?
So RHEL is Ford, Opel, GM, and KDE/Cinammon is chipping and customising when it wasn’t designed for that. Had the system/car not been customised, the bug/engine management light would not have appeared. That said, the bug most likely would have appeared on distributions that did include KDE by default and the bug would have been fixed, be it in the kernel or whatever.
That now goes back to, had the updates been done later, once the problems had been fixed, then you would also never have seen them once the bug had been fixed in the kernel, or wherever the problem lies. Technically it could also have been the display manager that had the bug.
The reason why RHEL is seen as a stable and reliable distribution is purely the fact that the cut down the amount of packages, and support what they want to support. That means they can concentrate far more on a smaller amount of packages. If they had to support every single bit of software out there, it would be far less stable than concentrating on a smaller package set to ensure there is stability. If that means they choose Gnome instead of KDE, then fair enough. It could have been the other way around, KDE being the default, and then people complaining that Gnome doesn’t work because RHEL didn’t include it. RHEL also doesn’t force you to use their system. You can choose to use it or not. If something doesn’t work for you there are plenty of other choices.
There are plenty of distros out there that have KDE by default. So people could also complain why don’t you include a desktop as huge as Gnome? There’s no logic in that whatsoever just because one or the other desktop you personally prefer more than the people who developed the operating system in the first place.
Each distribution makes choices on what software they do or don’t include. I could be angry that Debian 11 didn’t include PHP 8.x when they decided not to and left it with PHP 7.4. Especially since Debian 10 was PHP 7.3, why didn’t they make a bigger jump to support a version of PHP with a longer EOL than PHP 7.4.
1 Like
If there is a bug in RHEL 8 kernel due to backports that RH does, that bug won’t show up in other distros as they won’t use that kernel. As long as the bug does not affect RHEL 8, it could linger there. Didn’t ‘sudo’ had a vulnerability due to optimization that was added a decade ago? Naturally, now that RH apparently is aware of “weakness” in their kernel, they should have incentive to make it better.
If Ford/Opel/GM uses cheap components in their cars that are barely enough for the design, they are not at fault as the cars “work”. However, that can affect their reputation and guide customers to other brands, which is fair.
There is. The entire reason of existence for the bug-for-bug copies is to be such copies. Oracle has a partial copy – different kernel; they already offer different bugs.
Sorry, but GRUB2 seems better than legacy GRUB and the BLS – you can disable the BLS if you don’t like it. I do like it and have not seen anything to break. In fact, I see BLS as an improvement.
DNF modules is something that failed more clearly. Nice idea though. RHEL 9 will have less modules.
The point was if the car uses components designed for say 100-150bhp, then to then modify it to 200+bhp then puts it outside of the area that it was meant to be in. In such a situation that’s not Ford’s fault since it wasn’t designed to take that amount of power. At which point you should be changing far more components to ensure the reliability, but then that responsibility lies with the person making the changes, rather than Ford 
Ah no Ian, the bug this time, by the sounds of it, relates to something all other participants can reasonably expect to rely on: “qt (and perhaps something else) rightly assumes that if the kernel supports P_PIDFD …”
If MS released a version of Windows that fell over if you installed a non-EDGE browser the world would be up in arms and rightly so. If I installed an industry standard alarm in my car and it stopped working because the car manufacturer had messed up the cars electrical system so it was non-standard then I would be fully justified in “havin’ a go”. The bug can by the sounds of it affect a lot more that sddm. I’m surprised it was released given the concern over side-affects to the fix when there are likely to be other side-affects to the bug and it was identified pre-release. Sounds like any Qt application might be affected.
What if I’m an sddm or KDE developer working on a licensed RHEL developer workstation ? I have every right to not expect these issues.
Less important than to find party that is at fault is to ask who can and will fix the mess?
Interesting, CentOS Stream 8 repo:
kernel-4.18.0-365.el8.x86_64.rpm 2022-02-10 17:54
kernel-4.18.0-373.el8.x86_64.rpm 2022-03-22 17:34
The RHEL 8.6’s 4.18.0-372 has apparently never been seen in the Stream …
Well, if RHEL think “not supported” gets them off the hook it might take longer to see the fix in than if we can pin the blame there … priorities and all.
I imagine if all tests pass after the fix goes in we’ll see it pretty soon and in the meantime make do with GNOME… alternatives are even more grim…
But the real worry is how unstable your working environment is if you choose KDE and this can happen.
I’m with you. The work around to the sddm problem is to switch to LightDM. The install on jaguar went smoothly, but the install on ocelot saw everything from the Black Screen, to a problem with the Network… or lack thereof. I finally threw in in towel and rolled back 8.6 => 8.5 by doing a total restore of the nvme0n1 drive. What I think I am going to do is drop back 10 and punt: I’m going to logout, then reboot into openSUSE 15.3 Leap. I’ll keep tabs on the RHEL / RL 8.6 SNAFU via jaguar aka the “Kitty Litter Box” which is currently running RL 8.6.
Catch you guys on the flip side in about two weeks, when I hope Red Hat has fixed this mess …assuming they plan to fix this mess.
D’ Cat
If Qt (provided by RHEL) relies on kernel (provided by RHEL) and that dependency has a known malfunction, then RH really should modify one or both as both are in their “problem domain”. KDE is far from only program that depends on Qt and some are commercial – there are many 800lbs monsters out there.
Well… I think they should just leave Qt alone and fix the kernel but yeah…think about all those corporate and govt/defence Qt developers out there and the auto trade… this could cost them $millions in chasing bugs that aren’t really there… or fixing bugs they didn’t see because of it or hold ups in release schedules relying on it. I would hate to be the person at RHEL responsible for this … I feel for them, I do. I’d get it sorted and outta sight asap.
I had forgotten that QT was part of KDE/Plasma. That alone makes me want to run for the hills.
As soon as I have some headspace and time, I’m back to gnome.
If the kernel previously supported this P-PIDFD or whatever it is, then yes it would be RHEL that need to fix the kernel since if that is the case, it was supported, and then suddenly the option disappeared. However, if the previous kernel didn’t have it, then it means whatever newer QT/KDE packages have appeared have been incorrectly prepared with an option that wasn’t there before. That then means some kind of inconsistencies between teams not talking to each other to ensure that the kernel supports what the QT team requires or vice-versa. So whichever way you look at it, a bit messy.
From the other side though, is it possible to still have a fully functional QT/KDE without that option. If so, then it’s far easier to fix the QT side, since the core of the system is the kernel. QT/KDE is not the core of the system, since a server without a GUI environment still has a kernel, but it doesn’t have QT/KDE. A QT/KDE environment like a basic server also has a kernel as without it the system wouldn’t have booted. Making a kernel change affects every single system. Whereas making QT changes affects far fewer systems.