Building wayland only desktop image with kairos ?

[j-landru]

Context: Using kairos as a polymorphic immutable system image builder (siac system image as code) for academic lab systems see ..., I continue to work episodically on the abcd lineage (Alpine image). Aware that this is a roundabout use of kairos, it's not a question of interfering with kairos design choices, just of sharing tips and asking kairos dev about advice or guidelines for adjusting kairos to this specific context. At the start of 2025, for desktop images I have to take into account the abandonment of the X11 display protocol for wayland exclusively.

About Wayland only desktop

As all major desktop environments are now completely moving away from the X11 protocol to the Wayland/XWayland display-only protocol. For abcd4desktop lineage, which has been the case since the update to kde/plasma 6, there are a few points to bear in mind.

abcd4desktop live iso

Switching abcd4desktop wayland only

• There is a vty1 conflict between kairos iso and sddm display manager : It took me a while to successfully start sddm on wayland: Sddm on wayland seems to need exclusive access to vty1, on boot, whereas kairos iso reserves that vty for a privileged session (root), because kairos iso is designed as a “single boot install only live iso”. Whereas abcd live iso is designed as a “hypervisor-agnostic immutable VM image” for a live-mode session in an educational context where privileged access must be locked down. The solution to this issue is to comment out the vty1 privileged session in /etc/inittab (abcd being a derivative of Alpine/openrc kairos, I don't know the systemd counterpart for this issue).

--- /etc/inittab.orig
+++ /etc/inittab
@@ -21,6 +21,7 @@
 # Stuff to do before rebooting
 ::shutdown:/sbin/openrc shutdown
 
-tty1::respawn:/sbin/agetty --autologin root -i --noclear tty1
+# free vty1 as it is needed by sddm and no root access allowed in abcd4desktop usage
+#tty1::respawn:/sbin/agetty --autologin root -i --noclear tty1
 
 ttyS0::respawn:/sbin/getty -L ttyS0 115200 vt100  

As inittab file probably generated by aurora at iso build step, this has to be managed by the yaml cloud-config file of the iso ?

abcdic4desktop container remote desktop

For desktop derivative of abcdic, remote desktop access when execution context is container (lxc, podman, docker, incus, lxd,...), has to be clientless (aka hmtl5 browser only). No need, for student or user, to depend on one remote display client installation (rdp, rfb, vnc,...), just web access (in the perspective to "Lab as a Service" hosted on a k8s pod on some cloud).
On initial version of abcdic, this was accomplished by Xpra known as "screen for X. One of the coolest feature of Xpra is its capability to dynamically auto adjust desktop resolution to the browser window size; a "must have" in that academic lab context.
But, untill now, Xpra is X11 only, no plan for Wayland. So what alternative ??

• krfb or krdp kde window mangager with an Apache Guacamole front end server embedded : not really usable in abcd context, and I dont find a remote wayland solution for sddm display manager. I'd like to keep the same User eXperience between baremetal/VM execution as well as container execution with a graphical initial login interface, just like a classical VDI.
• Track to explore : Greenfield in-browser wayland compositor a young promising project, but it needs to be approtirated/integrated/configureqd and afaik nobody has also tried/succeed it for a full sddm/kde/plasma desktop. What about the auto-resolution adjustment I had in the former Xpra ?

both abcd/abcdic

Xwayland application need pre defined /tmp/.X11-unix tree

As it took me some time to have a "stable" wayland/kde/plamsa : In some context, and that's the case on Alpine wayland/kde/plasma, some part of the desktop were unstable and tricky to trace. Googling on several forums I finally found that Xwayland applications need a pre-exisiting /tmp/.X11-unix tree pre-existant when starting the Xwayland application. cloud-config file is probably the simplest way for that.

# mkdir -p /tmp/.X11-unix  && chmod 1777 /tmp/.X11-unix

network configuration : connman vs others

• for network configuration alpine kairos derivative uses connman as default network configurator. kde/plasma desktop best integrated/dependence for network configurator is NetwrokManager. And worse for abcd4objectifipv6 derivative, embedded Gns3 network simulator doesn't seem to work without NetworkManager.
  OK to switch from connman to networkmnager service at init step, but aurora live iso still start connman confilcting with networkmanager. What's the neatest way to invalidate connman at iso live startup ? cloud-config file ?

[jimmykarily]

You've done some amazing research on this @j-landru , thanks for sharing! @ig0rmin since you were also running a gui, you may find some of this information useful.

I wonder if we need a section in the documentation specifically for running GUI applications on kairos (kiosks, labs etc). If you folks find that useful we can start by putting some of the information here in a page. Maybe also some of the things from the blog post. This way we can extend as we go so more people benefit from it. Let me know what you think. Feel free to start directly with a PR in the docs too :D.

Regarding disabling connman in live mode, I think you can simply delete the relevant symlinks in the Dockerfile (does openrc also enable services by creating symlinks like systemd does? In /etc/init.d/ maybe? I'm not sure). The live system looks pretty much like the installed one in terms of services, except for those enabled by cloud init files or kairos agent/provider etc.

[j-landru]

I'm a senior network sysadmin, not a dev experienced in the arcana of devops on github, so I'm afraid I'll make a few clumsy mistakes by jumping straight into a pull request. I like the idea of starting by sharing and gathering, with others, ideas, snippets and the rough draft on the subject on this blog, perhaps in the “show and tell” category, using part of this post as a basis and then structuring it neatly in the doc._

About switching from connman to NetworkManager in live mode, I've already removed the service startup link (I confirm that in openrc managing services with the rc-update command is equivalent to manually managing links in /etc/runlevels subtree). The net service is a prerequisite for other primitive services, and in its absence it activated connman (the 1st one ?) by default. So starting networkmanager at boot runlevel instead of default did the trick

[jimmykarily]

I created a ticket here to prioritize in planning: #3284