this post was submitted on 05 Jul 2025
351 points (98.9% liked)
Linux
10254 readers
1136 users here now
A community for everything relating to the GNU/Linux operating system (except the memes!)
Also, check out:
Original icon base courtesy of lewing@isc.tamu.edu and The GIMP
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Yeah, I don't know who made the offending changes. I don't think it's fixed yet, I'm using a workaround at the moment.
I know the fix was up for testing, but I saw some people complaining about other issues with it and it wasn't rolled into the latest live update for me last I checked, so now I'm using a lock screen wallpaper that doesn't break and I'm not sure I have a way to tell when it's fixed other than manually checking.
Also, the error message suggesting a way to manually unlock using keyboard shortcuts to a virtual terminal does not match the defaults on my distro, so that added to the confusion.
Say what you will about Windows, but it was a stark reminder of the places where a single monolithic commercial owner would prevent some issues that can happen in Linux/open source projects. A commercial software developer would almost certainly not have shipped something broken in this way, and if they did they would have rolled it back in an update immediately. They also wouldn't have had a black screen with some tips on how to bypass the issue, presumably, and if they did they certainly wouldn't have been just... wrong, or mismatched.
Like I said, pros and cons, but it was a disappointing experience. Mostly because... well, yeah, I can understand what happened and troubleshoot it, but a) I didn't have the time, so I certainly was glad I am dual booting and could just flip to Windows for the time being, and b) a whole bunch of people would not have been able to troubleshoot this or comfortable tryign to do so even if the provided instructions in the workaround were accurate to their system.
And cloudstike did never happen...
I have Timeshift setup for fast and easy rollback.
Bad updates will happen to any OS. It is about if you want to update fast and having a rollback plan. There are dostros that updates more slow as they actually do their own testing and hence was not affected at all.
For me the lock screen instructions worked fine. The kernel update only broke Ghostty but a workaround fix was available the same day. I could also just have booted into the older kernel from Grub.
It did happen, but that wasn't an OS update, it was a third party update that bricked the OS. The fact that it could do that exposed some Windows practices that are a bigger deal than Linux's general jankyness when they happen, but they also surface less often for end users.
I thought this particular boo-boo was revelatory because Linux is relatively on the ball anticipating updates breaking the system entirely (one wonders if it should have to be, but whatever). But this was a widespread but specific issue within a random system component. Without googling for it an end user wouldn't immediately understand what's going on, and even then there was a fair amount of confusion for at least a day. There wasn't "a workaround", there were serveral, as normies and newer users struggled to understand what had broken and how to fix it, and people weren't very clear in reporting what worked and what didn't. This all happened within forums and bug reports, with no central source of information or even a centralized official organization informing of the status. Definitely not how that would have played out in a commercial environment, for better and worse.
Also, this is a slight tangent, but can I flag a couple of frequent Linux community behaviors you're engaging in here that I wish we would get rid of?
One, "it works in my machine" is a meaningless statement. It adds nothing to the conversation and it doesn't mean the issue is less important. It works on your machine, your version or your distro but not in others. That is every bug, it adds no useful information. In this case, a static screen contains specific instructions that report a common default but don't match implementation on every distro, so this warning screen isn't always accurate. That, in itself, is a problem.
Two, "here's all the smart stuff I did to fix it" (or the smart stuff I do to prevent it) is also entirely useless. The issue came and went, everybody fixed it. The goal isn't to work around the OS or the DE's jankiness, it is to have it not be janky in the first place. Putting the onus on the user to fix the shortcomings of the product is... a mitigation, I guess, but the goal is to compete with the paid alternatives on a mass scale, which has different requirements. Complaints about a wonky area of Linux shouldn't be dismissed or excused with offers to teach people manual workarounds or even best practices, they should be addressed with fixes from the developers of the components that have issues.
Bad updates don't happen on Bazzite. Immutable distros have solved this problem.
It is less likely to have. But software can still have bugs, big or small. The difference is just how much testing has to be done before you say it is good enough. Immutable dostros were not immune to KDE 6.0 bugs were if you upgrades from KDE 5 it completely broke. The issue were that you had to clear the cache in the users home folder for KDE. See Chris Titus YouTube channel about this were he did exactly this with Immutable distro.