Closed bam80 closed 2 years ago
Hi @bam80 can you describe the procedure you followed to do it on toolbx? how did you do that?
Generally speaking the wayland (or x11) socket is mounted inside the container so potentially can work, as all other single graphical applications are working
I'll see how it's done exactly on my Fedora SB machine, but the idea is you tweak Display Manager .desktop
file where you put your toolbox command to start the container.
On my other machine (without toolbox) the custom entry for Display Manager to start Plasma Dev session looks like this:
$ cat /usr/local/share/wayland-sessions/plasmawayland-dev.desktop
[Desktop Entry]
Exec=/home/bam/kde/usr/lib/x86_64-linux-gnu/libexec/plasma-dbus-run-session-if-needed /home/bam/kde/usr/lib/x86_64-linux-gnu/libexec/startplasma-dev.sh -wayland
DesktopNames=KDE
...
oh ok so you have GDB (or SSDM) on the host, that launches KDE from inside the container right?
Probably something like this?
$ cat /usr/local/share/wayland-sessions/plasmawayland-dev.desktop
[Desktop Entry]
Exec=/usr/bin/distrobox-enter --name YOUR_CONTAINER -- /home/bam/kde/usr/lib/x86_64-linux-gnu/libexec/plasma-dbus-run-session-if-needed /home/bam/kde/usr/lib/x86_64-linux-gnu/libexec/startplasma-dev.sh -wayland
DesktopNames=KDE
...
You got the idea. Can you try this? I'll provide any assistance needed since I have working setup.
Will try sure, just to be sure, this is not ran while you're already logged in, but you log out and select a new voice from the display manager
Yes. You can always run Nested session, though. But that is a bit other topic.
@bam80
Good news, it works Bad news it needs some work :sweat_smile:
As you can see here, I'm on Fedora Silverblue, with a fedora-toolbox image (EDIT: tested OCI fedora:35 and ubuntu 21 also), and Plasma installed inside the toolbox Exported the session file to /usr/local/share/wayland-sessions:
[Desktop Entry]
Exec=/usr/local/bin/distrobox-enter -- /usr/libexec/plasma-dbus-run-session-if-needed /usr/bin/startplasma-wayland
DesktopNames=KDE
Name=Plasma (Wayland)
X-KDE-PluginInfo-Version=5.23.3
Exporting the plasma-kactivitymanagerd.service
from the container (distrobox-export did work with a little patch) and enabling this service
Setting the owner of /tmp/.X11-unix to your $USER so that it's mapped correctly in the container
and... well it worked :smile:
Nice. I didn't do those additional steps, though. Also, I see you run it in QEMU, I suppose it also runs natively.
Yea running in QEMU to test on a plain Silverblue host
Interesting you didn't have to do the additional steps, I wonder how toolbx managed to start the systemd service and fix the permission
That's why my thoughts we don't need two projects ;)
That's why my thoughts we don't need two projects ;)
That's not the point really
I've tested toolbx in parallel to set this up The /tmp/.X11-unix permission problem persists (that's obvious, as the rootless user mapping does not map host's root) The systemctl service has to be exported and started to work, as PID1 is not systemd even on toolbx (and toolbx does not probide a way to export it) The desktop session file has to be done anyway
After all that, it worked also on toolbx, well the same as distrobox
so, what's the point of this comment?
The systemctl service has to be exported and started to work, as PID1 is not systemd even on toolbx (and toolbx does not probide a way to export it)
Otherwise, the session doesn't start? I don't remember I did anything other than the desktop session file.
The session starts, as it launches kwin_wayland correctly (could launch apps from terminal and move windows), but plasma-desktop does not start (so applets, taskbar etc etc) as, it depends on this plasma-kactivitymanagerd running I'm not an expert of kde, just saw that in the logs, exported the service, activated it and the full desktop started working
No, it started for me normally.
Well not for me on toolbx on a fresh Silverblue host created right now :shrug: it behaves in the same way as distrobox.
If you do not fix the permissions on the /tmp/.X11-unix directory you get:
kwin_xwl: /tmp/.X11-unix is not owned by root or us
And kwin segfaults, it works correctly after setting the permission. Fixing the permissions will make the session work, but only kwin will be shown.
Starting (either manually or using the service export) /usr/libexec/kactivitymanagerd will make the plasma-desktop start correctly.
That's the exact same steps I had to do on both
Don't really know what to say How did you install KDE?
I just did
sudo dnf groupinstall KDE
Probably something different between the two installations Can't really say about this, but I can confirm toolbx and distrobox behave in the same way in this use case, so either there is a difference in how we install KDE or you did some tweaking and you don't remember it :joy:
Either way I'm glad you brought up this use case, I didn't even think of using it like this :smiley:
or you did some tweaking and you don't remember it
That might possible be. Either way, my tweaks was not as yours, for sure :) I definitely didn't do anything with kactivitymanager..
Maybe something from this stuff: https://gitlab.gnome.org/fmuellner/silverblue-stuff
kactivitymanager
Seems an hard dependency for plasma-desktop to start, if I stop this process (kill -9
it for example) the desktop will still work, seems a dependency only on start of the desktop
Anyway without it, it will not start :shrug:
I wonder if you're using a different version of plasma that maybe does not hard-depend on this, or that autostarts it without other tweaks For example, why is it not part of the kwin_wayland launch script, or why it's not in the autostart as desktop file
Either way that has nothing to do with either distrobox or toolbx
I created 2 identical Fedora Silverblue 35 VMs, one with distrobox, one with toolbx, launched the same sudo dnf groupinstall KDE
and they both showed the same behavior, so this has nothing to do with having 2 project :smile:
Maybe something from this stuff: https://gitlab.gnome.org/fmuellner/silverblue-stuff
.. or this: https://blogs.gnome.org/fmuellner/2020/03/02/shell-hacking-on-silverblue/
Interesting, they are creating a whole new dbus session for this, I imagine this is for having nested GNOMEs (like the testing one appears in a window)
Anyway in the scripts there is the creation of the desktop sessions file, remounts a lot of stuff for udev and systemd (this is not needed on distrobox) and then launching the nested session of GNOME
This is different from what we were doing here with KDE (launching a full fat session login), but either way there was a lot of tweaking involved in toolbx too to do this stuff, which would obviously be needed on distrobox also (maybe a little less, but comparable)
Little update
Tested the same procedure with Centos8 (plain) an OCI fedora rawhide container and GNOME (installed with sudo dnf groupinstall GNOME
)
The only tweak that was needed was this inside the container:
rm -rf /run/systemd/{seats,sessions,system,users}
ln -s /run/host/run/systemd/{seats,sessions,system,users} /run/systemd
That's taken from here: https://gitlab.gnome.org/fmuellner/silverblue-stuff/-/blob/master/sb-gnome-shell-setup.sh
The .X11-unix permission/owner is not a problem on GNOME, but the access to systemd/logind is mandatory, hence the setup needed above
After that just create the session's desktop file, and that's it, latest gnome 42 inside fedora-rawhide, from centos 8 host :+1:
Great, I'm glad someone finds my experiments useful! (However, for me it was not just experiments but working environment).
It would be good if we can narrow the problem with Plasma down to KActivitymanagerd, then we could create an issue on their Gitlab.
Idea: How about document you finding to run these DE's in Toolbox/Distrobox somewhere in Wiki here?
Great, I'm glad someone finds my experiments useful! (However, for me it was not just experiments but working environment).
Glad to receive all this feedback on the project, that's how nice ideas come up :smile:
It would be good if we can narrow the problem with Plasma down to KActivitymanagerd, then we could create an issue on their Gitlab.
I'm not a lot into KDE, always been a GNOME user, so I'm not sure if this is intentional or not, I've came up with a much simpler solution (adding the process to /etc/profile.d/kde-init.sh) to not to fiddle with systemd
How about document you finding to run these DE's in Toolbox/Distrobox somewhere in Wiki here?
Absolutely, I'm planning to do a wiki with some use cases already explained with examples :smile: but will take some time
As per https://github.com/89luca89/distrobox/commit/a903d4220526838ab88499c75586f9d7d5a4d124 this is now documented in the docs/wiki
Closing this if there are new ideas let's discuss in a new issue :smile: Thanks again @bam80 for the idea!
Does this project target to be able run full Desktop Environment Wayland session from a container? I was able to run KDE Plasma session from within Toolbox, maybe could be automated here..