KDE Black Screen when changing shell to bash

Issues & Assistance
1

Hi all! I’ve been searching for a solution to this one for days now and while similar issues are around, nothing seems to match.

I’m an old soul on Linux but have been away from it for about 15 years. Came back to CachyOS and loving it - except for the fish default shell. When I change my default user shell to bash and restart, KDE Plasma gives me a black screen after I login. If I login with root (which uses sh) the desktop environment loads immediately. When I change back to fish (no other changes) I can restart and login with my user account.

Debug info / steps:

I can reproduce this every time by chsh -s /bin/bash and then revert by chsh -s /bin/fish myusername when logged in as root.

Manually invoking bash from the fish shell loads bash with no errors and I can use it just fine.

journalctl -b -1 | grep error shows no errors.

Going through journalctl during the time I restarted shows nothing problematic (that I can see) and everything seems to be loading. Between 11:05 and 11:07, I just left it on blackscreen before manually rebooting.

Apr 21 11:04:51 Cachy-COW bluetoothd[923]: Endpoint registered: sender=:1.39 path=/MediaEndpoint/A2DPSource/o>
Apr 21 11:05:11 Cachy-COW systemd-timesyncd[686]: Contacted time server 162.159.200.123:123 (time.cloudflare.>
Apr 21 11:05:11 Cachy-COW systemd-timesyncd[686]: Initial clock synchronization to Tue 2026-04-21 11:05:11.04>
Apr 21 11:05:11 Cachy-COW systemd[1]: systemd-hostnamed.service: Deactivated successfully.
Apr 21 11:05:12 Cachy-COW systemd[1]: systemd-timedated.service: Deactivated successfully.
Apr 21 11:05:20 Cachy-COW systemd[1]: systemd-localed.service: Deactivated successfully.
-- Boot d2c1e7f38dc44a9db6718056af29535a --
Apr 21 11:07:40 cachyos kernel: Linux version 7.0.0-1-cachyos (linux-cachyos@cachyos) (clang version 22.1.3, >
Apr 21 11:07:40 cachyos kernel: Command line: quiet nowatchdog splash rw rootflags=subvol=/@ root=UUID=e93c58>
Apr 21 11:07:40 cachyos kernel: BIOS-provided physical RAM map:

And here’s what’s happening immediately after login:

Apr 21 11:04:49 Cachy-COW plasmalogin[1031]: Message received from greeter: Login
Apr 21 11:04:49 Cachy-COW plasmalogin[1031]: start auth user true "/usr/lib/plasma-dbus-run-session-if-needed /usr/bin/startplasma-wayland"
Apr 21 11:04:49 Cachy-COW plasmalogin[1031]: Session "/usr/share/wayland-sessions/plasma.desktop" selected, command: "/usr/lib/plasma-dbus-run-session-if-needed /usr/bin/startplasma-wayland" for VT>
Apr 21 11:04:49 Cachy-COW plasmalogin-helper[1224]: [PAM] Starting...
Apr 21 11:04:49 Cachy-COW plasmalogin-helper[1224]: [PAM] Authenticating...
Apr 21 11:04:49 Cachy-COW plasmalogin-helper[1224]: [PAM] Preparing to converse...
Apr 21 11:04:49 Cachy-COW plasmalogin-helper[1224]: [PAM] Conversation with 1 messages
Apr 21 11:04:49 Cachy-COW plasmalogin-helper[1224]: pam_kwallet5(plasmalogin:auth): pam_kwallet5: pam_sm_authenticate
Apr 21 11:04:49 Cachy-COW plasmalogin-helper[1224]: [PAM] returning.
Apr 21 11:04:49 Cachy-COW plasmalogin[1031]: Authentication for user  "myusername"  successful
Apr 21 11:04:49 Cachy-COW plasma-login-greeter[1127]: Message received from daemon: LoginSucceeded
Apr 21 11:04:49 Cachy-COW plasmalogin-helper[1224]: pam_kwallet5(plasmalogin:setcred): pam_kwallet5: pam_sm_setcred
Apr 21 11:04:49 Cachy-COW plasmalogin-helper[1224]: pam_unix(plasmalogin:session): session opened for user myusername(uid=1000) by myusername(uid=0)
Apr 21 11:04:49 Cachy-COW systemd-logind[926]: New session '2' of user 'myusername' with class 'user' and type 'wayland'.
Apr 21 11:04:49 Cachy-COW systemd[1]: Created slice User Slice of UID 1000.
Apr 21 11:04:49 Cachy-COW systemd[1]: Starting User Runtime Directory /run/user/1000...
Apr 21 11:04:49 Cachy-COW systemd-user-runtime-dir[1228]: Successfully configured disk quota for UID 1000 on /dev/shm to 12.2G
Apr 21 11:04:49 Cachy-COW systemd[1]: Finished User Runtime Directory /run/user/1000.
Apr 21 11:04:49 Cachy-COW systemd[1]: Starting User Manager for UID 1000...
Apr 21 11:04:49 Cachy-COW (systemd)[1230]: pam_warn(systemd-user:setcred): function=[pam_sm_setcred] flags=0x8002 service=[systemd-user] terminal=[] user=[myusername] ruser=[<unknown>] rhost=[<unknown>]
Apr 21 11:04:49 Cachy-COW (systemd)[1230]: pam_unix(systemd-user:session): session opened for user myusername(uid=1000) by myusername(uid=0)
Apr 21 11:04:49 Cachy-COW systemd-logind[926]: New session '3' of user 'myusername' with class 'manager' and type 'unspecified'.
Apr 21 11:04:50 Cachy-COW systemd[1230]: Queued start job for default target Main User Target.
Apr 21 11:04:50 Cachy-COW systemd[1230]: Created slice User Application Slice.
Apr 21 11:04:50 Cachy-COW systemd-journald[578]: File /var/log/journal/676e41644e62457b875b37faf1b84e56/user-1000.journal corrupted or uncleanly shut down, renaming and replacing.
Apr 21 11:04:50 Cachy-COW systemd[1230]: Started Run arch-update auto check at boot and then once a day.
Apr 21 11:04:50 Cachy-COW systemd[1230]: Reached target Paths.

This one’s got me stumped. No idea how to even find what could be causing the black screen other than what I’ve tried above. It’s not exactly a major blocker, but I really do prefer my shells to be bashy and not fishy. The muscle memory alone for the bash shortcuts hurts me when I use fish.

Anyway, thank you in advance for anyone who replies and please let me know if there are more debugging steps I can perform and I would be happy to provide further info!

2

Hello and welcome,

I too prefer bash and that is what I use with Plasma.

My guess is something relied on is specific to fish.

In the users $HOME we might look for anything like .profile or similar that might be related. Similarly we could check in /etc/profile.d for anything fish-specific.

We could maybe narrow it down some also by creating and testing with a fresh user account.

4

Thank you so much for taking the time to respond. I created a new user and the default shell for it was bash. If only that were the case for the user created on install!

In any case, the new user can login without issue with bash as default.

There’s nothing odd that I can find on .bashrc, .bash-profile , .profile or /etc/profile.d (the latter two would be executed by the new user anyway).

Do you (or does anyone else) know of a way to check what is run post login? It really seems like something I’ve installed for just my user is being executed and it works on fish but not bash.

5

As an experiment, I also tried sh and zsh (man, never had a shell ask me so many questions before!) and both work! Definitely something with bash, but I can load a bash prompt without issue from fish, zsh or sh. Might be time to just get used to fish…

6

Glad to hear at least you are somewhat liberated.

It is interesting though.

On the affected user can you maybe dig around in;

find ~/.config/{environment.d,systemd/user/,plasma-workspace/env}/* -type f -exec head -n -0 {} +

systemctl --user list-units --all

I guess theres just a ton of plasma stuff in ~/.config really.

The source is of course still unclear .. its possible that something has some syntax that is not bash-friendly but happens to be acceptable in the other cases, for example.

7

Thanks again! I just found it… and I’d already missed it. I went back into my .bashrc settings and did a visual diff with the new Test User’s .bashrc just to see if maybe a path was being set in the Test User .bashrc that wasn’t on mine. Turns out on the last pass over that file my brain completely missed this:

My .bashrc:

set PS1 '[\u@\h \W]\$ '

Test user .bashrc:

PS1='[\u@\h \W]\$ '

The first is fishy syntax, the latter, bashy. I know this is exactly what you told me to look for, and I really did look for it. That line, however, is not something I remember adding to the file. Could it have been put there by the CachyOS installer? In any case, I just completely glossed over it mentally. Not to mention, the prompt matches the value set (since it’s the default, I guess) and source .bashrc showed no error. Again, setting the prompt is not something I care to add to .bashrc - especially since that setting is the default anyway.

Well, that was definitely the problem. Still scratching my head as to how that was ever included in my .bashrc in the first place - and why my default shell was set to fish when any new users created default to bash!

Thank you, yet again, @cscs for taking time out of your day to respond and my apologies for missing that when you clearly pointed to something just like that in your original reply!

8

Ah yes .. the set syntax is fishy.

No worries.
But now I still have some investigation to do to see if and/or how that gets deployed by default.

Glad it worked out. :+1:


Somewhat aside - but I still think the login shell should be bash or something closer to POSIX. And while I also think the default interactive shell should likewise be bash .. if it must be something eclectic then that should maybe be implemented via something like terminal emulator itself. In our case we already ship alacritty along with configs for it by default and it has an option for setting the shell. Regardless of which shell is a preferred default for userspace I believe that would be a better setup.