[Feature Request] OEM config should have bulletproof X support

[Mario Limonciello]

Binary package hint: oem-config

Sometimes a factory install can be ran through in a fully text based mode. When this happens there is a chance that OEM config may fail to start on the first boot due to a variety of extenuating circumstances.

When this happens, you get thrown into a root shell with no idea what's going on.

Instead, OEM config should fall back to bulletproofX like how GDM does.

[Loye Young (loyeyoung)]

This is a very bad idea, and should NOT be implemented.

OEM config SHOULD degrade to a command line if it does not complete correctly. In fact, the "bulletproofX" would make make it harder to debug and correct problems. If the system doesn't complete configuration of the system, the right way to debug and fix problems is from the command line, because the X display itself will obfuscate issues and interfere with the results of various debugging procedures. Worse, the changes made to the system by bulletproofX would introduce new problems to the final configuration, creating defects that may not be apparent until the customer begins using the system.

"you get thrown into a root shell with no idea what's going on."
Respectfully, if you don't know what's going on from the command line, you should be using the regular desktop installation CD instead. OEM config should NOT be used by anyone who does not understand how to engineer the box and fix things from the command line.

If you are an OEM or system builder but don't have sufficient resources to engineer your product so that you can efficiently, the Canonical team provides such services. IYCC also provides backend technical service to OEMs, ODMs, and system builders. We are doing just that for Feral-Penguin of Australia. See http://www.feral-penguin.com.au.

Happy Trails,

Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://archive.iycc.net

[Mario Limonciello (superm1)]

This isn't intended for OEM system builders to be able to fall back on or
debug - it's intended for end users who get stuck with a bad situation.

I've got two example cases, 1 of which happened to Dell already.

1) You create your OEM install image, and it's deployed across a wealth of
platforms and validated. Later down the road a new variable gets introduced
to the hardware - lets say a monitor with a bad EDID. You verify that it
works for the prototype stock of this monitor, but some of these monitors
with the bad EDID get shipped to customers. What's better for the customer?
Something that falls back to VESA and lets them recover and follow
directions given to them from support where to grab an updated driver, or a
root shell?

2) A desktop is shipped to a customer with an NVIDIA graphics card. Because
it's being shipped with an NVIDIA graphics card, the OEM preinstalls the
NVIDIA driver for the customer. Later down the road, they want to switch it
to an AMD graphics card. They make the swap, and install the appropriate
driver. Their system is working fine. A hard drive goes bad, and after
replacing it they are required to use their recovery disks to restore to
factory state. Well since the recovery disks would reinstall the NVIDIA
graphics driver, they wouldn't be able to boot into X to fix their driver
problem, but would be instead stuck at a root shell.

On Fri, Jan 9, 2009 at 17:40, Loye Young <email address hidden> wrote:

> This is a very bad idea, and should NOT be implemented.
>
> OEM config SHOULD degrade to a command line if it does not complete
> correctly. In fact, the "bulletproofX" would make make it harder to
> debug and correct problems. If the system doesn't complete configuration
> of the system, the right way to debug and fix problems is from the
> command line, because the X display itself will obfuscate issues and
> interfere with the results of various debugging procedures. Worse, the
> changes made to the system by bulletproofX would introduce new problems
> to the final configuration, creating defects that may not be apparent
> until the customer begins using the system.
>
> "you get thrown into a root shell with no idea what's going on."
> Respectfully, if you don't know what's going on from the command line, you
> should be using the regular desktop installation CD instead. OEM config
> should NOT be used by anyone who does not understand how to engineer the box
> and fix things from the command line.
>
> If you are an OEM or system builder but don't have sufficient resources
> to engineer your product so that you can efficiently, the Canonical team
> provides such services. IYCC also provides backend technical service to
> OEMs, ODMs, and system builders. We are doing just that for Feral-
> Penguin of Australia. See http://www.feral-penguin.com.au.
>
> Happy Trails,
>
> Loye Young
> Isaac & Young Computer Company
> Laredo, Texas
> http://archive.iycc.net
>
> --
> OEM config should have bulletproof X support
> https://bugs.launchpad.net/bugs/315647
> You received this bug notification because you are a member of Ubuntu
> Installer Team, which is subscribed to oem-config in ubuntu.
>

--
Mario Limonciell...

[Loye Young (loyeyoung)]

Example #2 is perhaps a bad example because recovery disks should NOT use oem-config, for this and many other reasons.

