Bug 670379 - Unknown lvalue 'ValidNoProcess' in section 'Service'.
Summary: Unknown lvalue 'ValidNoProcess' in section 'Service'.
Alias: None
Product: Fedora
Classification: Fedora
Component: firstboot
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Martin Gracik
QA Contact: Fedora Extras Quality Assurance
Whiteboard: AcceptedBlocker
: 676533 677675 (view as bug list)
Depends On:
Blocks: F15Alpha, F15AlphaBlocker
TreeView+ depends on / blocked
Reported: 2011-01-18 05:11 UTC by John Reiser
Modified: 2013-07-04 12:53 UTC (History)
9 users (show)

Fixed In Version: firstboot-1.117-2.fc15
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-02-21 14:51:51 UTC
Type: ---

Attachments (Terms of Use)

Description John Reiser 2011-01-18 05:11:14 UTC
Description of problem: At the first boot after installation, then firstboot fails with complaints from systemd.

Version-Release number of selected component (if applicable):

How reproducible: every time

Steps to Reproduce:
1. Compose install DVD for x86_64 from rawhide via pungi [uses lorax].
2. Fresh install DVD using defaults, General Internet desktop.
3. Boot newly-installed system.
Actual results: firstboot fails.  From console messages via 'dmesg':
[    8.227041] systemd[1]: [/lib/systemd/system/firstboot-graphical.service:12] Unknown lvalue 'ValidNoProcess' in section 'Service'. Ignoring.
[    8.228265] systemd[1]: [/lib/systemd/system/firstboot-text.service:11] Unknown lvalue 'ValidNoProcess' in section 'Service'. Ignoring.

Expected results: firstboot runs successfully: set date+time, create ordinary user account, etc.

Additional info: The actual files are:
Description=firstboot configuration program (graphical mode)

ExecStart=/etc/init.d/firstboot start


Description=firstboot configuration program (text mode)

ExecStart=/etc/init.d/firstboot start


Comment 1 Martin Gracik 2011-01-18 11:43:03 UTC
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?

Comment 2 James Laska 2011-02-08 20:12:22 UTC
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.

Comment 3 Adam Williamson 2011-02-08 21:30:32 UTC
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".

Comment 4 He Rui 2011-02-10 09:36:26 UTC
*** Bug 676533 has been marked as a duplicate of this bug. ***

Comment 5 Adam Williamson 2011-02-11 08:34:12 UTC
Leaving notes on proposed blockers as I won't be at the meeting tomorrow most likely:

Per my comment above, +1 blocker.

Comment 6 Jóhann B. Guðmundsson 2011-02-11 12:21:55 UTC
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..

Comment 7 Jóhann B. Guðmundsson 2011-02-11 16:08:06 UTC
Btw ValidNoProcess= got renamed to RemainAfterExit. . . .

Comment 8 Robyn Bergeron 2011-02-11 19:25:05 UTC
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

Comment 9 Lennart Poettering 2011-02-14 16:38:30 UTC
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.

Comment 10 Jóhann B. Guðmundsson 2011-02-15 09:38:38 UTC
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

Comment 11 Jóhann B. Guðmundsson 2011-02-15 10:51:54 UTC
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>
  File "/usr/lib/python2.7/site-packages/gtk-2.0/gtk/__init__.py", line 52, in _init
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 ) 

Will start firstboot fine

Same does apply for runlevel three 

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

Comment 12 Martin Gracik 2011-02-15 11:06:32 UTC
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.

Comment 13 Martin Gracik 2011-02-15 11:49:48 UTC
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.

Comment 14 Jóhann B. Guðmundsson 2011-02-15 12:34:02 UTC
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:

Comment 15 Martin Gracik 2011-02-15 13:04:51 UTC
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...

Comment 16 Jóhann B. Guðmundsson 2011-02-15 13:20:34 UTC
Remember to fix the systemd service files and dont you need to add mutter xfrontend.py?

Comment 17 Martin Gracik 2011-02-15 13:36:11 UTC
Is it already in F15? I don't think we need this yet.

Comment 18 James Laska 2011-02-15 13:48:45 UTC
(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.

Comment 19 Fedora Update System 2011-02-15 14:18:00 UTC
firstboot-1.116-1.fc15 has been submitted as an update for Fedora 15.

Comment 20 Jóhann B. Guðmundsson 2011-02-15 14:29:44 UTC
It's still broken. . .

Comment 21 Jóhann B. Guðmundsson 2011-02-15 14:39:13 UTC
Uhum my bad confirm fixed.. 
( removed and reinstall to clear my own fiddeling with the code.. )

Comment 22 Martin Gracik 2011-02-15 14:49:42 UTC
I'm glad to hear that.

Comment 23 Martin Gracik 2011-02-15 15:08:43 UTC
*** Bug 677675 has been marked as a duplicate of this bug. ***

Comment 24 James Laska 2011-02-15 16:49:47 UTC
Confirmed that firstboot-1.116-1 resolves the reported issue for me too.

Comment 25 Fedora Update System 2011-02-15 17:28:49 UTC
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

Comment 26 Dennis Gilmore 2011-02-21 14:51:51 UTC
firstboot-1.117-1.fc15 was pushed to stable

Comment 27 Fedora Update System 2011-02-25 22:00:47 UTC
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:
then log in and leave karma (feedback).

Comment 28 Fedora Update System 2011-02-26 04:39:56 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.