Allow and prefer running the graphical setup in wayland

[aleasto]

Hi! The initial-setup was configured to always run Xorg and an x11 window manager. We're dropping kwin_x11 from Fedora KDE in Fedora 40 so there won't be any x11 window manager nor Xorg preloaded.

This PR defines the interface for a generic graphic server to run the firstboot ui as a /usr/libexec/initial-setup/run-gui-backend program taking as parameters the firstboot binary and arguments. We implement a generic wayland server with weston, and use it by default.

The desktops can ship the configuration for their preferred compositor with a package providing their runner program at /usr/libexec/initial-setup/run-gui-backend, and

Provides:  firstboot(gui-backend)
Conflicts: firstboot(gui-backend)

Xorg+some window manager is still available as an option via initial-setup-gui-xorg that implements the same interface.

[aleasto]

I wonder if it's ok to drop the Requires: from the specfile, or if it should be something like Requires: (xorg-x11-server-Xorg unless kwin_wayland) and be changed for every new wayland compositor that gets added

[Conan-Kudo]

I think it probably makes sense to refactor the initial-setup packaging so that the X11 launcher and the Wayland launcher are in separate subpackages, and set a preference for the Wayland one.

That does mean we probably should add the launch logic for mutter, labwc, wayfire, and sway...

[Conan-Kudo]

Sorry, to explain, I mean we should do something similar to what we did for sddm subpackages for controlling wayland and x11 modes.

[pep8speaks]

Hello @aleasto! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

There are currently no PEP 8 issues detected in this Pull Request. Cheers! :beers:

Comment last updated at 2024-01-02 15:56:24 UTC

[Conan-Kudo]

This looks fine to me at this point, the test failure is because of the mutually conflicting backend packages, and is expected. That test will need to be adapted to deal with this problem.

[aleasto]

@jkonecny12 @M4rtinK @poncovka do you think we can merge this and break packit... or maybe disable packit tests until it becomes usable? It's only testing python3 -c "import initial_setup" anyways if i understand correctly.

[Conan-Kudo]

We really need this to land so that we can unblock the OpenQA failures for Fedora KDE. Can we please do something to get this in?

[M4rtinK]

Does not seem to work for me just yet when testing a scratchbuild. What I did:

1. installed latest Rawhide with default environment (custom OS something ?), without creating a user account (root only)
2. booted the system, set graphical run level: systemctl set-default graphical
3. installed regular IS from Rawhide,
4. enabled its unit: systemctl enable initial-setup, reboot
5. checked it works
6. uninstalled initial-setup, installed scratchbuild from this PR, enabled iots unit, rebooted
7. does not start

Looking at the logs, an environment variable seems not to be set:

[root@dhcp123 ~]# journalctl -b -u initial-setup
Dec 12 17:36:28 fedora systemd[1]: Starting initial-setup.service - Initial Setup configuration program...
Dec 12 17:36:28 fedora run-initial-setup[835]: Date: 2023-12-12 CET
Dec 12 17:36:28 fedora run-initial-setup[835]: [17:36:28.681] weston 13.0.0
Dec 12 17:36:28 fedora run-initial-setup[835]:                https://wayland.freedesktop.org
Dec 12 17:36:28 fedora run-initial-setup[835]:                Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/
Dec 12 17:36:28 fedora run-initial-setup[835]:                Build: 13.0.0
Dec 12 17:36:28 fedora run-initial-setup[835]: [17:36:28.681] Command line: weston --config=/tmp/tmp.nDld4ccxq9-wl-weston-firstboot-ini --socket=wl-firstboot-0
Dec 12 17:36:28 fedora run-initial-setup[835]: [17:36:28.681] OS: Linux, 6.7.0-0.rc5.41.fc40.x86_64, #1 SMP PREEMPT_DYNAMIC Mon Dec 11 15:42:52 UTC 2023, x86_64
Dec 12 17:36:28 fedora run-initial-setup[835]: [17:36:28.681] Flight recorder: enabled
Dec 12 17:36:28 fedora run-initial-setup[835]: [17:36:28.681] fatal: environment variable XDG_RUNTIME_DIR is not set.
Dec 12 17:36:28 fedora run-initial-setup[835]: Refer to your distribution on how to get it, or
Dec 12 17:36:28 fedora run-initial-setup[835]: http://www.freedesktop.org/wiki/Specifications/basedir-spec
Dec 12 17:36:28 fedora run-initial-setup[835]: on how to implement it.
Dec 12 17:36:28 fedora systemctl[843]: Removed "/etc/systemd/system/multi-user.target.wants/initial-setup.service".
Dec 12 17:36:28 fedora systemctl[843]: Removed "/etc/systemd/system/graphical.target.wants/initial-setup.service".
Dec 12 17:36:28 fedora systemd[1]: initial-setup.service: Deactivated successfully.
Dec 12 17:36:28 fedora systemd[1]: Finished initial-setup.service - Initial Setup configuration program.