However, I am sensitive to your example #1, and in particular to EDID problems. (Why is EDID so hard for monitor manufacturers to get right? The spec has been around plenty of time. But I digress.)

I remain strongly convinced that starting the Xserver is a bad idea in that situation and would make debugging worse. If oem-config is bailing from the install, either it should do a better job of recovering or the install should NOT go farther.

However, a middle ground is available.

The messages given by the current oem-config in that situation are cryptic, not helpful, and terse. The messages should be more intelligent about reporting what went wrong, how to call for help, and (if available) instructions for recovering (e.g., it might be possible to run a command that would tidy up the installation or even fix the problem).

While you're at it, have oem-config set up a "manufacturer data" file that the OEM could populate and that error messages could grep for support phone number, email address, etc.

Happy Trails,

Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://archive.iycc.net

[Mario Limonciello (superm1)]

What do you define recovery disks as doing? Every recovery disk i've seen
brings a system back to it's "factory shipped state". What's the first
thing you do when you boot your computer from the factory? You run
oem-config...

Example number 1 is something that has actually happened, and it's a
difficult problem to work with when a user is dropped to a console.

On Fri, Jan 9, 2009 at 19:47, Loye Young <email address hidden> wrote:

> Example #2 is perhaps a bad example because recovery disks should NOT
> use oem-config, for this and many other reasons.
>
> However, I am sensitive to your example #1, and in particular to EDID
> problems. (Why is EDID so hard for monitor manufacturers to get right?
> The spec has been around plenty of time. But I digress.)
>
> I remain strongly convinced that starting the Xserver is a bad idea in
> that situation and would make debugging worse. If oem-config is bailing
> from the install, either it should do a better job of recovering or the
> install should NOT go farther.
>
> However, a middle ground is available.
>
> The messages given by the current oem-config in that situation are
> cryptic, not helpful, and terse. The messages should be more intelligent
> about reporting what went wrong, how to call for help, and (if
> available) instructions for recovering (e.g., it might be possible to
> run a command that would tidy up the installation or even fix the
> problem).
>
> While you're at it, have oem-config set up a "manufacturer data" file
> that the OEM could populate and that error messages could grep for
> support phone number, email address, etc.
>
> Happy Trails,
>
> Loye Young
> Isaac & Young Computer Company
> Laredo, Texas
> http://archive.iycc.net
>
> --
> OEM config should have bulletproof X support
> https://bugs.launchpad.net/bugs/315647
> You received this bug notification because you are a member of Ubuntu
> Installer Team, which is subscribed to oem-config in ubuntu.
>

--
Mario Limonciello
<email address hidden>

[Loye Young (loyeyoung)]

On Fri, Jan 9, 2009 at 8:22 PM, Mario Limonciello <email address hidden>wrote:
>What's the first
>thing you do when you boot your computer from the factory? You run
>oem-config...

I don't know about other companies' practices, but no customer of IYCC has
to run oem-config. We have already run oem-config-prepare before we ship the
machine. Normal customers should simply turn on the computer, wait for the
Xserver/GTK dialog to start, fill out the form, and then log in. Even on
reinstallation, the customer should NOT be running oem-config unless the
customer wants to join the ranks of the Linux Army.

Oem-config is a tool for the OEM. Before the machine ever leaves the
factory, oem-config-prepare should have already been run so that the machine
is in a working state, ready for the customer to get to work. When the
customer turns on the machine the first time, the system runs through its
start-up scripts, one of the last of which is starting the Xserver. Because
it is the first time the customer has turned on the machine, instead of
running the gdm-chooser immediately, a GTK application runs that asks for a
few pieces of information, the user is created behind the scenes, and
finally the gdm-chooser (or other login screen) loads.

