It should be possible to start kmscon with the initial-setup script as a login program.

Something like this may work:

systemctl stop kmsconvt@tty1
kmscon --vt=tty1 --no-switchvt --login -- initial-setup

I've added a --oneshot argument to kmscon, to help solve this issue:

https://github.com/kmscon/kmscon/pull/427

I've proposed the following PR to initial setup, that solve the issue.

https://github.com/rhinstaller/initial-setup/pull/161

This also require the --oneshot support in kmscon, and some selinux rules, as by default selinux will prevent kmscon to start initial-setup.

I see I didn't actually propose this as a Beta blocker, though I said I would...fixing.

This bug appears to have been reported against 'rawhide' during the Fedora Linux 45 development cycle.
Changing version to 45.

  AGREED AcceptedBetaBlocker
  
  Discussed at the 2026-08-24 (blocker / freeze exception) review meeting:
  
  This is accepted as a violation of 'A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system' for the ARM minimal disk image (which is release-blocking and relies on console initial-setup to provide said mechanism).
  
  https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/2026-08-24/f45-blocker-review.2026-08-24-15.59.log.txt

See https://bugzilla.redhat.com/show_bug.cgi?id=2358688#c32 & follow-up commits for a status updated about how it looks like with the Initial Setup TUI. Unfortunately, even the latest batch of fixes has not yet fully fixed this. :P

I was able to sidestep kmscon + SELinux problems and run initial-setup on aarch64 / RPi4 by adding
this convoluted override suggested by Claude Opus 4.6. It runs initial-setup in text mode and switches
to kmscon after setup is done. Verified working on Minimal aarch64 image F45 Branched 20260826.n.0.

/etc/systemd/system/initial-setup.service.d/override.conf

[Unit]
# Stop kmscon on tty1 so it doesn't fight for the display
Conflicts=kmsconvt

[Service]
# Bypass kmscon which crashes on RPi4 due to V3D DRM incompatibility (SIGSEGV
# in kmscon_seat_remove_video). Run initial-setup TUI directly on tty1.
#
# Use --no-multi-tty because the multi-TTY handler opens every /dev/tty* and
# /dev/ttyS* device, which conflicts with kmscon instances on other VTs and
# results in the wizard output being invisible to the user. With --no-multi-tty
# the TUI reads/writes only on its own stdin/stdout (tty1).
#
# Use tty-force for StandardInput to ensure the TTY becomes the controlling
# terminal of the process (TIOCSCTTY). Without this, echo and line editing
# do not work because simpleline relies on Python's input() which needs a
# properly configured controlling terminal.
ExecStartPre=
ExecStart=
ExecStart=/bin/bash -c '\
    stty sane; \
    IS_UNIT=initial-setup.service; \
    /usr/libexec/initial-setup/initial-setup-text --no-stdout-log --no-multi-tty; \
    res=$?; \
    if [ $res -eq 0 ]; then \
        echo "Initial Setup finished successfully, disabling" | systemd-cat -t initial-setup -p 6; \
        systemctl -q is-enabled $IS_UNIT && systemctl disable $IS_UNIT; \
    else \
        echo "Initial Setup failed, keeping enabled" | systemd-cat -t initial-setup -p 3; \
    fi; \
    exit $res'
ExecStartPost=
ExecStartPost=/usr/bin/systemctl start --no-block kmsconvt
TTYPath=/dev/tty1
StandardInput=tty-force
StandardOutput=tty
StandardError=journal

I also investigated kmscon+SELinux route:

The initial-setup TUI fails to start under SELinux enforcing mode when launched via kmscon due to two issues in selinux-policy:
1. Missing file context: The binaries in /usr/libexec/initial-setup/ have generic bin_t context instead of install_exec_t. 
   The policy defines install_exec_t for /usr/bin/initial-setup and /usr/bin/anaconda, but not for /usr/libexec/initial-setup/ 
   where the actual TUI binaries live.
2. Missing type transition: When kmscon (kmscon_t) spawns initial-setup via --login, there is no type_transition rule to move 
   the child process from kmscon_t to install_t. The policy defines this transition for init_t, unconfined_t, and several other
   domains, but not for kmscon_t.
As a result, initial-setup inherits the kmscon_t context and gets AVC denials for operations that install_t would normally be allowed (searching /etc/pki, executing /usr/sbin/ldconfig, accessing journal directories).

Fix verified on Minimal aarch64 image F45 Branched 20260826.n.0 with the following custom policy module:

module kmscon-initial-setup 1.1;

