Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1185447
Summary: | text not GUI initial-setup runs on Xfce install (Rawhide 2015-01-23) | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Adam Williamson <awilliam> | ||||
Component: | initial-setup | Assignee: | Martin Kolman <mkolman> | ||||
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 23 | CC: | awilliam, danofsatx, germano.massullo, kevin, litimetal, mkolman, ncross, pbrobinson, pschindl, pwhalen, rdieter, robatino, satellitgo, sgallagh, vpodzime | ||||
Target Milestone: | --- | Keywords: | CommonBugs | ||||
Target Release: | --- | ||||||
Hardware: | x86_64 | ||||||
OS: | Linux | ||||||
Whiteboard: | https://fedoraproject.org/wiki/Common_F22_bugs#text-initial-setup RejectedBlocker | ||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2016-02-12 18:18:43 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 245418, 1170821 | ||||||
Attachments: |
|
Description
Adam Williamson
2015-01-23 18:50:28 UTC
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. |