oem-config-prepare works, but oem-config fails to start after reboot

[Ronald McCollam]

Binary package hint: ubiquity

Discovered testing the maverick amd64 alternate release candidate (20100928.1) image in OEM mode in VirtualBox.

oem-config-prepare appears to run correctly after install. However, after rebooting, the OEM user is again logged in and the initial user configuration does not occur. This is repeatable -- re-running oem-config-prepare and rebooting has the same (null) effect.

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: oem-config 2.4.4
ProcVersionSignature: Ubuntu 2.6.35-22.33-generic 2.6.35.4
Uname: Linux 2.6.35-22-generic x86_64
Architecture: amd64
Date: Tue Sep 28 18:53:57 2010
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release Candidate amd64 (20100928.1)
PackageArchitecture: all
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_US.utf8
 SHELL=/bin/bash
SourcePackage: ubiquity

[Evan (ev)]

Ronald,

Can you please boot with --debug on the kernel command line after running oem-config-prepare? This should print upstart debugging information to syslog, which I would then ask you to attach to this bug report along with /var/log/installer/*

Thanks!

[Jonathan Riddell (jr)]

works for me, kubuntu alternate i386 20100907

[Colin Watson (cjwatson)]

I tried the current Ubuntu alternate i386 daily build in KVM and couldn't reproduce this.

[Colin Watson (cjwatson)]

Also tried with Ubuntu alternate amd64 on real hardware. No dice. Ronald, if it's still reproducible for you, would it be possible to narrow it down at all so that we can construct a reproduction case? Thanks.

[Jeff Lane  (bladernr)]

I just recreated this on a VM with Kubuntu 64bit via the Alternate CD.

Installed OEM via d-i, after reboot I ran oem-config-prepare which claims to have run successfully and also claims that oem-config will run on next reboot.

Rebooted the VM, and on the next reboot, I was again logged in automatically as the OEM user and the oem-prepare icon was still on the desktop.

This is using the latest Kubuntu Alternate 64bit ISO spin for today... (synced about 30 minutes ago)

[Evan (ev)]

If you can reproduce the bug, please put --debug on the kernel command line after you run oem-config-prepare, in the boot for the oem-config run.

[aaron (aaron-zareason)]

We're getting the problem on several machines. We use oem-config-prepare for all our computers, and build many every day. The issue is intermittent, even though we always follow the same steps on every install, so reproducing it is going to take more than just one try. However, many of our machines are having the problem where they log back into the oem account after running oem-config-prepare. As you can imagine, this is frustrating because we have customers waiting for us to send them their computers, and running several installs until the oem-config-prepare 'takes' costs us time.

[Nephila (nephila-it)]

Hi,
I'm having the same problems that aaron and Jeff Lane described when trying to install ubuntu 10.10 alternate amd64 on several machines.
I experienced the "still oem user on next reboot" most of the times but apparently also some successful hits, don't have idea how to troubleshoot this still being an extremely useful functionality for working on several installations like us.
Tried on both physical and vmwares always selecting OEM option via the f4 menu at the grub graphic boot prompt.
i'll try the --debug option and share some logs
thanks for helping

[Nephila (nephila-it)]

attaching some logs after experienced the problem with oem-config-prepare, after reboot
--debug option on kernel line should be enabled.

[Pedro Villavicencio (pedro)]

I'm getting a similar issue with Natty Alt i386 image, i'm attaching the logs.

[Colin Watson (cjwatson)]

I'm afraid --debug doesn't seem to be helping me track this down. Could you add 'debug-oem-config' to the kernel command line in addition to that? Thanks ...

[Pedro Villavicencio (pedro)]

attaching the requested logs (/var/log/syslog; /var/log/installer/ and /var/log/oem-config.log), Thanks!.

[Nephila (nephila-it)]

Maybe it's related to https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/644638
If i stop gdm from starting on first boot after prepare and start oem-config in rc.local afterwards, oem-config is loaded correctly and the wizard succedes.

As a side note: when the problem arise a "sudo whatever" (or gksudo) in the oem user gnome session makes the session crash and brings me to the gdm login screen.

[Earl Malmrose (earl)]

I'm seeing this happen if I load the proprietary Nvidia drivers on a 64-bit Ubuntu 10.10 install.

[Alessio Treglia (quadrispro)]

I can confirm this.

[Removed by request (stoni.ch-deactivatedaccount)]

Hello, we can reproduce this with amd64 and i368 of 10.10 with remastered systems updated to current level as of today. Like Nephila observed in #14, the invocation of oem-config fails falling back to regular/previous desktop login variant.
Regards, dsto
***

[Carl Richell (carlrichell)]

This bug also effects System76. We think this is a race condition as described in bug #644638.

The bug is reproducible 100% of the time on fast hardware (particularly nVidia with SSD's). If we cause gdm to pause for 5 seconds, oem-config will run; however, gdm then starts in the background on VT1 while oem-config is on VT7.

We have tried a couple workarounds to no avail.

1.) pause GDM if /var/lib/oem-config/run exist. While this works to start oem-config, the user is dropped to an error message and a reboot is required to reach their login.
1.) exit GDM if /var/lib/oem-config/run exist. System doesn't boot.

It seems that Upstart's "start on starting gdm" isn't precise enough to ensure oem-config starts before GDM on fast hardware.

[Carl Richell (carlrichell)]

This workaround has been successful for us. Modify /etc/init/oem-config.conf removing the "or stopping rc RUNLEVEL=[2345]" line.

from:

start on (starting gdm
          or starting kdm
          or starting xdm
          or starting uxlaunch
          or stopping rc RUNLEVEL=[2345])

to

start on (starting gdm
          or starting kdm
          or starting xdm
          or starting uxlaunch)

[Removed by request (stoni.ch-deactivatedaccount)]

Tested workaround which was not working here. Please assist, this bug is affecting two major rollouts due by beginning of january. Thx

[Jean-Baptiste Lallement (jibel)]

After some investigation I think it is a possible race with upstart jobs.

If I boot in rescue mode instead of normal boot after the oem-config-prepare step, suddenly X starts, and the user configuration step begin.
If I boot with --verbose and without 'quiet splash' on the kernel command line, the boot is much slower and ubiquity starts as expected. This suggests a race of some kind.

A guess is that the upstart job for oem-config starts too early.
Removing the following line from the oem-config upstart job:
----
or stopping rc RUNLEVEL=[2345])
----

to force the oem-config job to start when gdm starts helps to workaround the issue. This is just a suggestion and I don't know if its the right fix.

[Jean-Baptiste Lallement (jibel)]

Here is the syslog that shows the sequence in which jobs are started/stopped

[Evan (ev)]

from #ubuntu-installer, for historical context:

(10:08:29) Evan: hmm, if oem-config starts on stopping rc, then conceivably gdm could start shortly thereafter as oem-config isn't in the start on starting gdm condition, thus if oem-config takes a bit long to get to X startup in ubiquity-dm, gdm could have already started X on vt7
(10:09:59) Evan: (going off of this http://paste.ubuntu.com/568103/ )
(10:30:58) Evan: hm, accommodating the debconf frontend in the upstart job is going to be a bit tricky, it seems.
(15:46:30) superm1: ev, what about in the oem-config-debconf package ship an additional dummy job and have the standard job start on that dummy job's start?
(15:51:05) superm1: something like this: http://pastebin.com/jGEakyr9

[Launchpad Janitor (janitor)]

This bug was fixed in the package ubiquity - 2.5.16

---------------
ubiquity (2.5.16) natty; urgency=low

  [ Evan Dandrea ]
  * Rename the keyboard layout guessing button (LP: #717500).
  * Install oem-config-slideshow-ubuntu alongside oem-config-gtk.
  * Fix accessibility support in the installer session.
  * Automatic update of included source packages: flash-kernel
    2.28ubuntu14, partman-auto 93ubuntu5.

  [ Mario Limonciello ]
  * Create a dummy job for oem-config-debconf to prevent race
    conditions with oem-config-gtk and gdm. (LP: #650703)
 -- Evan Dandrea <email address hidden> Sun, 20 Feb 2011 03:00:54 +0000

[Matt Sealey (mwsealey)]

Requesting a super immediate update to Maverick as this is affecting our distribution support for Efika MX..

[aaron (aaron-zareason)]

If this bug was fixed why are we still seeing it with the latest Maverick?

[aaron (aaron-zareason)]

By the way, we've found that if we force the grub menu, and use the recovery option in grub, instead of a recovery menu, oem-config takes over. This is reproducible %100 of the time when we get this 'oem' bug.

Also, when logging into the desktop after an oem-config, pressing enter at any time crashes the desktop (we get logout).

[Ramón Rocha (ramon.rocha)]

oem-config

[Ramón Rocha (ramon.rocha)]

Sorry, wrong field. Meant to search, please delete my comments if possible.

[Colin Watson (cjwatson)]

Sorry for the delay on backporting this. I've uploaded Lucid and Maverick versions now, waiting for approval.

[Martin Pitt (pitti)]

Hello Ronald, or anyone else affected,

Accepted ubiquity into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Martin Pitt (pitti)]

Hello Ronald, or anyone else affected,

Accepted ubiquity into maverick-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Jean-Baptiste Lallement (jibel)]

SRU verification for Lucid:
I have reproduced the problem with ubiquity 2.2.26 in lucid-updates and have verified that the version of ubiquity 2.2.27 in -proposed fixes the issue.

I forced the race by changing the last line of /etc/init/udev.conf to
post-start script
     kill -USR1 1
     sleep 10
 end script

I also tried without this and never been able to reproduce the problem with 2.2.27. I have not seen any regression.
I tried oem installation of latest desktop, alternate and DVD on i386 and amd64

Marking as verification-done

[Colin Watson (cjwatson)]

Great, thanks. We'll skip the waiting period for this since (a) it doesn't affect upgrades and (b) we need it for 10.04.3.

[Launchpad Janitor (janitor)]

This bug was fixed in the package ubiquity - 2.2.27

---------------
ubiquity (2.2.27) lucid-proposed; urgency=low

  * Separate out oem-config-debconf into a new Upstart job which is only
    installed in the oem-config-debconf package, to prevent race conditions
    between oem-config-gtk and gdm (thanks, Mario Limonciello; LP: #650703).
 -- Colin Watson <email address hidden> Mon, 18 Jul 2011 13:45:33 +0100

[JC Hulce (soaringsky)]

This bug affects Ubuntu 10.10, Maverick Meerkat. Maverick has reached end-of-life and is no longer supported, so I am closing the bugtask for Maverick. Please upgrade to a newer version of Ubuntu.
More information here: https://lists.ubuntu.com/archives/ubuntu-announce/2012-April/000158.html