During OEM-config removal, there is no graphical feedback

Set to "Wishlist" as this seems more like a feature request than a bug.

I've taken a video to show how the experience looks on a slow box.

http://www.youtube.com/watch?v=ByWfLWbgbj0

The first 7:49 or so are all OEM config time where it's spinning and doing stuff. At 7:49, X closes, a black screen comes up, there's a whole bunch of errors (probably plymouth?), and then a generating locales and then it just sits there. Looks like it's doing nothing. It spends about 1 minute at this screen.

It would be far better to either:
1) Throw up plymouth during this time
2) Pop up a dialog in X indicating it's cleaning up and do it in the background while X is active (but oem-config itself is finished)

Business Justification:
             This issue effects the first boot user experience and potentially could cause a user to mess up the configuration of the machine by killing it. As from the video above the user is left with a black screen with a ton of errors for just over a minute. If the user kills the machine during that time they will mess up the removal process.

             Dell expects if this issue cannot be addressed. That errors on the screen, such, as "broken pipe" can be resolved.

             This also effect the omsk project.

At this point in the cycle, the only solution I see to this problem is to remove the feature, then there's no reason to worry about the 1st boot user experience being diminished or users messing up the removal process. However, this is clearly not an option. Adding a graphical feedback breaks several release freezes, and is something we simply cannot afford to do at this stage of the release. We can, however, consider fixing this in 10.04.1, or at the very least, get it into 10.10.

This behaviour is indeed very ugly. If it doesn't get fixed in Lucid we'll need to fix it for omsk if we continue down the oem-config path.

This is appalling user experience. The system looks like it's crashed,
the user would be perfectly justified to reboot the machine during the
process.

Can I ask:

 - is this an unexpected result that happens rarely (a bug) or does this
happen every time?
 - was it known that this would happen when we developed the feature
 - does the developer think this is OK to ship?
 - what the estimation is to do this properly (cleanly)

Mark

> is this an unexpected result that happens rarely (a bug) or does this
happen every time?

Happens every time

