[Solved] Installed KDE Plasma Workstations Group, No Login Shell?

Hey All,

I’m running f40 Workstation, which of course is synonymous with saying I’m running the Gnome DE. After reading through the documentation, I thought I’d load up KDE Plasma Workspaces to take quick look at what the KDE Plasma DE was about.

Unfortunately, I did not look here first to see if there were issues that were unresolved with doing then undoing that on Fedora Workstation. There are. :frowning: But, I guess, that is a concern that can wait till another day.

One thing I’d still like to understand, though, is that it doesn’t appear that my KDE Plasma session is being started as a login session. That is, judging by the fact that none of the environment variables that I define and export in my ~/.bash_profile are being pushed to the kitty terminal windows I open from the desktop.

I took a quick breeze through my system journal for current boot, and I see that gdm is still being run at the start to handle the login, and that there are some gnome processes still being started at boot time, and there’s even a brief appearance made by gnome-shell. I don’t know if these processes are conflicting with any of the Plasma-related ones, but maybe others who have a better handle on starting Plasma organically vs via a modification to a machine with a native Gnome setup wouldn’t mind commenting on whether they’d seen this effect themselves, and whether they knew of a workaround.

Many thanks!

I’d guess that gdm AND sddm are both enabled at the same time. You’ll want to disable one.
Check with systemctl status <service>

Looking at this, it’s just running gdm, or, rather, gdm-session-worker. It also looks like everything gets run in a logical order from there: First , gdm-wayland-session, then startplasma-wayland, and then kwin_wayland. So everything looks fine. It’s just that nothing in this lineup appears to run either my ~/.bash_profile or my ~/.profile. Note that the latter is just a symbolic link to the former.

I’ve just installed KDE in a VM, a great way to test things first ;),
with dnf install @kde-desktop-environment.
sddm is disabled. Fedora makes sure that only one display manager is enabled. I can get a KDE session with GDM after selecting the plasma session. It needs wayland! There are kwin-x11 packages available, but they are not yet available for the newly releases kde6.1.

I also created a NEW user for KDE, because GNOME and KDE share settings and overwrite each others settings.

I agree that the VM method is a good one. Unfortunately, my machine is memory limited, so that is impractical for me.

Anyway, things do run okay for me, at least on the surface, save for this business with the login shell failing to run as a login shell.

I think that this whole KDE Plasma thing may well be a future full-time DE for me, so a clean install of Kinoite may be the answer long term. Prior to that, though, I’d like the possibility of exploring other options from my now-tangled Fedora Workstation-installed system.

So what do you see when you login with gdm? A blank screen or what?
What happens if you switch to sddm instead of gdm?
Maybe create a new user for the kde login.
Normally, there is no need to add anything to .bash_profile or .profile for GNOME or KDE.

sudo systemctl disable gdm
sudo systemctl enable sddm
reboot

You did select the plasma session in gdm?

I see the gdm-style greeter, and I select Plasma from the gear at lower right corner. There’s no blank screen, and it logs me in normally to a Plasma session. On the surface everything looks fine.

The only way i began to notice the business about my login session not running my shell ~/.bash_profile was that I went into visual edit mode in less and it kicked me into vi. I have both EDITOR and a VISUAL environment variables set and exported in that file. Later I learned that none of the environment variables are getting set and exported, so concluded that the top level desktop process is not being run as a login session.

A bash in a kde terminal shows exported variables defined in .bash_profile.

Does this also happen if you export in .bashrc instead?

If I did this exporting in .bashrc, I’m pretty confident it would work. I’d just like to understand why I need to do it that way.

yeah, it’s the better location for env variables evaluated by interactive sessions.
A shell is not necessarily started by graphical terminals as a login shell. I think you can override this with a new Konsole profile.

Can you reproduce with a new testuser?

If you enable sddm instead of gdm, then some process will source .bash_profile for you. But it’s never the shell started by Konsole, unless you create a profile and start bash with the -l option.

Similar it’s in GNOME, per default the Gnome terminal won’t start a login shell unless you change the profile.

No idea why this is not working with gdm to open the KDE session. Bug?

Oh, I understand that point, but thanks for covering that base with me!

I’m going to try the gdm–>sddm thing first.

Now I’m invested in figuring out why it’s not performing in the expected way, and how to go about looking at the relevant log files. I’ve got a thread going over in one of the KDE discussion forums. I’ll touch base back here if I get enough help to figure things out.

Thanks again for all the help and for brainstorming this issue with me!

Exporting in .bashrc leads to all sorts of hard to debug issues.
You cannot change any env var set in .bashrc interactively reliably.
Please do not do that.

For terminals it is good practice to configure the terminal to start a login shell so that it runs .bash_profile withbash -l as suggest above.

Yes, that’s easy enough to do, but vexing nonetheless. If the parent process of any terminal had already read the .bash_profile, then it’d be unnecessary. I have no idea if this is the source of other problems as I haven’t spent enough time with Plasma yet. I have already seen problems with no replacement for gnome-keyring, so I’ve got no ready ssh-agent connection; that probably holds for any connection to a gpg-agent, too.

