Bug 670379

I've looked at the systemd.service documentation, andthere are no Environment, StandardInput and ValidNoProcess options.

Lennart is it OK, if I just remove those lines from the service files, or should they be substituted with something else?

In my testing, the presence of this bug, and no firstboot configuration, doesn't offer a graphical method for non-root user creation after install.

I'm having a hard time determining if this issue impacts the Alpha release criteria.  Adding 'F15Alpha' to request review of this issue during this weeks F15 Alpha Blocker Review meeting.

we have two desktop validation tests set as Alpha - Firefox browsing and updating the system - and you can't do those properly if you can't create a non-root user.

The relevant criteria are "In most cases, the installed system must boot to a functional graphical environment without user intervention (see Blocker_Bug_FAQ) " and "It must be possible to run the default web browser and a terminal application from the default desktop environment. The web browser must be able to download files, load extensions, and log into FAS".

*** Bug 676533 has been marked as a duplicate of this bug. ***

Leaving notes on proposed blockers as I won't be at the meeting tomorrow most likely:

Per my comment above, +1 blocker.

Note the reason that firstboot does not work is not the "ValidNoProcess=yes" systemd just ignores it 

I notice several issues with Firstboot when fiddling with it yesterday.. 

The first boot code needs to be rewritten to handle systemd definiton of runlevels. 

For instance it craps on runlevel S looks like the code expects integere and why is it checking what runlevel it is in the first it makes no sense to me it should just check if X if not try to startX and fallback into text mode if that fails. 

It needs to be from the looks of it ported to GTK3 and mutter added as one of the window managers to start/check for.

And whatever is checking if X is running in the code is broken or needs to be updated to reflect changes in. ( This I believe is the cause for it not to start )

And it looks like the native systemd files is just a layer on top of the traditional sysv init script which is just a hack from my perspective instead of just taking the time to properly porting the old init script to systemd ( as opposed to stuffing systemd stuff in that init script and continuing to use that ).

Honestly you probably need drop this ancient spaghetti mess from Chris pick all the usable mead balls from the code ( if any )  and write firstboot from scratch reflecting recent changes python gtk systemd X gnome dbus etc.. 

If the plan is to rewrite the code before beta I think that firstboot should not be consider a blocker if not it is..

Btw ValidNoProcess= got renamed to RemainAfterExit. . . .

Per 2011-02-11 Alpha blocker bug meeting - 
AGREED: 670379 - accepted as F15Alpha release blocker as this impacts ability login as non-root user and also hits Alpha desktop criteria

Yes, all that's necessary here is to apply s/ValidNoProcess=/RemainAfterExit=/.

We renamed that quite some time ago on request of a lot of users who found ValidNoProcess not very explicative.

Note that replacing ValidNoProcess to RemainAfterExit will fix the reported error but firstboot still does not start ( as I expected ).

[   21.372706] systemd[1]: Forked /etc/init.d/firstboot as 913
[   21.378233] systemd[1]: firstboot-graphical.service changed dead -> start 
[   32.581794] systemd[1]: Got SIGCHLD for process 913 (firstboot)
[   32.588076] systemd[1]: Child 913 died (code=exited, status=1/FAILURE)
[   32.593835] systemd[1]: Child 913 belongs to firstboot-graphical.service
[   32.597771] systemd[1]: firstboot-graphical.service: main process exited, code=exited, status=1
[   32.602058] systemd[1]: firstboot-graphical.service changed start -> failed
[   32.605939] systemd[1]: Job firstboot-graphical.service/start finished, success=no
[   32.613554] systemd[1]: Unit firstboot-graphical.service entered failed state.

Tested on TC2 

Still a valid blocker bug

Note this is actually what's happening.. 

firstboot DEBUG: X is already running, not using any frontend <--- Whatever is detecting this is broken.. 

Traceback (most recent call last):
  File "/usr/sbin/firstboot", line 175, in <module>
    from firstboot.interface import *
  File "/usr/lib/python2.7/site-packages/firstboot/interface.py", line 20, in <module>
    import gtk
  File "/usr/lib/python2.7/site-packages/gtk-2.0/gtk/__init__.py", line 64, in <module>
    _init()
  File "/usr/lib/python2.7/site-packages/gtk-2.0/gtk/__init__.py", line 52, in _init
    _gtk.init_check()
RuntimeError: could not open display


Just a side note here switching to VT in runlevel 5 login as root and running 

export DISPLAY=":0.0" ( this will fix the gtk python error ) 
firstboot

Will start firstboot fine

Same does apply for runlevel three 

Login 
run startx
( note that firstboot is saying that X is already running even thou you have not started it ) 
export DISPLAY=":0.0"
firstboot

The check if we have X checks if we have a DISPLAY environment variable, so it looks like there is one, even if X is not running.

I'm getting a different traceback than you are. In my case, it wants to start the X server, but it fails, and I don't know why yet.

Is it not better to check if X actually is running then relying on a environmental variable?  

And you should consider adding a check like..  

if 'DISPLAY' in os.environ:
    return

That's exactly what firstboot checks. The error with gtk you got is something else. You switched to a VT from running X, so you got X running already, so the check is OK, it just didn't find the display to connect to, so after you did the export DISPLAY manually, it worked. But firstboot is not supposed to be run in this way. It's supposed to be run by init (systemd). Let me check my patch with Alpha...

Remember to fix the systemd service files and dont you need to add mutter xfrontend.py?

Is it already in F15? I don't think we need this yet.

(In reply to comment #17)
> Is it already in F15? I don't think we need this yet.

Yeah, mutter is in F15.  I agree, we don't need this now ... at least, not in this bug.  Switching firstboot to use mutter should be tracked as different bug/feature request.

firstboot-1.116-1.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/firstboot-1.116-1.fc15

It's still broken. . .

Uhum my bad confirm fixed.. 
( removed and reinstall to clear my own fiddeling with the code.. )

I'm glad to hear that.

*** Bug 677675 has been marked as a duplicate of this bug. ***

Confirmed that firstboot-1.116-1 resolves the reported issue for me too.

firstboot-1.116-1.fc15 has been pushed to the Fedora 15 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update firstboot'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/firstboot-1.116-1.fc15

firstboot-1.117-1.fc15 was pushed to stable

Package firstboot-1.117-2.fc15:
* should fix your issue,
* was pushed to the Fedora 15 updates-testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing firstboot-1.117-2.fc15'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/firstboot-1.117-2.fc15
then log in and leave karma (feedback).

firstboot-1.117-2.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.