> was it known that this would happen when we developed the feature
Yes. However, the feature was delivered on January 13th:
  revno: 3654
  fixes bug(s): https://launchpad.net/bugs/210779
  committer: Evan Dandrea <email address hidden>
  branch nick: ubiquity
  timestamp: Wed 2010-01-13 17:28:10 +0000
  message:
   Remove oem-config on successful completion (LP: #210779)

We received no feedback until the bug submitter raised the issue on irc with ev and cjwatson on April 1st, after Beta 2 Freeze (see attachment), and the bug itself was only just opened last week.

> does the developer think this is OK to ship?
Given ev had no feedback on it, I would assume he did, until being notified on April 1st, and (imo) it would have been hard to consider it very critical, as there was no bug filed. To be clear, I agree this is ugly, but fixing it now is a real risk to the stability of oem-config in general.

 - what the estimation is to do this properly (cleanly)
ev will answer this.

@Robbie:

On Tue, Apr 13, 2010 at 12:28, Robbie Williamson <email address hidden> wrote:

>
> We received no feedback until the bug submitter raised the issue on irc
> with ev and cjwatson on April 1st, after Beta 2 Freeze (see attachment),
> and the bug itself was only just opened last week.
>
>
Due to lots of other extenuating circumstances that blocked installation
from other bugs that are now fixed, the installation couldn't get that far
in the Dell factory environment until very recently.

--
Mario Limonciello
<email address hidden>

We are discussing a text progress bar solution, if this works, would that be acceptable? There would be a bit of flicker as we have to drop into an ncurses environment, but the messages would be hidden.

An alternative is that it may be possible to have a simple X progress
bar using debconf-apt-progress and debconf's GNOME frontend. Neither
would be particularly pretty, but they would be better than a black
screen with various errors on it.

For what it's worth, while I'd like to improve the user experience here,
at this point I'm only considering options for which the code
substantially already exists and which are already known to be robust
and functional, requiring only to be glued into oem-config. Anything
else is more risky than just pulling the feature. Although
debconf-apt-progress, whether with an ncurses-style frontend or an
X-based frontend, is not going to be seamlessly integrated into the user
experience provided by the rest of oem-config, it has the virtue of
being a known-good component usable for this kind of thing and I don't
think anything else is likely to be done in time with an acceptable risk
of regressions.

If both of these approaches are unacceptable, then I think we have no
alternative but to default oem-config/remove to false and thus return to
the previous situation where oem-config was left on the user's system
after configuration (bug 210779). I have a slight reliability concern
here, because I'd really rather get rid of oem-config's Upstart job
entirely rather than risk it being accidentally run again later when it
shouldn't be, and so I think this option carries its own problems.
Still, it's possible.

(As Robbie's IRC log notes in passing, the problem with trying to
integrate smoothly into oem-config's UI is that we're in the process of
ripping out all of oem-config's files from under it. Thus, IMO any
option that involves removing oem-config before most of oem-config has
exited carries a risk, which is why I'm not really comfortable with
doing it in the normal package removal hooks at this point. I would be
happy for us to experiment with that for Maverick.)

One other option is to simply display nothing at all, but in X. This still leaves the user wondering what's happening, but because it's still in X it doesn't look quite so much as though the computer has crashed.

(I don't think this is the best available option, but I mention it anyway in the spirit of completeness.)

I've committed a change to add a very simple progress feedback window around this, displayed before X is shut down. As promised, it is not integrated into the rest of oem-config nor even in the same style, and I don't expect to have time to do anything about this for 10.04 LTS. I think that it's a fair bit better than just displaying text on a black screen anyway, but if it is nonetheless unacceptable, then I suggest that the best (and probably the only reasonable and feasible) fallback solution for 10.04 would be to display just the X root window while this is going on.

I hope my change will be good enough for the moment, though.

On 13/04/10 19:37, Colin Watson wrote:
> For what it's worth, while I'd like to improve the user experience here,
> at this point I'm only considering options for which the code
> substantially already exists and which are already known to be robust
> and functional, requiring only to be glued into oem-config. Anything
> else is more risky than just pulling the feature.
>
+1

Mario, this is unfortunate, but if there's no sane, clean way to do it,
we'll need to drop the feature. If there's a sane, clean way to do it,
Colin & Evan will find it. I certainly think it should have been
possible to spot this, even outside the factory environment, if it's a
result of running it every time.

Mark

On Wed, Apr 14, 2010 at 03:41:14PM +0100, Mark Shuttleworth wrote:
> Mario, this is unfortunate, but if there's no sane, clean way to do it,
> we'll need to drop the feature. If there's a sane, clean way to do it,
> Colin & Evan will find it. I certainly think it should have been
> possible to spot this, even outside the factory environment, if it's a
> result of running it every time.

Please note my update to this bug in comment 13; I'm interested in
whether the option I've gone for is deemed acceptable, and have offered
a fallback position there that may be better both than the current
situation and than dropping the feature entirely (which has its own
problems, since in some ways this was a bug fix not a feature).

On 14/04/10 16:38, Colin Watson wrote:
> On Wed, Apr 14, 2010 at 03:41:14PM +0100, Mark Shuttleworth wrote:
>
>> Mario, this is unfortunate, but if there's no sane, clean way to do it,
>> we'll need to drop the feature. If there's a sane, clean way to do it,
>> Colin & Evan will find it. I certainly think it should have been
>> possible to spot this, even outside the factory environment, if it's a
>> result of running it every time.
>>
> Please note my update to this bug in comment 13; I'm interested in
> whether the option I've gone for is deemed acceptable, and have offered
> a fallback position there that may be better both than the current
> situation and than dropping the feature entirely (which has its own
> problems, since in some ways this was a bug fix not a feature).
>

I can't see it in action but it sounded fine - Mario?

@Colin @Mark

          We are going to roll a package with the commit later today to take a look at how it looks.

This bug was fixed in the package ubiquity - 2.2.17

---------------
ubiquity (2.2.17) lucid; urgency=low

  [ Mario Limonciello ]
  * Remove unused install_bottom_eb from GTK frontend's install_window.

  [ Evan Dandrea ]
  * Catch invalid iterators in on_region_combo_changed (LP: #521851).
  * Don't let not being able to talk to the system bus crash the entire
    language page.
  * Translate the yes and no buttons on the quit dialog in the KDE
    frontend (LP: #561876).
  * Update translations from Launchpad.
  * Automatic update of included source packages: base-installer
    1.103ubuntu7, choose-mirror 2.29ubuntu3, partman-base 139ubuntu4,
    partman-basicfilesystems 63ubuntu4, tzsetup 1:0.26ubuntu8.

  [ Colin Watson ]
  * Skip copy_wallpaper_cache when running as oem-config.
  * Update finish-install.d/07oem-config-user for new location of KDE's
    oem-config-prepare .desktop file (LP: #557309).
  * Restore translations for oem-config-check and oem-config-udeb, lost in
    oem-config merge.
  * Display simple progress feedback using debconf-apt-progress while
    removing oem-config (LP: #558593).
  * Write locale-gen output from ubiquity-dm to /var/log/installer/dm rather
    than to the console.
  * Increase kernel flush times (dirty_writeback_centisecs to 3000, and
    dirty_expire_centisecs to 6000) during bulk data copying. Surbhi
    Palande suggests that this should make it easier for the kernel to pack
    blocks contiguously, speeding up ureadahead after installation.

  [ Amichai Rothman ]
  * Fix hang unless mouse is moved (LP: #556376)
 -- Evan Dandrea <email address hidden> Wed, 14 Apr 2010 17:38:36 +0100

@Colin
       Don't think we did anything wrong. But the change you made is ok on how it removes oem-config. Besides the "debconf" text on the top bar ..it looks good.

       The problem is after it is done .. . you drop to a root prompt.

       Here are videos:
http://www.youtube.com/watch?v=Z_ony4TTb_s
http://www.youtube.com/watch?v=W7IjV0yhK_E

The "debconf" text is one of those style problems I mentioned that I can't do much about for 10.04. We should be able to address this for 10.10 (which should maybe be a separate bug, or just a TODO comment, I don't mind).

Looks like a simple glitch in my move of code from oem-config-firstboot to oem-config-wrapper/oem-config-remove. I'm not sure why it didn't show up in my testing, but that's why we're doing this a couple of weeks before release! Fix on its way once I've done another straight-through test.

@Collin
           Thanks. Just tried with todays build and hit the issue. Still dropping to root prompt. Here is a picture of the error attached.

So it appears something *else* is wrong here, judging by all the errors....perhaps this is why Colin is not seeing it.

We haven't uploaded the fix yet, which is why you don't see it. Note
that the bug status is "Fix Committed", not "Fix Released".

This bug was fixed in the package ubiquity - 2.2.18

---------------
ubiquity (2.2.18) lucid; urgency=low

  [ Evan Dandrea ]
  * Force garbage collection so we don't end up with stray X resources
    when we kill the X server (LP: #556555).
  * Fix the Portuguese and Latvian translations of the variable name
    RELEASE (LP: #564517).
  * Fix a missing closing bold tag in the Portuguese and Polish
    translations (LP: #564545).
  * Fix labels not expanding vertically to fit their text (LP: #560114,
    LP: #557164, LP: #520898).
  * Do not translate variable names in the Amharic translation
    (LP: #564582).
  * Start the window manager via ck-launch-session so pulseaudio is
    granted access to the sound devices (LP: #549738).
  * Update translations from Launchpad.
  * Automatic update of included source packages: console-setup
    1.34ubuntu14, flash-kernel 2.13ubuntu16, hw-detect 1.73ubuntu3,
    partman-auto 89ubuntu6, partman-base 139ubuntu5, partman-ext3
    58ubuntu3, partman-target 64ubuntu8, user-setup 1.28ubuntu6.

  [ Colin Watson ]
  * Break out of oem-config-firstboot's main loop if oem-config-wrapper
    succeeds (LP: #558593).
  * Quit plymouth before starting either the emergency noninteractive
    ubiquity frontend in automatic mode, or oem-config's debconf frontend.
  * Get a controlling terminal before starting bterm, as otherwise bterm
    won't reliably be able to take console input.
 -- Evan Dandrea <email address hidden> Fri, 16 Apr 2010 15:28:19 +0100

Confirmed Fixed. Latest ubiquity fixed issue where oem-config was dropping to root prompt.