I just ran a test install from a Rawhide 2015-01-23 Xfce live image, and on first boot, initial-setup-text.service was run, not initial-setup-graphical.service . Both are installed. [root@localhost test]# systemctl status initial-setup-text.service --full ● initial-setup-text.service - Initial Setup configuration program (text mode) Loaded: loaded (/usr/lib/systemd/system/initial-setup-text.service; disabled; vendor preset: enabled) Active: active (exited) since Fri 2015-01-23 10:47:28 PST; 2min 27s ago Process: 1220 ExecStartPost=/bin/kill -54 1 (code=exited, status=0/SUCCESS) Main PID: 742 (code=exited, status=0/SUCCESS) CGroup: /system.slice/initial-setup-text.service Jan 23 10:47:27 localhost.localdomain initial-setup[745]: skipping <pyanaconda.kickstart.Keyboard object at 0x7f5749a11d90> on line 13 Jan 23 10:47:27 localhost.localdomain initial-setup[745]: skipping <pyanaconda.kickstart.Lang object at 0x7f57499be810> on line 15 Jan 23 10:47:27 localhost.localdomain initial-setup[745]: skipping <pyanaconda.kickstart.Timezone object at 0x7f57499be450> on line 23 Jan 23 10:47:27 localhost.localdomain initial-setup[745]: executing <pyanaconda.kickstart.Group object at 0x7f5749a11ed0> on line 0 Jan 23 10:47:27 localhost.localdomain initial-setup[745]: executing <pyanaconda.kickstart.User object at 0x7f57499be710> on line 0 Jan 23 10:47:28 localhost.localdomain initial-setup[745]: skipping <pyanaconda.kickstart.RootPw object at 0x7f57499be090> on line 21 Jan 23 10:47:28 localhost.localdomain initial-setup[745]: executing addons Jan 23 10:47:28 localhost.localdomain initial-setup[745]: writing the Initial Setup kickstart file /root/initial-setup-ks.cfg Jan 23 10:47:28 localhost.localdomain initial-setup[745]: finished writing the Initial Setup kickstart file Jan 23 10:47:28 localhost.localdomain logger[1196]: initial_setup finished successfully, disabling [root@localhost test]# systemctl status initial-setup-graphical.service --full ● initial-setup-graphical.service - Initial Setup configuration program Loaded: loaded (/usr/lib/systemd/system/initial-setup-graphical.service; disabled; vendor preset: enabled) Active: inactive (dead)
Martin, can you please have a look at this? If both services are enabled right after the installation/during the first boot, the initial-setup-graphical.service should win the game and run successfully. That's at least how it always worked, maybe something has changed in systemd recently.
Ups, wanted to set the needinfo flag in this second step. Adam, could you please enable both of the initial-setup services and reboot?
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
Still happening with 22 Beta TC1. Both services *are* enabled - 'systemctl status initial-setup-graphical.service' shows loaded, enabled (and vendor preset: enabled). But it shows as 'inactive (dead)' and the text one is running.
It seems like the X server or the xfwm fails to start which makes the graphical service fail which then triggers the text service to run.
I see this with KDE in 22 Beta RC1.
*** Bug 1217787 has been marked as a duplicate of this bug. ***
Still seeing this with KDE in Final TC1 and 20150503 nightly. Proposing as a Final FE at least. vpod, are you getting anywhere with this?
Created attachment 1021848 [details] journalctl output from a 20150503 kde install that is affected
I note: May 04 10:57:50 localhost.localdomain systemd[1]: [/usr/lib/systemd/system/initial-setup-text.service:21] Support for option SysVStartPriority= has been removed and it is ignored May 04 10:57:50 localhost.localdomain systemd[1]: [/usr/lib/systemd/system/initial-setup-graphical.service:14] Support for option SysVStartPriority= has been removed and it is ignored May 04 10:58:06 localhost.localdomain initial-setup[706]: display mode detected: tui
Seeing this on a number of desktops with 22_TC1 (Xfce, MATE, KDE) on ARM. Rebooting the system sometimes works and initial-setup-gui runs, but not always.
see https://bugzilla.redhat.com/show_bug.cgi?id=1202113#c22 With mate live TC3 initial-setup crashed.
Discussed at the 2015-05-11 blocker review meeting[0]. Voted as AcceptedFreezeException. AGREED: 1185447 - AcceptedFreezeException - while the text i-s works fine, seeing it on a graphical install is fairly jarring and it would be good to fix that if possible (adamw, 18:03:47) [0]: http://meetbot.fedoraproject.org/fedora-blocker-review/2015-05-11/
> May 04 10:58:06 localhost.localdomain initial-setup[706]: display mode > detected: tui So my understanding of this is that it's basically a race to start. Which ever service starts first takes pole position and the other shuts down. This isn't really useful as ultimately the user has no control over that. What we really need is for them both to start and then the first to receive actual input on stdio (keyboard/serial) indicate to the other one to shut down. That way it's useful on both. This would be a potential use case for server as well where it's not unusual for a server to have both serial console (via real serial or emulated via IPMI) and a console (whether virtual, via VNC or via keyboard/video/mouse). It's a bit late to be doing the above in F-22 so I suggest for the ARM graphical images we remove the initial-setup TUI startup service symlink so it isn't able to start. If people think that's a reasonable work around for F-22 let me know and I'll push a fix to to the appropriate kickstarts.
I can definitely confirm that it is a race condition between both services. With mate TC4 iso i run into the same issue on first boot, only text setup commes up. At this point reset the VM and started in rescue target. Here i disabled initial-setup-text.service and rebooted again. Now initial-setup-graphical.service comes up without any probs. I reset the VM about x times at this point and initial-setup-graphical.service runs stable all the time. So, why not diable initial-setup-graphical.service for live desktop isos? I mean the goal of a live desktop iso is to provide a graphical desktop. When there is a issue with graphic drivers, X won't start and a user has only a multi-user.target. Here it's easy to add a user by hand or enable/start initial-setup-text.service again. I know this is a workaround for f22 but this is better than have no GUI for a desktop installation. my 0.1 cents
Clearing F22 accepted / nominated freeze exception status as F22 has shipped, per https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Trackers . You may nominate as an Alpha, Beta or Final freeze exception for F23 if desired using the web application - https://qa.fedoraproject.org/blockerbugs/propose_bug (though it is not currently set up for F23) - or by marking the bug as blocking AlphaFreezeException, BetaFreezeException, or FinalFreezeException.
The same thing seems to happen with F23 RC1. I installed two systems with KDE. On one i-s-text was started instead of graphical. I restarted a few times and it happens randomly. Sometimes the graphical is started sometimes the text mode. Both are enabled. I propose this as F23 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.
I don't really think it does, does it? I mean, you do *see* the text i-s, right? It doesn't prevent system boot?
-1 Blocker as long as the system actually boots.
A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system. That's criterion which is clearly violated. I tried to reboot few times (about 10 times) and it was 50/50. So 50% of first boots won't get i-s. When text mode is used nothing appears (you can just see from systemctl status initial-setup-text that it run). Still this seems to be minor issue as it is enough just to reboot (at most few times). So -1 for Alpha blocker. But then I would repropose this to final.
OK. I'm totally -1 due to https://bugzilla.redhat.com/show_bug.cgi?id=1250409#c1
As we have a separate bug for KDE, which would be the one that will block ARM if this issue occurs on ARM, and we have 3 -1s, I'm marking this as RejectedBlocker. It'd be nice to finally fix the damn thing, though, and the issue may still be a blocker if it occurs on the ARM KDE image and prevents it being practically usable.
Ultimately the way initial-setup runs is that if it starts first on text it doesn't start on DUI. What is should be doing is running on both and have some form of lock file or mechanism to signal to the other instance when someone starts imputing information
I'm not sure that seems like an inherently better design, both have complexities. If you run both you have to be pretty careful to take both down when one is complete (otherwise you've got a root password reset screen just hanging around for someone to find). And if both run how do we make sure the graphical one is displayed if it runs (which is what we want)? Not sure we need to be re-engineering it, it just needs fixing to work as currently intended (only run one or the other, GUI by preference).
(In reply to Adam Williamson from comment #24) > I'm not sure that seems like an inherently better design, both have > complexities. If you run both you have to be pretty careful to take both > down when one is complete (otherwise you've got a root password reset screen > just hanging around for someone to find). And if both run how do we make > sure the graphical one is displayed if it runs (which is what we want)? Well the idea is that if they both run they'll both be displayed, and when one receives input the other exits, and obviously they both cease to run on a completed config like it currently does > Not sure we need to be re-engineering it, it just needs fixing to work as > currently intended (only run one or the other, GUI by preference). Well the way I understand it is it is running as current designed, if not intended, as the second one to start exits. Up until now I think it's been purely luck that it's mostly worked. On ARM we've seen issues on an off for a few releases and to date the fix has been to reboot.
*** Bug 1202113 has been marked as a duplicate of this bug. ***
(In reply to Petr Schindler from comment #20) > A working mechanism to create a user account must be clearly presented > during installation and/or first boot of the installed system. > > That's criterion which is clearly violated. > > I tried to reboot few times (about 10 times) and it was 50/50. So 50% of > first boots won't get i-s. When text mode is used nothing appears (you can > just see from systemctl status initial-setup-text that it run). > > Still this seems to be minor issue as it is enough just to reboot (at most > few times). So -1 for Alpha blocker. But then I would repropose this to > final. I'm using Fedora 23 Beta on x86_64, and this problem still exists as you described.
proposing as a Final blocker, then. So to be absolutely clear: sometimes, on first boot of the ARM minimal and/or Xfce disk image, you don't see i-s?
This should be fixed now - there are no longer two Initial Setup services ("initial-setup-text.service" and "initial-setup-graphical.service") but just a single service called "initial-setup.service". As for the triggering of what will run - this is now simply based on installed packages - if you install just "initial-setup", you will get the TUI. If you also install "initial-setup-gui", you will get the GUI. The fallback are also still there - if the GUI fails to start for some reason, Initial Setup should automatically fall back to running the TUI.