Bug 1127450

Also seen in Fedora-Live-KDE-x86_64-21-20140805.iso

why does the lack of a filled in user not trigger a pop-up in anaconda like the one triggered if both root and user are blank?

console is available on ctrl-alt-f4 and ctrl-alt-f6. From there, I was able to log in as root and get the logs.


Aug  6 16:57:47 localhost xinit: kdeinit4: Aborting. $HOME not set!kdeinit4: Aborting. $HOME not set!kwin(991): Couldn't start kglobalaccel from kglobalaccel.desktop:  "KLauncher could not be reached via D-Bus. Error when calling start_service_by_desktop_path:
Aug  6 16:57:47 localhost xinit: The name org.kde.klauncher was not provided by any .service files
Aug  6 16:57:47 localhost xinit: "
Aug  6 16:57:48 localhost xinit: kdeinit4: Aborting. $HOME not set!kactivitymanagerd(1093): No ksycoca4 database available!
Aug  6 16:57:48 localhost xinit: kactivitymanagerd(1093)/kdecore (trader) KServiceTypeTrader::defaultOffers: KServiceTypeTrader: serviceType  "ActivityManager/Plugin"  not found
Aug  6 16:57:48 localhost xinit: kdeinit4: Aborting. $HOME not set!kwin(991): No ksycoca4 database available!
Aug  6 16:57:48 localhost xinit: kwin(991)/kdecore (trader) KServiceTypeTrader::defaultOffers: KServiceTypeTrader: serviceType  "KWin/Script"  not found
Aug  6 16:57:48 localhost xinit: kdeinit4: Aborting. $HOME not set!kwin(991): No ksycoca4 database available!
Aug  6 16:57:48 localhost xinit: kwin(991)/kdecore (trader) KServiceTypeTrader::defaultOffers: KServiceTypeTrader: serviceType  "KWin/Effect"  not found
Aug  6 16:57:49 localhost avahi-daemon[607]: Server startup complete. Host name is linux-2.local. Local service cookie is 3115009440.
Aug  6 16:57:49 localhost avahi-daemon[607]: Registering new address record for fe80::5054:ff:fee3:ca36 on eth0.*.
Aug  6 16:57:49 localhost org.a11y.Bus: GLib-GIO-Message: Using the 'memory' GSettings backend.  Your settings will not be saved or shared with other applications.
Aug  6 16:57:49 localhost org.a11y.Bus: Activating service name='org.a11y.atspi.Registry'
Aug  6 16:57:49 localhost org.a11y.Bus: Successfully activated service 'org.a11y.atspi.Registry'
Aug  6 16:57:49 localhost org.a11y.atspi.Registry: SpiRegistry daemon is running with well-known name - org.a11y.atspi.Registry
Aug  6 16:57:49 localhost org.a11y.atspi.Registry: Xlib:  extension "XEVIE" missing on display ":9".
Aug  6 16:57:49 localhost anaconda: Running Thread: AnaInputThread1 (140094129506048)
Aug  6 16:57:49 localhost xinit: ================================================================================
Aug  6 16:57:49 localhost xinit: ================================================================================
Aug  6 16:57:49 localhost xinit: Initial setup of Fedora 21 (Twenty One)
Aug  6 16:57:49 localhost xinit: 1) [ ] User creation
Aug  6 16:57:49 localhost xinit: (No user will be created)
Aug  6 16:57:49 localhost xinit: Please make your choice from above ['q' to quit | 'c' to continue |
Aug  6 16:57:49 localhost python: detected unhandled Python exception in '/usr/lib/python2.7/site-packages/initial_setup/__main__.py'
Aug  6 16:57:49 localhost abrt-server: Can't load public GPG key /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-22-secondary
Aug  6 16:57:49 localhost abrt-server: Can't load public GPG key /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-22-secondary
Aug  6 16:57:49 localhost abrt-server: Can't load public GPG key /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-22-secondary
Aug  6 16:57:49 localhost abrt-server: Can't load public GPG key /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-22-secondary
Aug  6 16:57:49 localhost abrt-server: Can't load public GPG key /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-22-secondary
Aug  6 16:57:49 localhost abrt-server: Can't load public GPG key /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-22-secondary
Aug  6 16:57:49 localhost abrt-server: Duplicate: core backtrace
Aug  6 16:57:49 localhost abrt-server: DUP_OF_DIR: /var/tmp/abrt/Python-2014-08-06-16:51:36-1056
Aug  6 16:57:49 localhost abrt-server: Deleting problem directory Python-2014-08-06-16:57:49-1000 (dup of Python-2014-08-06-16:51:36-1056)
Aug  6 16:57:49 localhost anaconda: Thread Done: AnaInputThread1 (140094129506048)
Aug  6 16:57:49 localhost xinit: 'r' to refresh]: Traceback (most recent call last):
Aug  6 16:57:49 localhost xinit: File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 227, in run
Aug  6 16:57:49 localhost xinit: threading.Thread.run(self, *args, **kwargs)
Aug  6 16:57:49 localhost xinit: File "/usr/lib64/python2.7/threading.py", line 766, in run
Aug  6 16:57:49 localhost xinit: self.__target(*self.__args, **self.__kwargs)
Aug  6 16:57:49 localhost xinit: File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/tui/simpleline/base.py", line 159, in _thread_input
Aug  6 16:57:49 localhost xinit: data = raw_input()
Aug  6 16:57:49 localhost xinit: EOFError: EOF when reading a line

