I Broke My Linux. Well, Once Again.

…and this one took me days to get back to my setup.

There are two types of Linux users:

Those who have broken their system.
Those who are about to.

I belong to a secret third category:

People who keep breaking the same system repeatedly and somehow never learn.

This week’s incident started with what I thought was a routine cleanup.

The Crime Scene

I was deleting random files to free up space.

You know the feeling.

You open your file manager.

You see a directory.

You don’t remember creating it.

You think:

“Surely this isn’t important.”

And then you hit delete.

The folder?

~/.local/bin

Now before every Linux user collectively screams at their monitor:

Yes.

I know.

I know that bin means binaries.

I know Linux stores executable scripts there.

I know deleting random directories under .local is a terrible idea.

And yet somehow my brain looked at:

.local/bin

and translated it into:

.local/recycle-bin-probably

The delete key was pressed.

The damage was done.

Everything Worked Fine…

For About 10 Minutes.

Then the weirdness began.

Commands started failing.

Applications behaved strangely.

Things that had worked for months suddenly didn’t.

At first I did what every developer does.

I ignored it.

Then I restarted.

Then I ignored it harder.

Eventually I reached the point where the system became unusable.

And after enough suffering, I launched OpenCode and started investigating.

The Symptom

The most obvious issue was my desktop.

I would enter my password.

The screen would flash.

Hyprland would briefly appear.

And then…

Back to the login screen.

Every single time.

No error.

No popup.

No helpful message.

Just:

Login
↓
Flash
↓
Logout
↓
Login
↓
Flash
↓
Logout

The Linux equivalent of being stuck in a time loop.

Before debugging, I had to understand what was actually supposed to happen.

On Omarchy, the boot sequence looks something like this:

Boot
 ↓
systemd
 ↓
SDDM
 ↓
uwsm
 ↓
Hyprland

The actual flow is:

systemd starts SDDM.
SDDM launches a Wayland compositor.
The login screen appears.
You enter your password.
SDDM starts uwsm.
uwsm prepares your environment.
Hyprland launches.
Your session starts.

Simple.

At least on paper.

What Actually Went Wrong

The culprit was a tiny file that no longer existed.

Inside my .profile was this line:

. "$HOME/.local/share/../bin/env"

Which resolves to:

~/.local/bin/env

Remember the folder I deleted?

Yeah.

That one.

The missing env script was responsible for setting environment variables used during login.

Once it disappeared, the entire startup chain started collapsing.

The Domino Effect

What looked like a graphical login issue was actually a missing shell script.

The failure chain looked like this:

.profile tries to source ~/.local/bin/env
           ↓
File not found
           ↓
uwsm env preloader fails
           ↓
wayland-wm-env service exits
           ↓
systemd tears down session
           ↓
uwsm exits
           ↓
SDDM thinks session ended
           ↓
Back to login screen

The entire disaster completed in under a second.

That’s why I briefly saw Hyprland before being kicked out.

It wasn’t crashing.

It was getting murdered by systemd because part of the login environment failed.

The Rabbit Hole Gets Deeper

While debugging this, I discovered three additional problems.

Because apparently one disaster wasn’t enough.

Problem #1: Wrong Wayland Command

Inside:

/etc/sddm.conf.d/10-wayland.conf

I found:

CompositorCommand=Hyprland

But it should have been:

CompositorCommand=start-hyprland -- --config /usr/share/sddm/hyprland.conf

This special configuration exists so SDDM can run a minimal Hyprland instance for the login screen.

Without it, the greeter looked weird.

Different wallpaper.

Different behavior.

Random visual inconsistencies.

At least now I knew why the login screen felt “off.”

Problem #2: Missing Theme Configuration

Another configuration file contained:

[Autologin]

And absolutely nothing about themes.

The correct version included:

[Theme]
Current=omarchy

Without it, SDDM wasn’t loading the Omarchy theme properly.

The login UI essentially had no instructions on how to render itself.

Problem #3: PAM Configuration From Another Dimension

Then came the weirdest discovery.

Inside:

/etc/pam.d/sddm-autologin

I found this line:

auth required pam_faillock.so authsucc

Repeated.

Five times.

auth required pam_faillock.so authsucc
auth required pam_faillock.so authsucc
auth required pam_faillock.so authsucc
auth required pam_faillock.so authsucc
auth required pam_faillock.so authsucc

I have absolutely no idea how this happened.

Past me apparently decided authentication stacks should resemble copy-pasted StackOverflow answers.

This duplication could potentially break password validation altogether.

Which certainly wasn’t helping.

Why Reinstalling Didn’t Save Me

My first instinct was:

Nuke.
Reinstall.
Move on.

Surely reinstalling Omarchy would fix everything.

It didn’t.

And here’s why.

User Dotfiles Survive

The broken .profile lived in:

~/.profile

Reinstalling doesn’t touch user files.

So the broken line remained.

SDDM Configs Persisted

The configuration files under:

/etc/sddm.conf.d/

weren’t fully replaced.

Some bad values survived.

PAM Was Still Corrupted

The PAM configuration remained untouched.

So even after reinstalling, authentication problems persisted.

The reinstall fixed almost nothing.

The broken pieces were all hiding outside the files being replaced.

The Real Lesson

This wasn’t actually a Hyprland problem.

Or an SDDM problem.

Or even a Wayland problem.

It was a shell startup problem.

One missing file:

~/.local/bin/env

managed to bring down an entire graphical desktop environment.

And that’s what makes Linux simultaneously beautiful and terrifying.

Everything is connected.

Everything is composable.

Everything is scriptable.

And deleting one tiny script can trigger a chain reaction across half the operating system.

How I’ll Debug This Next Time

After spending days digging through logs, I now have a checklist.

Check SDDM

journalctl -u sddm.service -n 100

Check User Session Logs

journalctl --user -n 100

Inspect Failing Services

systemctl --user status wayland-wm-env@hyprland.desktop.service

Look For Env Preloader Errors

If you see something like:

Env output mark not found in shell output
wayland-wm-env@hyprland.desktop.service failed

Start checking:

~/.profile
~/.bashrc
~/.zshrc

for missing files.

Inspect Core Dumps

coredumpctl list

This tells you whether the crash belongs to:

SDDM
Hyprland
The greeter
Your actual session

That distinction matters more than you’d think.

Verify Every Sourced File Exists

grep '^\. ' ~/.profile
grep '^source ' ~/.bashrc

Then manually verify every referenced path.

ls -la /path/to/file

This single step would have saved me multiple days.

The Golden Rule

If your shell configuration references a file that doesn’t exist:

source some-file-that-is-gone.sh

you’re creating a time bomb.

Maybe your terminal survives.

Maybe your IDE survives.

Maybe your desktop environment survives.

Or maybe your entire login session self-destructs before you can even reach your wallpaper.

Linux gives you infinite power.

Unfortunately, it also assumes you know what you’re doing.

And every few months, I prove that I absolutely do not.

Until next time.

Hopefully.

Though if history is any indication, I’ll be back here writing:

I Broke My Linux. Well, Yet Again.