#9816 BLOC 1.5-sof: Firstboot: sugar profile creation failing due to gconf error in os54

[Zarro Boogs per Child]

#9816: Firstboot: sugar profile creation failing due to gconf error in os54
-----------------------+----------------------------------------------------
 Reporter:  sj         |                 Owner:  cjb                              
     Type:  defect     |                Status:  new                              
 Priority:  blocker    |             Milestone:  1.5-software-beta                
Component:  distro     |               Version:  Development build as of this date
 Keywords:  firstboot  |           Next_action:  diagnose                         
 Verified:  0          |   Deployment_affected:                                   
Blockedby:             |              Blocking:                                   
-----------------------+----------------------------------------------------
 I clean-installed os54 on q3a18 today on two machines.  Both times
 encountering this error: on firstboot, after choosing name/profile colors,
 configuration isn't saved and transition to the home screen is stalled at
 a blank white screen w/cursor

 shell.log has this error:

 Traceback (mst recent call last):
  File "usr/lib/python2.6/site-packages/jarabe/intro/window.py", line 258
 in _create_profile_cb
 create profile(name, color)
  File "usr/lib/python2.6/site-packages/jarabe/intro/window.py", line 48,
 in create_profile
 client.set_string("/desktop/sugar/user/nick", name)

 glib.GError: no database available to save your configuration: unable to
 store a value at key '/desktop/sugar/user/nick', as the configuration
 server has no writable databases.  There are some common causes of this
 problem: 1) your configuration path file /etc/gconf/2/path doesn't contain
 any databases or wasn't found 2) somehow we mistakenly created two gconfd
 processes 3) your operating system is misconfigured so NFS file locking
 doesn't work in your home directory or 4) your NFS client machine crashed
 and didn't properly notify the server on reboot that file locks should be
 dropped.  If you have two gconfd processes (or had two at the time the
 second was launched), logging out, killing all copies of gconfd, and
 logging back in may help.  If you have stale locks, remove
 ~/.gconf*/*lock.  Perhaps the problem is that you attempted to use GConf
 from two machines at once, and ORBit still has ts default configuration
 that prevents remote CORBA connections - put "ORBITOPIPv4=1" in
 /etc/orbitrc.  As always, check the user.* syslog for details on problems
 gconfd encountered.  There can only be one gconfd per home directory, and
 it must own a lockfile in ~/.gconfd and also lockfiles in individual
 storage locations such as ~/.gconf

-- 
Ticket URL: <http://dev.laptop.org/ticket/9816>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system