IIRC a similar variable had to be set in the Anaconda Wayland prototype as well.

[changyp6]

Does not seem to work for me just yet when testing a scratchbuild. What I did:

1. installed latest Rawhide with default environment (custom OS something ?), without creating a user account (root only)

2. booted the system, set graphical run level: `systemctl set-default graphical`

3. installed regular IS from Rawhide,

4. enabled its unit: `systemctl enable initial-setup`, reboot

5. checked it works

6. uninstalled initial-setup, installed [scratchbuild](https://m4rtink.fedorapeople.org/initial-setup/wayland_support/v1/) from this PR, enabled iots unit, rebooted

7. does not start

Looking at the logs, an environment variable seems not to be set:

[root@dhcp123 ~]# journalctl -b -u initial-setup
Dec 12 17:36:28 fedora systemd[1]: Starting initial-setup.service - Initial Setup configuration program...
Dec 12 17:36:28 fedora run-initial-setup[835]: Date: 2023-12-12 CET
Dec 12 17:36:28 fedora run-initial-setup[835]: [17:36:28.681] weston 13.0.0
Dec 12 17:36:28 fedora run-initial-setup[835]:                https://wayland.freedesktop.org
Dec 12 17:36:28 fedora run-initial-setup[835]:                Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/
Dec 12 17:36:28 fedora run-initial-setup[835]:                Build: 13.0.0
Dec 12 17:36:28 fedora run-initial-setup[835]: [17:36:28.681] Command line: weston --config=/tmp/tmp.nDld4ccxq9-wl-weston-firstboot-ini --socket=wl-firstboot-0
Dec 12 17:36:28 fedora run-initial-setup[835]: [17:36:28.681] OS: Linux, 6.7.0-0.rc5.41.fc40.x86_64, #1 SMP PREEMPT_DYNAMIC Mon Dec 11 15:42:52 UTC 2023, x86_64
Dec 12 17:36:28 fedora run-initial-setup[835]: [17:36:28.681] Flight recorder: enabled
Dec 12 17:36:28 fedora run-initial-setup[835]: [17:36:28.681] fatal: environment variable XDG_RUNTIME_DIR is not set.
Dec 12 17:36:28 fedora run-initial-setup[835]: Refer to your distribution on how to get it, or
Dec 12 17:36:28 fedora run-initial-setup[835]: http://www.freedesktop.org/wiki/Specifications/basedir-spec
Dec 12 17:36:28 fedora run-initial-setup[835]: on how to implement it.
Dec 12 17:36:28 fedora systemctl[843]: Removed "/etc/systemd/system/multi-user.target.wants/initial-setup.service".
Dec 12 17:36:28 fedora systemctl[843]: Removed "/etc/systemd/system/graphical.target.wants/initial-setup.service".
Dec 12 17:36:28 fedora systemd[1]: initial-setup.service: Deactivated successfully.
Dec 12 17:36:28 fedora systemd[1]: Finished initial-setup.service - Initial Setup configuration program.

IIRC a similar variable had to be set in the Anaconda Wayland prototype as well.

Yes. I tried it, and encountered the same issue.

[changyp6]

Does not seem to work for me just yet when testing a scratchbuild. What I did:

1. installed latest Rawhide with default environment (custom OS something ?), without creating a user account (root only)

2. booted the system, set graphical run level: `systemctl set-default graphical`

3. installed regular IS from Rawhide,

4. enabled its unit: `systemctl enable initial-setup`, reboot

5. checked it works

6. uninstalled initial-setup, installed [scratchbuild](https://m4rtink.fedorapeople.org/initial-setup/wayland_support/v1/) from this PR, enabled iots unit, rebooted

7. does not start

Looking at the logs, an environment variable seems not to be set:

[root@dhcp123 ~]# journalctl -b -u initial-setup
Dec 12 17:36:28 fedora systemd[1]: Starting initial-setup.service - Initial Setup configuration program...
Dec 12 17:36:28 fedora run-initial-setup[835]: Date: 2023-12-12 CET
Dec 12 17:36:28 fedora run-initial-setup[835]: [17:36:28.681] weston 13.0.0
Dec 12 17:36:28 fedora run-initial-setup[835]:                https://wayland.freedesktop.org
Dec 12 17:36:28 fedora run-initial-setup[835]:                Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/
Dec 12 17:36:28 fedora run-initial-setup[835]:                Build: 13.0.0
Dec 12 17:36:28 fedora run-initial-setup[835]: [17:36:28.681] Command line: weston --config=/tmp/tmp.nDld4ccxq9-wl-weston-firstboot-ini --socket=wl-firstboot-0
Dec 12 17:36:28 fedora run-initial-setup[835]: [17:36:28.681] OS: Linux, 6.7.0-0.rc5.41.fc40.x86_64, #1 SMP PREEMPT_DYNAMIC Mon Dec 11 15:42:52 UTC 2023, x86_64
Dec 12 17:36:28 fedora run-initial-setup[835]: [17:36:28.681] Flight recorder: enabled
Dec 12 17:36:28 fedora run-initial-setup[835]: [17:36:28.681] fatal: environment variable XDG_RUNTIME_DIR is not set.
Dec 12 17:36:28 fedora run-initial-setup[835]: Refer to your distribution on how to get it, or
Dec 12 17:36:28 fedora run-initial-setup[835]: http://www.freedesktop.org/wiki/Specifications/basedir-spec
Dec 12 17:36:28 fedora run-initial-setup[835]: on how to implement it.
Dec 12 17:36:28 fedora systemctl[843]: Removed "/etc/systemd/system/multi-user.target.wants/initial-setup.service".
Dec 12 17:36:28 fedora systemctl[843]: Removed "/etc/systemd/system/graphical.target.wants/initial-setup.service".
Dec 12 17:36:28 fedora systemd[1]: initial-setup.service: Deactivated successfully.
Dec 12 17:36:28 fedora systemd[1]: Finished initial-setup.service - Initial Setup configuration program.

IIRC a similar variable had to be set in the Anaconda Wayland prototype as well.

Yes. I tried it, and encountered the same issue.

I did some modification, which can make weston run during first-boot. Following is the patch

diff --git a/initial-setup.spec b/initial-setup.spec
index ac44db4..4f15a5a 100644
--- a/initial-setup.spec
+++ b/initial-setup.spec
@@ -69,6 +69,7 @@ RemovePathPostfixes: .guixorg
 Summary: Run the initial-setup GUI in Wayland
 Requires: %{name}-gui = %{version}-%{release}
 Requires: weston
+Requires: seatd
 Requires: xorg-x11-server-Xwayland

 Provides:  firstboot(gui-backend)
diff --git a/scripts/run-gui-backend.guiweston b/scripts/run-gui-backend.guiweston
index a36c45c..eda8fe4 100755
--- a/scripts/run-gui-backend.guiweston
+++ b/scripts/run-gui-backend.guiweston
@@ -5,11 +5,13 @@
 CONFIG_FILE=$(mktemp --suffix="-wl-weston-firstboot-ini")
 RUN_SCRIPT=$(mktemp --suffix="-wl-weston-firstboot-run")
 EXIT_CODE_SAVE=$(mktemp --suffix="-wl-weston-firstboot-exit")
+RUNTIME_DIR=/run/user/0

 cat > ${CONFIG_FILE} << EOF
 [core]
 shell=kiosk
 xwayland=true
+renderer=pixman

 [autolaunch]
 path=${RUN_SCRIPT}
@@ -24,8 +26,17 @@ EOF

 chmod +x ${RUN_SCRIPT}

+mkdir -p        ${RUNTIME_DIR}
+chown root:root ${RUNTIME_DIR}
+chmod 700       ${RUNTIME_DIR}
+
+systemctl start seatd
+export XDG_RUNTIME_DIR=${RUNTIME_DIR}
 weston --config=${CONFIG_FILE} --socket=wl-firstboot-0
 exit_code=$(< ${EXIT_CODE_SAVE})
+systemctl stop seatd

 rm ${CONFIG_FILE} ${RUN_SCRIPT} ${EXIT_CODE_SAVE}
+rm -rf ${RUNTIME_DIR}
+
 exit $exit_code

[aleasto]

Thanks! But why doesn't it work with systemd-logind?

[Conan-Kudo]

Probably because there's no login session that early.

[changyp6]

Thanks! But why doesn't it work with systemd-logind?

When initial-setup.service is running, systemd-logind.service is not started yet. And in the systemd-logind.service file, it has the following requirements:

Wants=user.slice modprobe@drm.service
After=nss-user-lookup.target user.slice modprobe@drm.service

When initial-setup.service is running, there is no user existing in this system. I don't know much about user.slice. I'm not sure if I can call systemctl start systemd-logind.service before any users are created.

In this case, I experimented with seatd.service, and it works. I didn't try systemd-logind.service, maybe someone can help try it to see if it works. 😸

[aleasto]

Thanks! But why doesn't it work with systemd-logind?

When initial-setup.service is running, systemd-logind is not started yet. And in the systemd-logind.service file

Wants=user.slice modprobe@drm.service
After=nss-user-lookup.target user.slice modprobe@drm.service

When initial-setup is running, there is no user exist in this system. I don't know much about user.slice. I'm not sure if I can call systemctl start systemd-logind.service before any users are created.

In this case, I experimented with seatd.service, and it works. I didn't try systemd-logind.service, maybe someone can try it to see if it works. 😸

I did try it, and it doesn't work. But it's not related to the fact that there are no users created. I was trying to avoid the dependency on seatd.

[changyp6]

Thanks! But why doesn't it work with systemd-logind?

When initial-setup.service is running, systemd-logind is not started yet. And in the systemd-logind.service file

Wants=user.slice modprobe@drm.service
After=nss-user-lookup.target user.slice modprobe@drm.service

When initial-setup is running, there is no user exist in this system. I don't know much about user.slice. I'm not sure if I can call systemctl start systemd-logind.service before any users are created. In this case, I experimented with seatd.service, and it works. I didn't try systemd-logind.service, maybe someone can try it to see if it works. 😸

I did try it, and it doesn't work. But it's not related to the fact that there are no users created. I was trying to avoid the dependency on seatd.

In document of weston from https://wayland.pages.freedesktop.org/weston/toc/running-weston.html in section Running Weston on a stand-alone back-end,

Launching Weston via ssh or a serial terminal is best with the libseat launcher and seatd. Logind will refuse to give access to local seats from remote connections directly. 

Is it possible that systemd-logind somehow doesn't give access to the seats ?

[aleasto]

Fixed, systemd will now create a session for us at TTY 7

[Conan-Kudo]

Awesome, so now can we get this to land, @jkonecny12?

[Conan-Kudo]

Or rather, I guess @M4rtinK since he's the maintainer of this.

[jkonecny12]

I wonder, what will happen if user has installed multiple Desktop Environments? For example there would be Weston together with Xorg and Mutter. What will initial setup DNF transaction do? Will it chose one randomly or will it fail?

[aleasto]

I wonder, what will happen if user has installed multiple Desktop Environments? For example there would be Weston together with Xorg and Mutter. What will initial setup DNF transaction do? Will it chose one randomly or will it fail?

If I understood the question, dnf will put preference towards weston as declared here: https://github.com/rhinstaller/initial-setup/pull/149/files#diff-d62e3ca5f7708945b1caac6623cb1b15dece3cb5152de414e58c5177fecf96f7R48

[Conan-Kudo]

That is, of course, only if the spin doesn't pick a backend. For example, for the KDE Spin, we'll pick the backend we ship ourselves. @alebastr will ship their own for Sway Spin, and the others will wind up using Weston as that's the default choice.

[aleasto]

Oh maybe the question was more like: what happens when in a netinstall the user selects multiple desktop environment groups that each provide their own firstboot(gui-backend) conflicting with each other. I guess maintainers should be careful not to mark them as mandatory in comps? And if none of the chosen backends is weston, then the selection would be "random" (probably more like deterministic according to some dnf criterion that i don't know)

[Conan-Kudo]

It should probably not be in comps, instead each backend package should use a rich supplements. For example initial-setup-gui-wayland-plasma will Supplements: (initial-setup-gui and kwin-wayland).

[jkonecny12]

Thanks @aleasto , yes that was the correct question I was asking.

My question is related to kickstart installations mainly but might be also elsewhere. What will happen with this pseudo kickstart in place.

%packages
initial-setup
@kde
@gnome-shell
@sway
%end

What would be used for the Initial Setup as backend. Related to that what would happen with:

%packages
initial-setup
@gnome-shell
@sway
%end

What would be the backend in case Weston is not installed directly because KDE is not installed. Will this work correctly at all?

[aleasto]

If no selected desktop provides a configuration, Weston will be installed.

If only one desktop provides a configuration, that one will be installed.

If multiple desktops provide a configuration, only one will be installed, I don't know which one.

• this is assuming the desktops provide their configuration package with something like Supplements: (initial-setup-gui and $MY_WAYLAND_COMPOSITOR)

• not tested, this is only reasoning like the dependency solver should

[Conan-Kudo]

I believe it's "first one wins" in a sorted list of requested packages, but I don't know that for certain.

[jkonecny12]

That is probably good enough.