Four Hours with Fedora Kinoite: A Well-Intentioned Detour

6 Jan 2026

I’ve been running Fedora 42 Workstation for a while now, and with Fedora 43 on the horizon, I was planning my usual upgrade routine. But this time, I decided to take a different path - one I’d been curious about for quite some time: trying an atomic desktop.

Why Atomic?

My interest in atomic desktops isn’t just idle curiosity. While it’s been years now, I’ve had my share of stability issues with Linux in the past. Those experiences, though distant, still linger in the back of my mind. The promise of an immutable system - one where the chances of breaking something irreparably are significantly reduced - is genuinely appealing.

Since I was going to upgrade anyway, this seemed like the perfect opportunity. Why not try Fedora Kinoite and see what this atomic desktop business is all about?

I’ll be honest: I had no real expectations. I’d never used an atomic desktop before, so I couldn’t form any. What I did assume was that managing the system would be different, and that it would be more resilient to breakages. Beyond that, I was going in blind.

First Impressions

Kinoite impressed me right out of the gate. The installation was incredibly quick, and startup times were noticeably fast. Everything worked right out of the box, which is always a good sign.

Then came a pleasant surprise: I connected my existing home drive to the fresh Kinoite install and rebooted. When the system came back up, my desktop was configured exactly as it had been on Fedora 42 Workstation. Everything - my KDE settings, my customizations, all of it - just there.

This isn’t a Kinoite-specific feature, mind you. It’s one of the fundamental advantages of how Linux handles configuration. Unlike Windows, where the registry needs to be populated by installing software, Linux stores configuration in text files. When those files are in the expected locations (your home directory), any Linux system will pick them up. This is where Linux genuinely excels, and it made the transition seamless.

Where Everything Fell Apart

Here’s where my four hours with Kinoite turned from exploration into frustration. What should have been simple became an exercise in fighting the system.

The Shell Configuration Saga

I wanted to use Zsh as my default shell instead of bash. On Workstation, this is straightforward - install Zsh, run chsh, done. On Kinoite, it became an odyssey that consumed the majority of my time.

First problem: I needed to install Zsh. Fair enough, I installed it with rpm-ostree install zsh and rebooted. But then I discovered that terminal emulators on Kinoite don’t respect the default shell setting in /etc/passwd. Running chsh or lchsh changed the file correctly, but Kitty and Konsole both continued launching bash.

The workaround? I had to explicitly configure the shell in each terminal emulator’s settings. Kitty needed shell /usr/bin/zsh in its config file. Konsole needed the shell set in its profile settings. On regular Fedora, this just works - change your shell, and terminal emulators respect it. On Kinoite, you’re fighting against the system design.

Second problem: I learned that packages installed with rpm-ostree only exist on the host system. They’re not available inside toolbox containers. This makes sense architecturally, but it was a surprise. If I wanted Zsh in a toolbox, I’d need to install it separately inside that container with dnf.

Third problem: Even after installing Zsh inside a toolbox container and using chsh to set it as the default, bash kept launching. The /etc/passwd file inside the container showed the correct shell, but it didn’t matter. Why? Because toolbox inherits the $SHELL environment variable from the host system, and that takes precedence over the container’s password file.

The workaround? Use toolbox enter --shell /usr/bin/Zsh every time, or create an alias to wrap it. But this felt like I was fighting against the system at every turn.

The Bigger Picture

None of these issues are bugs, exactly. They’re consequences of the architectural decisions that make Kinoite immutable and atomic. The system is designed to keep the base OS minimal and unchanged, with containerization for everything else. Terminal emulators not respecting /etc/passwd is a known limitation. Toolbox inheriting environment variables is by design. Package separation between host and containers is intentional.

But for something as fundamental as “I want to use Zsh as my shell,” having to:

Layer it on the host with rpm-ostree and reboot
Configure each terminal emulator individually
Install it separately in each toolbox
Work around environment variable inheritance
Use command-line flags or aliases to make it actually work in containers

…felt like far too many hoops for such a basic task.

I spent hours troubleshooting this, consulting documentation, and working through each layer of the problem.

The Positives

Despite my frustrations, Kinoite did some things remarkably well:

The installation was incredibly quick
Startup times were impressively fast
Everything worked right out of the box
The atomic update system is genuinely clever
The documentation is thorough (even if the answers weren’t what I wanted to hear)

My Takeaway

If something as fundamental as changing my default shell requires this many workarounds and architectural compromises, then Kinoite - not atomic desktops in general, but this specific implementation - needs more polish before it’s ready for me.

That’s the critical distinction: this is about me and my workflow. I’m certain many people are running Kinoite happily and successfully. The atomic desktop paradigm makes perfect sense for certain use cases, and I appreciate the engineering that went into it. But for the way I work - where I expect my shell choice to just work across the system - the friction was too much.

What’s Next

I’ve gone back to my Fedora Workstation installation. Tomorrow, I’ll do what I originally planned: upgrade to Fedora 43 the traditional way, where dnf is available directly and changing my shell doesn’t require a systems architecture degree.

But this isn’t the end of my atomic desktop journey. I will try Kinoite again in the future, though it won’t be for some time. The project is actively developed, and these issues may be addressed. I’m also watching KDE Linux with interest - once it matures a bit more, I may give that a go instead.

Kinoite introduced more friction than I was prepared to handle, but it hasn’t scared me off atomic desktops entirely. It’s reminded me that not every promising technology is ready for every user’s workflow, and that’s okay. Sometimes the cutting edge cuts back.

Advice for Others

If you’ve never used an atomic desktop before and you’re thinking about trying Kinoite, here’s my recommendation: try it on a secondary system first. Don’t make it your daily driver until you’ve spent some time understanding its quirks and workflow differences. Specifically:

Understand the difference between rpm-ostree (system packages) and toolbox (containerized development environments)
Be prepared for terminal emulators not respecting your default shell setting
Know that packages on the host aren’t available in toolbox containers
Plan for containerized workflows rather than traditional package management
Have a backup plan if things don’t work the way you expect

The atomic desktop paradigm is genuinely interesting, and I believe it has a real future in Linux. The stability benefits are real, and the rollback capabilities are impressive. But like any significant architectural change, it comes with trade-offs - and sometimes those trade-offs affect basic workflows in unexpected ways.

For me, the shell configuration saga was the deal-breaker. For you, it might not matter at all. That’s what makes Linux great: we have choices. Kinoite is one of them, and for some people, it’s the right choice. Just make sure you understand what you’re signing up for before you commit.