[telemetry] Record OEM installation mode

Bug #1765693 reported by Jean-Baptiste Lallement on 2018-04-20
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)
Medium
Didier Roche
Bionic
Medium
Didier Roche

Bug Description

[Impact]

 * On release week, we had to remove the "OEM" telemetry data report as it was making ubiquity crash. After investigation, we saw that we were looking for debconf key oem-config/enable=true, which was indeed valid for OEM installation.
 * However, non OEM installation is removing oem-config, which leads to debconf not knowing about this key and crashing.
 * We reintroduce here this functionality cut on the release day, as OEM is an useful metrics on the telemetry data. For instance, multiple machines will have the same installation information and we need to triage them.

[Test Case]

Do it for OEM and non OEM mode, on ubuntu and kubuntu:
 * Start an 18.04 live session and install ubiquity
 * Start ubiquity
 * Complete the installation and close ubiquity without rebooting the session
 * Check that the boolean associated with the "OEM" key reports correctly if you were doing an OEM or a non OEM installation

[Regression Potential]

 * We are now using a value from the base installer class, common to all UIs. The installer will crash if the usage is invalid, but in a reproducible way.

----

Telemetry data should collect OEM installation mode. It is defined by the debconf key oem-config/enable=true

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: ubiquity (not installed)
ProcVersionSignature: Ubuntu 4.15.0-15.16-generic 4.15.15
Uname: Linux 4.15.0-15-generic x86_64
ApportVersion: 2.20.9-0ubuntu5
Architecture: amd64
Date: Fri Apr 20 14:06:05 2018
InstallCmdLine: file=/cdrom/preseed/ubuntu.seed boot=casper initrd=/casper/initrd.lz quiet splash -- keyboard-configuration/layoutcode=fr keyboard-configuration/variantcode=oss
InstallationDate: Installed on 2014-07-15 (1375 days ago)
InstallationMedia: Ubuntu 14.10 "Utopic Unicorn" - Alpha amd64 (20140520)
SourcePackage: ubiquity
UpgradeStatus: Upgraded to bionic on 2018-03-24 (26 days ago)

Related branches

Jean-Baptiste Lallement (jibel) wrote :
Didier Roche (didrocks) on 2018-05-29
description: updated
Didier Roche (didrocks) on 2018-05-29
Changed in ubiquity (Ubuntu Bionic):
status: New → Triaged
Changed in ubiquity (Ubuntu):
status: New → Triaged
importance: Undecided → Medium
assignee: nobody → Didier Roche (didrocks)
Changed in ubiquity (Ubuntu Bionic):
assignee: nobody → Didier Roche (didrocks)
importance: Undecided → Medium
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ubiquity - 18.10.3

---------------
ubiquity (18.10.3) cosmic; urgency=medium

  * Don't record telemetry data when doing stage 2 (user mode) as it keeps an
    unused /target directory (LP: #1773321) Also, record OEM types
    (LP: #1765693)
  * Switch to use uptime instead of time.time() which is sensitive to
    BIOS time reset after NTP sync, leading to negative values.
    (LP: #1771966)
  * Ignore .git file from built package and remove .bzr artefacts
  * update manifest

 -- Didier Roche <email address hidden> Mon, 28 May 2018 16:02:33 +0200

Changed in ubiquity (Ubuntu):
status: Triaged → Fix Released

Hello Jean-Baptiste, or anyone else affected,

Accepted ubiquity into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/ubiquity/18.04.14.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in ubiquity (Ubuntu Bionic):
status: Triaged → Fix Committed
tags: added: verification-needed verification-needed-bionic
Jean-Baptiste Lallement (jibel) wrote :

SRU verification for Bionic:
I have reproduced the problem with ubiquity 18.04.14.1 in bionic-updates and have verified that the version of ubiquity 18.04.14.2 in -proposed fixes the issue.

Marking as verification-done

tags: added: verification-done verification-done-bionic
removed: verification-needed verification-needed-bionic
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ubiquity - 18.04.14.2

---------------
ubiquity (18.04.14.2) bionic; urgency=medium

  * Switch to use uptime instead of time.time() which is sensitive to
    BIOS time reset after NTP sync, leading to negative values.
    (LP: #1771966)
  * Don't record telemetry data when doing stage 2 (user mode) as it keeps an
    unused /target directory (LP: #1773321) Also, record OEM types
    (LP: #1765693)
  * Ignore .git file from built package and remove .bzr artefacts

 -- Didier Roche <email address hidden> Mon, 28 May 2018 16:08:48 +0200

Changed in ubiquity (Ubuntu Bionic):
status: Fix Committed → Fix Released

The verification of the Stable Release Update for ubiquity has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers