* Does the service require post-rpm-installation configuration in order to be useful (for example, does it need manual edits to a configuration file)? No * Does the service listen on a network socket for connections originating on a separate physical or virtual machine? No * Is the service non-persistent (i.e. run once at startup and exit)? No * What is the exact name (or names) of the systemd unit files to be enabled? The kmscon service should replace agetty on all tty. The recommended way is to link autovt to kmsconvt, like this: sudo ln -s /usr/lib/systemd/system/kmsconvt@.service /etc/systemd/system/autovt@.service * Is this request for all Fedora deliverables or only for some Editions (list them)? Yes, this request is for all Fedora deliverables, as they all have VT.
(In reply to Jocelyn Falempe from comment #0) > * What is the exact name (or names) of the systemd unit files to be enabled? > > The kmscon service should replace agetty on all tty. The recommended way is > to link autovt to kmsconvt, like this: > sudo ln -s /usr/lib/systemd/system/kmsconvt@.service > /etc/systemd/system/autovt@.service This doesn't really make sense. What you're suggesting here is that the `ksmconvt@.service` should PRETEND to be the `autovt@.service`. First of all, that's not something that can be done with a preset, so far as I know. Secondly, that would be violating the user's trust. If they have `autovt@.service` enabled, *that is what they expect will be running*. Is this your way of trying to "upgrade" the users to `kmsconvt@.service`? If so, it's not the right way to go about it. Also, is it safe (and desirable) to migrate all users to the new service, or might some users want to remain on `autovt@.service` for any reason? Can both services be enabled at the same time on one system, or will they conflict? If they conflict, what happens? Does the first one to start "own" the virtual terminals? Does it become impossible to bring up a VT at all? I think this needs more thought before we enable it by default.
Thanks for looking into this. The goal is to disable fbcon/fbdev in the kernel, so the userspace has to be ready before that. You're right, the link in /etc is for user configuration. But on a default Fedora installation, there is already a link /usr/lib/systemd/system/autovt@.service which points to getty@.service ll /usr/lib/systemd/system/autovt@.service lrwxrwxrwx@ - root 13 oct. 2025 /usr/lib/systemd/system/autovt@.service -> getty@.service So is it possible to change this link to point to kmsconvt instead? There is a fallback to getty in kmsconvt service: Before=getty.target Conflicts=getty@%i.service OnFailure=getty@%i.service So normally, if kmsconvt doesn't start on some configuration, getty should take the VT. That happens when I develop kmscon, and it segfaults, I always get a getty on the same VT a few seconds later. If some users want to go back to getty/fbcon, it should be possible to override this with a link in /etc/systemd/system/autovt@.service. This should be properly documented in the F44 release note. The cases where we don't want kmscon for F44 (but we will need to support, before disabling fbcon) are: - disk encryption password (if not using plymouth). - early ramdisk failure. - installation ISO. (I should check with anaconda team first, if the text install works in kmscon).
Looking a bit more, the link /usr/lib/systemd/system/autovt@.service belongs to the systemd package. So what can be possible is to make systemd depends on kmscon, and change the link in the systemd package?
autovt@.service is a symlink because it is an alias. It is a static symlink because until now there was no reason to ever change it. What we want to do is 1. change the systemd unit to use [Install]Alias= instead of the static symlink 2. change kmsconvt@.service to have the same [Install] section 3. add a preset to disable getty@.service and a preset to enable kmsconvt@.service https://github.com/systemd/systemd/pull/40440 for the first item.
Thanks a lot, that's much better than what I proposed.
So, in order to be on-time for the F44 schedule, I will submit a new version of kmscon package with https://github.com/kmscon/kmscon/pull/245 included. I think we also need a systemd package update with https://github.com/systemd/systemd/pull/40440 ? And then adding the preset. if I understand correctly the F44 schedule, it should be done by February 3, which is next week ?
https://src.fedoraproject.org/rpms/fedora-release/pull-request/395
FEDORA-2026-0b2b8265d2 (fedora-release-44-0.12) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-0b2b8265d2
This update breaks on non-graphical setup, it looks like neither agetty nor kmscon is started on the tty. Maybe it's because I put kmscon as "default" in https://pagure.io/fork/jfalempe/fedora-comps/c/294d8e2a05e35010cb365dfe7a76061136d8ad8a and I should put "mandatory" ?
I don't think that is the cause, because there was already a problem with the systemd update that changed to use [Install] for getty@.service. (That update predated the fedora-release changes.) I'm looking into it, but didn't figure it out yet. (I was at FOSDEM, so I didn't have any time to do anything properly.)
I'm wondering how to move forward on this topic. Should I add something like this in systemd.spec, but that looks a bit hacky: %install %meson_install ln -fs kmsconvt@.service %{buildroot}/usr/lib/systemd/system/autovt@.service On the other hand, I can't overwrite this link in kmscon package, as it will be reset each time systemd is updated?
I think the problems in systemd have been fixed. The latest updates use presets for getty@.service. So we should try to reintroduce the changes to switch to kmsconvt@.service again.
Yes, we can try to enable it again, but I think there are still issues with autovt and kmscon. For getty, it's not a problem if it's started on the same tty as a DE, because it will disable itself if it's not drm master, and won't prevent a DE to be started. But for kmscon, it will fail to start if it can't take the drm master, and it will prevent any application to become drm master on the same tty. I think that autovt was made to avoid wasting resources by not starting getty on tty that are not active, but may lack feature to avoid conflicts between kmscon and DE?
In general systemd will start getty@.service in two cases: - upon switch to a virtual console that was previously idle - unconditionally for a fixed number of vts. IIRC, this unconditional starting is done so that something is displayed on the console in all cases. If it was blank, this could be confusing to users. Systemd doesn't do anything to avoid confict… It's possible that some changes are needed here to work properly with kmscon. It'd probably be better to discuss this upstream if so.
Ok, thanks for the details. I've made more testing with the F44 kde installer image that has the preset enabled, and had issues. The problem is that kmscon is started on tty1, and prevent kwin/installer to run. after a while kmscon got somewhat killed and the installer finally appear. On the installed system, it works fine. So a simple solution would be to mask kmsconvt@tty1 on the installer?
After more tests, sometime kmscon can run on the same tty as gdm, or sddm, leading to strange things. But I didn't find a reliable way to reproduce it. I also found that most desktop environment systemd services have getty@tty1 hardcoded in them eg: gdm https://github.com/GNOME/gdm/blob/main/data/gdm.service.in sddm: https://github.com/sddm/sddm/blob/develop/services/sddm.service.in So they both Conflicts with getty Should we patch all this services, and add Conflicts:kmsconvt and After:kmsconvt too ? Or maybe this can be done in kmsconvt@service using Conflicts: and Before: with every login manager available. Or should I open an issue in upstream systemd to have something more generic like Conflicts:any_tty ? So if there is another thing like kmscon in the future, we won't need to add it to every DE service ?
I opened this issue on systemd upstream: https://github.com/systemd/systemd/issues/41087
I've pushed this 3 PR, that should solve the conflicts with kmsconvt. https://src.fedoraproject.org/rpms/gdm/pull-request/42 https://src.fedoraproject.org/rpms/plasma-login-manager/pull-request/1 https://src.fedoraproject.org/rpms/sddm/pull-request/13 So when they are merged we can make another try?
The 3 PR are now merged, so we can try again to enable the preset.
I opened the following PR: https://src.fedoraproject.org/rpms/redhat-systemd-presets/pull-request/3 presets have moved to redhat-systemd-presets.