For the time-being, I just do an exec /bin/bash -l in any terminal window. There may be other related effects that I’ll run into day to day, but I’m pretty sure that I’ll just do a new Kinoite install and be done with this hybrid thing. It’s already clear that my Gnome setup is completely hosed, so going back to that will also mean a bunch of work that is non-trivial, also.

One other thing that is pretty clear to me is that the simple “Switch to Another Desktop Environment” thing is a myth. The documentation should be amended to make that clear. It’s a path that’s very difficult to implement both forward away from Gnome to Plasma and backward to Gnome from Plasma. I suspect the same is true of others.

Is this under kde plasma?

For both these use cases the kde wallet is used under kde, not gnome-keyring.

Yes, it is. kwallet is running. The app prompted me for my user password, but gave me a cryptic message indicating that I had no stored keys. I just ignored that part.

But, when I used ssh to login to another machine, I got prompted in the terminal, no gui widget, for my ssh key’s password. I connected to the remote machine, then exited back to local and re-ssh’d. I was again prompted in the terminal cli for my ssh key’s password. I didn’t reflect on that much; just shrugged and moved on. :slight_smile:

Thanks for clearing up kwallet’s role for me!

You need to do a small amount of set to have ssh use kwallet.

I have this in my .bash_profile


# need to setup ask pass even if not using a terminal
# as is the case when KDE is logging in
if [ -e "${SSH_ASKPASS:=/usr/bin/ksshaskpass}" ]
then
    export GIT_ASKPASS=${SSH_ASKPASS}
    export SSH_ASKPASS
fi

Also if you want to load the ssh keys at login you can add a kde start up script like this in system-settings. I have two ssh keys at the moment so I load both.

$ more bin/kde-startup-tasks
#!/bin/bash
# always have the SSH keys loaded
ssh-add ~/.ssh/id_ed25519 </dev/null
if [ -e ~/.ssh/id_github_ed25519 ]
then
    ssh-add ~/.ssh/id_github_ed25519 </dev/null
fi

The </dev/null causes ssh-add to use the GUI prompt for the pass phrase.

The first time you login and this script runs it will prompt you to add the passphrase for each key that is added.

Thanks for the tips on how to use kwallet!

Now I just have to figure out how to get my .bash_profile read at login time. :slight_smile:

You wouldn’t happen to know if there’s a file that’s produced during login where the initial plasma session is recorded? I’m thinking here of something like the log files that startx, e.g., used to produce.

Mine is read at login.

I added some debug to my .bash_profile to see what the process tree is when its run on KDE login.

This is what I added to .bash_profile:

echo "bash_profile running at $(date) pid $$" >>~/tmpdir/bash_profile.log
ps afx >>~/tmpdir/bash_profile.log

This is the what I see in the log file:

   4013 ?        Ssl    0:00 /usr/bin/sddm
   6705 ?        S      0:00  \_ /usr/libexec/sddm-helper --socket /tmp/sddm-auth-a0804cea-6bac-401d-80e2-378dc7869080 --id 4 --start /usr/bin/sddm-greeter-qt6 --socket /tmp/sddm--eJpgWk --theme /usr/share/sddm/themes/breeze --user sddm -
-display-server kwin_wayland --no-global-shortcuts --no-lockscreen --inputmethod maliit-keyboard --locale1 --greeter
   6889 ?        S      0:00  \_ /usr/libexec/sddm-helper --socket /tmp/sddm-auth-a0804cea-6bac-401d-80e2-378dc7869080 --id 3 --start /usr/libexec/plasma-dbus-run-session-if-needed /usr/bin/startplasma-wayland --user barry
   6903 tty3     Ss+    0:00      \_ /bin/bash --login /etc/sddm/wayland-session /usr/libexec/plasma-dbus-run-session-if-needed /usr/bin/startplasma-wayland
   6944 tty3     R+     0:00          \_ ps afx

sddm runs a bash --login to boot strap plasma wayland and anything I setup in my .bash_profile is available to all processes.

Edit: How does this work?

It looks like systemd --user records the envirorment it is started with.
It does no run with that environment, its run with a cleaned up one.

But when it starts services their environment is setup to be the environment
that was present when systemd --user was started.

Yes, I’m certain that it’s because you’re running plasma natively from a Kinoite install. I’m doing a hybrid DE change from a Fedora Workstation install.

Nothing in the “simple” desktop environment change is seamless that I’ve been able to find. Selecting Plasma at the gdm greeter doesn’t invoke the command line you show. Trying to disable gdm.service/enable sddm service sends me to a Gnome DE. I could find no obvious way to switch to Plasma through something similar to the gear I see in gdm.

I was hoping to be able to switch DEs at will, but I don’t see how that’s going to happen easily. It’s going to take committing to one or the other.

For the time being, though,during the eval period, it’s pretty good if it’s all that can be mustered. I’m liking what I see with Plasma so far. Maybe that’s the real point.

Thanks for your help!