oh wow...that looks hideous. Attaching as a file instead.

Created attachment 924632 [details]
xinit logs from KDE Live 0806

snippet of the logs from a failed F21 KDE Live build showing the xinit errors causing a black screen on first boot if no users defined.

From the logs, it looks like initial-setup is starting up in text mode (rather than GUI mode) with no tty attached, is that what's going on? I'm reassigning this to initial-setup for now, if this isn't your fault, please reassign it further to whom you think is really to blame.

(And if it's our kickstart's fault, please tell us how to fix it.)

Proposing as a blocker due to violating Alpha criteria of "A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system." I am emphasizing the "and" portion of the "and/or" operator.

Additionally, the criteria "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility." is also applicable - in current state, it does not boot to a login screen after installation.

Just to give us more information, could you please test if the same issue happens after Xfce/LXDE installation?

(In reply to Kevin Kofler from comment #6)
> From the logs, it looks like initial-setup is starting up in text mode
> (rather than GUI mode) with no tty attached, is that what's going on? I'm
> reassigning this to initial-setup for now, if this isn't your fault, please
> reassign it further to whom you think is really to blame.
Initial Setup tries to fall back to text mode if the graphical mode fails. From the logs it seems to me that kwin doesn't start.

> From the logs it seems to me that kwin doesn't start.

That would be kde-workspace's fault then, reassigning.

(In reply to Vratislav Podzimek from comment #9)
> Just to give us more information, could you please test if the same issue
> happens after Xfce/LXDE installation?

XFCE exhibits exact same error. Attaching journal next.

Created attachment 924955 [details]
xfce journal

xfce exhibits exact same error with xinit not starting. Attached journal will show the same errors as KDE.

This is also confirmed on the following LXDE images:
Fedora-Live-LXDE-i686-rawhide-20140805
Fedora-Live-LXDE-x86_64-rawhide-20140805
Fedora-Live-LXDE-x86_64-21-20140805

I'll attached xinit logs for each (from journal).

Created attachment 924991 [details]
xinit.log from LXDE 21 0805 Live Image

Created attachment 924992 [details]
xinit.log from LXDE Rawhide 0805 i386 Live Image

Created attachment 924993 [details]
xinit.log from LXDE Rawhide 0805 x86_64 Live Image

From poking at initial-setup, it seems that 'import gui' in __main__.py (line 78) fails setting mode to 'tui.'

That's enough evidence to bump this bug back to initial-setup.

The workaround for this is to drop to another tty, and then drop the run level to 3. This will let you finish out the user configuration from the cmdline. Reboot once that's finished and you have a working system.

OK guys, you're right, I think I can now see the issue. But the big issue here is probably a terrible lack of debug information in the logs.

Discussed at the 2014-08-13 blocker review meeting:
http://meetbot.fedoraproject.org/fedora-blocker-review/2014-08-13/

Accepted as an Alpha blocker. This bug clearly violates the alpha criterion: "A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system."

Discussed in 2014-08-20 Blocker Review Meeting [1].

(06:53:48 PM) kparal: #info this will be tested with the next functional compose


[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-08-20/

just did a boot.iso (boot-f21-0819.iso) install of KDE to VirtualBox:

Test: added root but no user in anaconda
On boot :
"Permit user sessions" then login manager. logged in to root. Search to Users
Created User and logged out "Permit user sessions" logged in as new user.
Seems to be fixed.

Fedora-Live-KDE-x86_64-21-20140819.iso  install of KDE to VirtualBox:

Test: added root but no user in anaconda

At finish of install get pop-up:

Initial setup
 USER
[Finish Install]
On reboot logs in to KDE user
Seems to be fixed.

nothing needs pushing, the fix landed in initial-setup long before freeze, so closing this.