Well I guess I didn’t really break it. A KDE update broke it. After updating I rebooted, and then when I tried to log in, the screen went black and got stuck like that.
Anyway, I read on the forums that the fixed involved adding a parameter to some line in the kernel options, which I had no clue how to do. I also didn’t know I could enter the terminal from a frozen screen. So I tried the grub menu. But I didn’t know what I was doing and was scared to mess things up, and for some reason I thought the answer was in the UEFI screen.
Now I knew that I was treading in dangerous waters, so I was trying not to touch anything while poking around the menus trying to figure out where I needed to go. But apparently I touched something I wasn’t supposed to, cause my computer tried booting from the spare SSD, which isn’t mounted yet and don’t know how to decrypt it. So I got stuck for a while, tried the grub rescue in the command line because it was the only option I seemed to have, didn’t understand it, panicked for a while, and eventually found out I could press f2 on startup to go straight to the UEFI screen. So then I went back to the menu where I messed things up and made sure to click on the correct disk.
So I was quite relieved when I was able to decrypt it and it brought me back to the Endeavour grub menu (the purple screen), and then booted up as it was supposed to. I tried logging in again and it still froze, but at this point I had learned I could press some hotkeys to get to the terminal. So I went in there and followed some instructions I found, ultimately only really learning what the problem wasn’t. It turns out the parameter I was supposed to add to fix the issue was already there!
So I found out how to revert kde desktop and workspace to a previous version from the cache, and I did that, but when I rebooted and tried logging in again it still froze.
Luckily I had previously made a guest account so I logged in there and it worked. So then I learned that that means the issue was in the user-level configurations.
So I followed some more instructions to back up my KDE configs, moved the existing ones to somewhere else, then killed and restarted plasmashell to create new default config files.
And then I tried logging in, and it worked! This was an hours-long process, so it definitely felt good to have a working system again.
Luckily most of my settings and my favorited items in the app launcher were still intact. I hadn’t moved my global shortcuts config file either, so my keybindings were preserved. The only things missing were my pinned icons on the app manager toolbar at the bottom of the screen.
So I went into my backup file for the plasma appletsrc configs, and I found the line that listed the apps I had pinned, and I copied it and used nano to paste into the current version in same place it would have been.
So even though it was tragic and frustrating and a bit gut-wrenching at times, I learned a LOT today. I gained some familiarity with grub, UEFI, terminal, basic shell commands, restoring previous versions of software from the cache, logging and troubleshooting, backups, configurations, and the basic system architectures, and the anatomy of the KDE environment.
I’m still no power user, and I still have a lot to learn, but I came a long way in just one day. Now, I’m tired.
There’s lots more to set up tomorrow, but at least walking into it I won’t feel so lost!


It’s great at pointing you in the correct direction. As a Linux newbie myself, I’ve been through similar things as OP and used llms to help me debug the issues, but almost every time it suggested something a bit more complex than your average command, it was wrong. Luckily, I never trusted the output from the llms, but it got me so far, that I knew what to search for in forums and then get the right solution.
Yeah, I use it as a “downsing rod” as well. Points me in the right direction, but I still prefer verifying stuff myself by going to the proper pages. It’s often I find out that the LLM is just plain wrong.