Fixes to weston startup

[marmarek]

This PR fixes two aspect of weston startup:

1. Switching VT - necessary with libseat >= 0.9.0
2. Handling multiple GPUs

See individual commit messages for details

[Conan-Kudo]

FYI @AdamWill @nirik: This pull request should also resolve RH#2358688.

[M4rtinK]

So I've tried the fix by installing a Rawhide VM & installing initial-setup-gui.

First I tried to run the Initial Setup GUI without the changes - set graphical.target target as the default systemd target & enable initial-setup.service. Indeed, in this case the GUI does not run & you end up on the login prompt.

Then I edited the /usr/libexec/initial-setup/run-gui-backend file with the changes from this PR, set graphical.target target as the default systemd target & enabled initial-setup.service - this fixes the issue with the GUI not showing up - it is now visible!

But unfortunately the fix does not appear to be complete - although the GUI does show up, when you press the FINISH CONFIGURATION button, something gets stuck indefinitely & the login prompt is not reached:

It is possible to switch to a different TTY, but the one in which Initial Setup was running is stuck.

Journal dump from this happening:
journal_stuck_dump.txt

[marmarek]

the login prompt is not reached:

Was there supposed to be a login prompt? initial-setup uses tty7, but I think normally getty is started only on tty1-tty6.

[AdamWill]

after initial-setup runs, either a login prompt or a logged-in session must be presented next. this is in the release criteria, and it's how it has always worked previously.

[marmarek]

Lightdm (and probably others too) will switch to appropriate VT on its own. That isn't the case for the text console. I guess I can add chvt back to tty1 (or saved fgconsole if that works?), will that be enough?

[Conan-Kudo]

It should indeed switch back to what it started with before. So basically capture the existing vt, switch, then switch back.

[marmarek]

This version should (hopefully) do that now.

[Conan-Kudo]

kbd should be specified as a runtime dependency of the subpackage containing this script.

[Conan-Kudo]

Needs to be added for this subpackage block: https://github.com/rhinstaller/initial-setup/blob/master/initial-setup.spec#L93-L111

[marmarek]

CI is unhappy, not sure why:

2025-04-24 14:07:18.247 logging.py        INFO   Creating tar archive
2025-04-24 14:07:18.324 logging.py        INFO   removing 'initial_setup-0.3.101' (and everything under it)
2025-04-24 14:07:18.350 logging.py        INFO   The archive is in initial-setup-0.3.101.tar.gz
2025-04-24 14:07:18.351 commands.py       DEBUG  Command: bash -c cp dist/*.tar.gz .
2025-04-24 14:07:18.354 commands.py       DEBUG  Command: bash -c ls -1 initial-setup-*.tar.gz
2025-04-24 14:07:18.357 logging.py        INFO   ls: cannot access 'initial-setup-*.tar.gz': No such file or directory
2025-04-24 14:07:18.358 commands.py       ERROR  Command 'bash -c ls -1 initial-setup-*.tar.gz' failed.
2025-04-24 14:07:18.358 commands.py       DEBUG  Command stderr: ls: cannot access 'initial-setup-*.tar.gz': No such file or directory

[M4rtinK]

Any updates ? I assume its still broken without the fix. :P

[marmarek]

Let me know if I can help, I think I addressed all earlier comments. CI looks to be broken, but I don't think I can do anything about it...

[M4rtinK]

Let me know if I can help, I think I addressed all earlier comments. CI looks to be broken, but I don't think I can do anything about it...

OK, will check on ~Monday. :)

[Conan-Kudo]

Can someone please look at this? We should get this fixed and released to F42 and Rawhide.

[supakeen]

I've been tinkering with some Fedora variants that could make use of this.