oem-config-remove-gtk not found during preinstalled desktop initialization

Bug #820514 reported by Tobin Davis
14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
livecd-rootfs (Ubuntu)
Fix Released
High
Adam Conrad
Oneiric
Fix Released
High
Adam Conrad

Bug Description

On the armel preinstalled images, one of the last steps is to remove oem-config and ubiquity. Currently this fails and the image is left with an installer icon on the ubiquity launcher.

Image is oeneiric alpha 3.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: ubiquity 2.7.14
ProcVersionSignature: User Name 3.0.0-1200.2-omap4 3.0.0-rc7
Uname: Linux 3.0.0-1200-omap4 armv7l
Architecture: armel
Date: Wed Aug 3 11:22:25 2011
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: ubiquity
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Tobin Davis (gruemaster) wrote :
tags: added: iso-testing
summary: - oem-config-remove-gtk not found during preinstalled dsktop
+ oem-config-remove-gtk not found during preinstalled desktop
initialization
tags: added: ubiquity-2.7.14
tags: added: oem-config
Changed in ubiquity (Ubuntu):
assignee: nobody → Canonical Foundations Team (canonical-foundations)
Changed in ubiquity (Ubuntu Oneiric):
importance: Undecided → High
Changed in ubiquity (Ubuntu Oneiric):
assignee: Canonical Foundations Team (canonical-foundations) → Evan Dandrea (ev)
Revision history for this message
Evan (ev) wrote :

These logs don't have any tracebacks in them. Was there anything in /var/crash?

Changed in ubiquity (Ubuntu Oneiric):
status: New → Incomplete
Revision history for this message
Tobin Davis (gruemaster) wrote :

No, nothing in var crash. And nothing ever seems to show up in the installer logs except "/usr/sbin/oem-config-wrapper: 2: oem-config-remove-gtk: not found".

Changed in ubiquity (Ubuntu Oneiric):
status: Incomplete → Confirmed
Revision history for this message
Tobin Davis (gruemaster) wrote :

Still happening in oneiric beta1 BTW.

Revision history for this message
Evan (ev) wrote :

This appears to be because ubiquity-frontend-gtk and oem-config-debconf are on the CD. Ubiquity running in oem-config mode will see that the GTK frontend is present and try to use that, but because you don't have oem-config-gtk installed, it will be missing files necessary to complete the install (like oem-config-remove-gtk).

The solution is to seed oem-config-gtk on your images, or if you really want to use the debconf frontend, remove ubiquity-frontend-gtk from the image seed.

Changed in ubiquity (Ubuntu Oneiric):
status: Confirmed → Incomplete
Brad Figg (brad-figg)
tags: added: rls-mgr-o-tracking
Evan (ev)
Changed in ubiquity (Ubuntu Oneiric):
assignee: Evan Dandrea (ev) → nobody
Revision history for this message
Steve Langasek (vorlon) wrote :

Per Evan, this is a seed issue with the preinstalled images, not with ubiquity.

affects: ubiquity (Ubuntu Oneiric) → ubuntu-meta (Ubuntu Oneiric)
Changed in ubuntu-meta (Ubuntu Oneiric):
assignee: nobody → Canonical ARM (canonical-arm)
status: Incomplete → Confirmed
Revision history for this message
Adam Conrad (adconrad) wrote :

This is utter madness. You can't just haphazardly select something to execute based on the fact that a package is installed. If the rest of the system worked that way, people would never get proper pagers, browsers, mail clients, etc, etc, etc when in terminals, if they just also happened to have a GUI client installed.

We use the default ubuntu live seeds (and there's no reason we should need to fork to remove one package), but we install from the text/debconf frontend. I see no reason why this shouldn't work, just because another package happens to be installed.

affects: ubuntu-meta (Ubuntu Oneiric) → ubiquity (Ubuntu Oneiric)
Changed in ubiquity (Ubuntu Oneiric):
assignee: Canonical ARM (canonical-arm) → Evan Dandrea (ev)
Revision history for this message
Evan (ev) wrote :

Are you proposing that every execution of Ubiquity require specifying the frontend? That's the alternative.

It needs to default to something, and I think iterating through the installed set of frontends in the current order is a reasonable approach. If you want to be explicit about the frontend you're using, then by all means call `ubiquity FRONTEND_NAME` or use the ubiquity/frontend= kernel command line argument that I've just copied from the ubiquity upstart job to oem-config-firstboot.

Revision history for this message
Adam Conrad (adconrad) wrote :

I might be suggesting that if $DISPLAY isn't set, calling an X application is a bit silly. See, for instance, sensible-browser. If there's a sane way for us to hack around this, I suppose we can do so, but it seems strange to me that if we start oem-config in a console frontend, it then tries to run (some) GTK binaries.

Revision history for this message
Adam Conrad (adconrad) wrote :

Okay, so this bug was rather misrepresented to me when I was asked to look at it, which led to much running around in circles until I just broke down and tested it on a machine locally and realized that we *are* using the GTK frontend, and this has nothing to do with frontend mismatches, as I'd been led to believe. :P

Fix incoming in livecd-rootfs.

Revision history for this message
Adam Conrad (adconrad) wrote :

livecd-rootfs (2.39) oneiric; urgency=low
  .
  * Explicitely select the oem-config frontend to install on a
    per-project basis, to match the ubiquity in use (LP: #820514)
  .
 -- Adam Conrad <email address hidden> Mon, 26 Sep 2011 19:14:56 -0600

affects: ubiquity (Ubuntu Oneiric) → livecd-rootfs (Ubuntu Oneiric)
Changed in livecd-rootfs (Ubuntu Oneiric):
assignee: Evan Dandrea (ev) → Adam Conrad (adconrad)
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.