If the machine is unable to complete the boot process enough to load the
Xserver, the customer has a defectively or incompletely configured computer
and should either call the OEM for support or return the system for a
cheerful refund or exchange. The GTK application won't run without an
Xserver running. The application assumes (rightly) that the system is
configured well enough from the factory that the process is capable of
completing all the steps necessary, all the way through to Xserver startup.
(Although it is technically possible to run natively in graphics mode from
the time the kernel is loaded, for reasons of reliability and maximum
compatibility, that's not the current state of the art.)

Recovery discs should not require a customer to go through oem-config, even
on reinstalltion. The Right Way to support the customer is to send a
factory-customized disc that contains a more traditional desktop
installation script and some additional recovery tools. The factory already
knows how the system is to be configured, so it should have already set up
the preseed file with all the configuration options already set and included
all the necessary packages. The customer should not have to think, and the
install should "just work."

Pre-configuring the system is what customers pay OEMs to do. The oem-config
script is an aid to OEMs when engineering a custom system. If the system
needs a re-installation, the customer should be guided through a very clean
desktop installation process that doesn't require anything more than filling
in customer-specific information.

Back to the original issue of this bug report, I share your frustration with
defectively designed or built monitors and other peripherals. I do believe
that oem-config-firstboot should fail more gracefully and provide more
helpful information. Having banged my head against a wall way too many
times, however, I am steadfast in my conviction that oem-config failing...

[Mario Limonciello (superm1)]

On Sun, Jan 11, 2009 at 02:38, Loye Young <email address hidden> wrote:

> On Fri, Jan 9, 2009 at 8:22 PM, Mario Limonciello <<email address hidden>
> >wrote:
> >What's the first
> >thing you do when you boot your computer from the factory? You run
> >oem-config...
>
> I don't know about other companies' practices, but no customer of IYCC has
> to run oem-config. We have already run oem-config-prepare before we ship
> the
> machine. Normal customers should simply turn on the computer, wait for the
> Xserver/GTK dialog to start, fill out the form, and then log in. Even on
> reinstallation, the customer should NOT be running oem-config unless the
> customer wants to join the ranks of the Linux Army.

Running oem-config and oem-config-prepare are two entirely different tools.
I never referred to oem-config-prepare. That's part of what's done in the
factory recovery image process. When a user first receives a machine, the
first thing that should be ran however, is the oem-config tool.

--
Mario Limonciello
<email address hidden>

[Loye Young (loyeyoung)]

No. That's not the how oem-config works. The end user SHOULD NOT run
anything.

Oem-config is a two-stage process. First, oem-config sets up an OEM user and
configuration desktop so that the engineer can configure the machine. When
the machine is configured and ready to ship, the engineer runs
oem-config-prepare, which gets the machine ready for the customer. (The
"Prepare for shipping to user" icon and related menu item simply invoke
oem-config-prepare and confirm that the machine is ready to ship.)

All the customer has to do is turn on the machine and everything is
automatic. The user simply waits for the machine to ask for the basic
configuration details. Behind the scenes, oem-config-first-boot deletes the
oem user, sets up the new user, and hands over the system to gdm (for a
gnome desktop) or kdm (for a KDE desktop).

This "bug" should be marked as "Invalid".

Happy Trails,

Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://www.iycc.net

[Mario Limonciello (superm1)]

There really is a comprehension problem here. Like I said, the
recovery media runs OEM config prepare in its post install scripts.
The machine reboots, and the first thing that happens is that OEM
config launches for the user, yes by the first boot init script.that's
what needs the fallback support.

On 01/29/2009, Loye Young <email address hidden> wrote:
> No. That's not the how oem-config works. The end user SHOULD NOT run
> anything.
>
> Oem-config is a two-stage process. First, oem-config sets up an OEM user and
> configuration desktop so that the engineer can configure the machine. When
> the machine is configured and ready to ship, the engineer runs
> oem-config-prepare, which gets the machine ready for the customer. (The
> "Prepare for shipping to user" icon and related menu item simply invoke
> oem-config-prepare and confirm that the machine is ready to ship.)
>
> All the customer has to do is turn on the machine and everything is
> automatic. The user simply waits for the machine to ask for the basic
> configuration details. Behind the scenes, oem-config-first-boot deletes the
> oem user, sets up the new user, and hands over the system to gdm (for a
> gnome desktop) or kdm (for a KDE desktop).
>
> This "bug" should be marked as "Invalid".
>
> Happy Trails,
>
> Loye Young
> Isaac & Young Computer Company
> Laredo, Texas
> http://www.iycc.net
>
> --
> [Featire Request] OEM config should have bulletproof X support
> https://bugs.launchpad.net/bugs/315647
> You received this bug notification because you are a member of Ubuntu
> Installer Team, which is subscribed to oem-config in ubuntu.
>

--
Sent from my mobile device

Mario Limonciello
<email address hidden>

[Colin Watson (cjwatson)]

On Thu, Jan 29, 2009 at 11:36:56PM -0000, Loye Young wrote:
> No. That's not the how oem-config works. The end user SHOULD NOT run
> anything.

Loye, read Mario as saying "when oem-config is run on behalf of the
end user". Regardless of whether the end user types oem-config into a
shell or not (presumably not, as you say), oem-config gets run.

> All the customer has to do is turn on the machine and everything is
> automatic. The user simply waits for the machine to ask for the basic
> configuration details.

The program that actually asks the questions is called "oem-config", you
know ...

> This "bug" should be marked as "Invalid".

No, it really shouldn't. Mario knows what he's talking about.

[Loye Young (loyeyoung)]

>Mario knows what he's talking about.

Let's just say that Mario and I have a fundamental difference on how
oem-config should work and what its scope should be. We at IYCC work with it
every day, and we do not tolerate shipping a machine in the state Mario
describes.

This report should be marked invalid (or perhaps "will not fix") because
it's a bad idea. As I said earlier in this thread, while I agree that
oem-config should degrade more gracefully by providing more helpful error
messages, the so-called "bulletproof X" would make matters WORSE.

Happy Trails,

Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://www.iycc.net

[Loye Young (loyeyoung)]

>There really is a comprehension problem here.
I understand you perfectly. Perhaps it is you are aren't comprehending what
I am saying.

>Like I said, the recovery media runs OEM config prepare in its post install
scripts.
I am aghast at how you suggest customers should be supported. Oem-config (or
any portion) should NOT be on a customer's recovery media at all. A recovery
media should be simply a desktop installation disk preconfigured to factory
defaults.

>yes by the first boot init script.that's
>what needs the fallback support.
That's the part that should NOT have "fallback" support. Instead, the
factory should fix whatever causes the X server not to load. "Fallback"
support in that situation just leaves the customer thinking that the OS
sucks generally, instead of the more accurate perception that something is
wrong with the particular machine configuration.

Happy Trails,

Loye Young

[Colin Watson (cjwatson)]

It is my discretion, as the Ubuntu developer paying most attention to this package, whether to mark this bug invalid or won't fix; I do not intend to do so, and will reopen it if somebody else does. In general it is rather discourteous to continue to insist that something is not a bug when the author of the package has already acknowledged it as a bug!

For system builders that ship computers and monitors as a single unit (which as far as I can tell is the case for IYCC, from what http://www.iycc.biz/ says), it makes sense to configure it properly in the factory. However, other system builders have no idea what monitor their system will be connected to and thus there is a reasonable possibility of failure (since the monitor resolution is taken into account when the X server configures itself), even if the computer itself is correctly configured. You may not have run into this yourself, but it does happen, and the system builder can't always reasonably do anything about it; it's an Ubuntu problem and bullet-proof X is our last line of defence against it before dumping the user at a text console. In Ubuntu, we need to take both possibilities into account rather than only considering IYCC's case.

I would be happy for this to be an option that IYCC could turn off (or that Mario could turn on, whichever); there is no need to be concerned that your customers will need to be affected by this, and no need to harangue other experienced system builders who genuinely have different requirements from you.

Let me be clear that I do view it as generally undesirable for a user to actually end up needing bullet-proof-X, but only because I think that it means that Ubuntu's X autoconfiguration itself should be improved. I do not think that it means that the system builder necessarily did something wrong. I have a small amount of sympathy for the "user must suffer as much as possible for our bugs, otherwise they won't bother reporting them to us" viewpoint, but there are more graceful ways to get good bug reports that don't involve impeding users' ability to get on with their lives.

[Mario Limonciello (superm1)]

I was thinking about this again recently and had another idea for it. Perhaps instead of putting the bulletproof X support in oem-config, perhaps it would be better to have oem-config's GTK or KDE frontends fall back to the debconf frontend if they failed. This would let the user finish setting up the system, and then upon starting GDM bootstrap into the standard bulletproof-x setup.

[Loye Young (loyeyoung)]

>Perhaps instead of putting the bulletproof X support in oem-config,
>perhaps it would be better to have oem-config's GTK or KDE frontends
>fall back to the debconf frontend if they failed.

The devil is in the details, of course, but this might be a workable
compromise.

Thanks Mario.

Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://www.iycc.net

[Tony Espy (awe)]

Changed Status to WontFix in the Dell task, as this project is used to track non-public hardware enablement work.

[Timothy R. Chavez (timrchavez)]

The bug task for the somerville project has been removed by an automated script. This bug has been cloned on that project and is available here: https://bugs.launchpad.net/bugs/1305459

[Marcus Tomlinson (marcustomlinson)]

This release of Ubuntu is no longer receiving maintenance updates. If this is still an issue on a maintained version of Ubuntu please let us know.

[Launchpad Janitor (janitor)]

[Expired for ubiquity (Ubuntu) because there has been no activity for 60 days.]