require {
    type kmscon_t;
    type install_t;
    type install_exec_t;
    class dir { search getattr open read };
    class file { execute open read getattr map ioctl };
    class process { transition };
}

allow kmscon_t install_exec_t:dir { search getattr open read };
allow kmscon_t install_exec_t:file { execute open read getattr map ioctl };
allow kmscon_t install_t:process transition;
type_transition kmscon_t install_exec_t:process install_t;

And the following file context addition:

/usr/libexec/initial-setup(/.*)?    --    system_u:object_r:install_exec_t:s0


With both applied, initial-setup runs as install_t and completes successfully with zero AVC denials.

There is a separate problem that on RPi4 kmscon crashes on shutdown when initial-setup is already done.
I reported this here including a fix: https://bugzilla.redhat.com/show_bug.cgi?id=2524448

Created attachment 2155891 [details]
HOWTO Install SELinux policy update on mounted fs

I've reassigned this issue to `selinux-policy` as this is an SELinux policy issue and the above policy change (I haven't looked if it's actually a "good" change) has been confirmed to resolve it.

Some concerns I have with the suggested policy:

1. I think the install_exec_t:dir is a dead rule.
2. This basically allows kmscon to do *everything*.

But I think that's already the status quo anyways.

If the SELinux update is too intrusive, there is another verified workaround described in https://bugzilla.redhat.com/show_bug.cgi?id=2484542#c8
This one temporarily drops kmscon from tty1, runs initial-setup there in text mode and restores kmscon after it is done.
Only initial-setup service needs to be updated, no changes to SELinux configuration.

Zdenek, can you please take a look at this and let us know what you think? It's a Fedora 45 Beta blocker and Beta is coming up soon, so we really need some kind of resolution.

(In reply to Simon de Vlieger from comment #12)
> Some concerns I have with the suggested policy:
> 
> 1. I think the install_exec_t:dir is a dead rule.
> 2. This basically allows kmscon to do *everything*.
> 
> But I think that's already the status quo anyways.

Is that still better than fbcon, that is in the kernel so is completely out of the selinux policy ?

Taking a look, I'll comment later today.

I think a fix is needed in selinux-policy.

Thanks, Zdenek. Can we expect a new build with the fix soon? Go/No-Go for Beta is next week, I am trying to line up blocker fixes as early as possible. Thanks again!

Actually, since this is the last blocker for Beta currently, I'll do a backport build...

FEDORA-2026-a24762e6fe (selinux-policy-45.15-2.fc46) has been submitted as an update to Fedora 46.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-a24762e6fe

FEDORA-2026-2f1cf4178d (selinux-policy-45.15-2.fc45) has been submitted as an update to Fedora 45.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-2f1cf4178d

FEDORA-2026-a24762e6fe (selinux-policy-45.15-2.fc46) has been pushed to the Fedora 46 stable repository.
If problem still persists, please make note of it in this bug report.

Setting back to ON_QA, the Rawhide update cannot close this bug.

FEDORA-2026-2f1cf4178d has been pushed to the Fedora 45 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-2f1cf4178d`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-2f1cf4178d

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Seems that `initial-setup` is not fixed in F45 Beta 1.1 for either aarch64 or x86_64

Seems that SELinux policy update did not make it yet to this release - see AVC denials in attached boot log.
Including also latest Rawhide boot log for comparing.

Created attachment 2156576 [details]
bootlog Fedora-Minimal-45_Beta-1.1.aarch64

Created attachment 2156577 [details]
bootlog Fedora-Minimal-Rawhide-20260903.n.0.aarch64

After I updated manually selinux-policy* from version 45.14.1.fc45 to 45.15-2.fc45 the initial-setup works as expected on Fedora 45 Beta 1.1.

Yeah, sorry, my bad. I meant to include the selinux-policy fix - that's why I made it! - but somehow it didn't make it into the Beta-1.1 request. I've requested a new candidate compose now.

Fix verified in Beta-1.2 testing.

FEDORA-2026-2f1cf4178d (selinux-policy-45.15-2.fc45) has been pushed to the Fedora 45 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2026-c59e65cdbc (selinux-policy-45.16-1.fc45) has been submitted as an update to Fedora 45.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-c59e65cdbc

FEDORA-2026-c59e65cdbc has been pushed to the Fedora 45 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-c59e65cdbc`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-c59e65cdbc

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2026-c59e65cdbc (selinux-policy-45.16-1.fc45) has been pushed to the Fedora 45 stable repository.
If problem still persists, please make note of it in this bug report.