Description of problem: Initial setup isn't started and system boots directly to sddm. No user is created. Output of systemctl status initial-setup-graphical.service: ● initial-setup-graphical.service - Initial Setup configuration program Loaded: loaded (/usr/lib/systemd/system/initial-setup-graphical.service; enabled; vendor preset: enabled) Active: inactive (dead) since Wed 2015-08-05 11:38:57 CEST; 20min ago Process: 861 ExecStart=/bin/xinit /bin/firstboot-windowmanager /bin/initial-setup -- /bin/Xorg :9 -ac -nolisten tcp (code=exited, status=0/SUCCESS) Process: 833 ExecStartPre=/bin/plymouth quit (code=exited, status=0/SUCCESS) Main PID: 861 (code=exited, status=0/SUCCESS) CGroup: /system.slice/initial-setup-graphical.service Aug 05 11:38:55 dhcp-28-126.brq.redhat.com org.a11y.atspi.Registry[1352]: after 21 requests (21 known processed) with 0 events remaining. Aug 05 11:38:55 dhcp-28-126.brq.redhat.com xinit[861]: waiting for X server to shut down Service started, version: Aug 05 11:38:55 dhcp-28-126.brq.redhat.com org.a11y.Bus[1274]: g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting. Aug 05 11:38:55 dhcp-28-126.brq.redhat.com xinit[861]: No ksycoca database available! Tried running kbuildsycoca5 ? Aug 05 11:38:55 dhcp-28-126.brq.redhat.com xinit[861]: KServiceTypeTrader: serviceType "ActivityManager/Plugin" not found Aug 05 11:38:55 dhcp-28-126.brq.redhat.com xinit[861]: The X11 connection broke (error 1). Did the X11 server die? Aug 05 11:38:55 dhcp-28-126.brq.redhat.com xinit[861]: Couldn't start kglobalaccel from org.kde.kglobalaccel.service: QDBusError("org.freedesktop.DBus.Error.Disconnected", "Connection is closed") Aug 05 11:38:56 dhcp-28-126.brq.redhat.com xinit[861]: .error setting MTRR (base = 0xe0000000, size = 0x01000000, type = 1) Invalid argument (22) Aug 05 11:38:56 dhcp-28-126.brq.redhat.com xinit[861]: (II) Server terminated successfully (0). Closing log file. Aug 05 11:38:57 dhcp-28-126.brq.redhat.com systemd[1]: Started Initial Setup configuration program. Version-Release number of selected component (if applicable): initial-setup-0.3.35-1.fc23.x86_64 How reproducible: always Steps to Reproduce: 1. Install system with KDE without creating user 2. Boot Actual results: initial-setup fails to start Expected results: Initial-setup is provided Additional info: I propose this as alpha blocker as it violates the alpha criterion: Expected installed system boot behavior - A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system.
Note that "and/or" - it's specifically written *not* to require firstboot to work on paths where the installer user creation interface is shown. Basically firstboot is only *required* to work for ARM disk image deployments. (If this bug affects the ARM KDE image, though, that'd be blocker...)
As written, I'm -1 blocker on this. The criteria only requires that at least one of Anaconda or initial-setup provides the option to create a user. However, if the ARM image also doesn't run initial-setup, that would be a blocker as Adam says, because Anaconda isn't in play to offer user-creation.
Thanks for clarification of that criterion, I missed that. Then I'm -1 for blocker (if it works on ARM).
pwhalen is going to test whether this affects the ARM KDE image. I tried but hit too many issues getting some kind of ARM test environment running.
The KDE Alpha RC1 image booted to initial-setup-text on the ARM, allowing me to create a user.
Excellent! -1 blocker, no more conditions :)
Marking as rejected blocker with pwhalen's report that the ARM case seems OK (he did try a few boots). Though I guess it could conceivably vary between platforms, if it's racy.
Seems to me like an issue with either DBus, the X server or kwin according to: Aug 05 11:38:55 dhcp-28-126.brq.redhat.com org.a11y.Bus[1274]: g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting. Aug 05 11:38:55 dhcp-28-126.brq.redhat.com xinit[861]: No ksycoca database available! Tried running kbuildsycoca5 ? Aug 05 11:38:55 dhcp-28-126.brq.redhat.com xinit[861]: KServiceTypeTrader: serviceType "ActivityManager/Plugin" not found Aug 05 11:38:55 dhcp-28-126.brq.redhat.com xinit[861]: The X11 connection broke (error 1). Did the X11 server die? Aug 05 11:38:55 dhcp-28-126.brq.redhat.com xinit[861]: Couldn't start kglobalaccel from org.kde.kglobalaccel.service: QDBusError("org.freedesktop.DBus.Error.Disconnected", "Connection is closed") Aug 05 11:38:56 dhcp-28-126.brq.redhat.com xinit[861]: .error setting MTRR (base = 0xe0000000, size = 0x01000000, type = 1) Invalid argument (22)
I've just installed a test system from Fedora-Live-KDE-i686-23_Alpha-2.iso, following https://fedoraproject.org/wiki/QA:Testcase_Partitioning_No_Swap. Please note that I've used a qemu-kvm guest. But I didn't hit this bug! Since I didn't create a user via Anaconda, initial-setup was correctly started during the first boot. Strange enough, I remember the opposite scenario during the F22 testing cycle. I recall that initial-setup was working on bare metal but not on a virtual environment (bug #1202113, bug #1185447).
As long as the bug's been around, it's been like that - there's a racy element to it, whichever of the two services starts up faster wins, it seems.
(In reply to Adam Williamson from comment #10) > As long as the bug's been around, it's been like that - there's a racy > element to it, whichever of the two services starts up faster wins, it seems. The initial-setup-text.service has this: Conflicts=initial-setup-graphical.service After=initial-setup-graphical.service which used to work like: 1) run GUI IS 2) if it fails, run TUI IS But that was probably 100 major versions of systemd back so hard to say how it behaves now.
(In reply to Giulio 'juliuxpigface' from comment #9) > I've just installed a test system from Fedora-Live-KDE-i686-23_Alpha-2.iso, > following https://fedoraproject.org/wiki/QA:Testcase_Partitioning_No_Swap. > > Please note that I've used a qemu-kvm guest. > > But I didn't hit this bug! Since I didn't create a user via Anaconda, > initial-setup was correctly started during the first boot. > > Strange enough, I remember the opposite scenario during the F22 testing > cycle. I recall that initial-setup was working on bare metal but not on a > virtual environment (bug #1202113, bug #1185447). Yes, and even our testing yesterday revealed that X server crashes in VMs when run for the Initial Setup -- segmentation fault in the qxl (SPICE) driver.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.