Ubuntu
ubiquity package

OEM installs telemetry file to target folder

Bug #1773321 reported by Adam Smith
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)
Fix Released
High
Didier Roche-Tolomelli
Bionic
Fix Released
High
Didier Roche-Tolomelli
Ubuntu ubuntu-18.04.1

Bug Description

[Impact]

 * Telemetry data were leaving a telemetry file while the second stage OEM installer (the user setup) was ran. This telemetry file was creating thus a /target directory on the root FHS.

[Test Case]

 * Start an 18.04 live session and install ubiquity in OEM mode
 * Start ubiquity
 * Complete the installation and close ubiquity without rebooting the
session

 * Reboot, check /var/log/installer/telemetry and mark the machine as ready
 * Reboot with the user creation and config step, and proceed through it with relogin with the new created user
 * Check that there is no /target directory and that /var/log/installer/telemetry is still the same.

[Regression Potential]

 * The impact is minimal, we check for and env variable before bailing out from recording the file. That will make room for the future to easily merge those second stage data with the installer (OEM) ones.

----

Experimenting with an oem install, after the user setup and the installation is complete there is a /target/var/log/installer/telemetry file. This file location seems to be hard coded into ubiquity, but there is no /target at the oem user setup stage.

This is using unofficial xubuntu-core installation media.

See original description

Related branches

~didrocks/ubiquity:bionic-fix-oem
Jean-Baptiste Lallement: Approve
Diff: 75 lines (+13/-0)
5 files modified
ubiquity/frontend/debconf_ui.py (+1/-0)
ubiquity/frontend/gtk_ui.py (+1/-0)
ubiquity/frontend/kde_ui.py (+1/-0)
ubiquity/frontend/noninteractive.py (+1/-0)
ubiquity/telemetry.py (+9/-0)
~didrocks/ubiquity:master-fix-oem
Jean-Baptiste Lallement: Approve
Diff: 75 lines (+13/-0)
5 files modified
ubiquity/frontend/debconf_ui.py (+1/-0)
ubiquity/frontend/gtk_ui.py (+1/-0)
ubiquity/frontend/kde_ui.py (+1/-0)
ubiquity/frontend/noninteractive.py (+1/-0)
ubiquity/telemetry.py (+9/-0)
Revision history for this message
Jean-Baptiste Lallement (jibel) wrote :

Thanks for your report.

Confirmed with Ubuntu Cosmic desktop 20180528

Changed in ubiquity (Ubuntu):
status: New → Triaged
importance: Undecided → High
assignee: nobody → Didier Roche (didrocks)
Changed in ubiquity (Ubuntu Bionic):
status: New → Triaged
milestone: none → ubuntu-18.04.1
Revision history for this message
Didier Roche-Tolomelli (didrocks) wrote :

I tried both on Bionic and Cosmic desktop 20180528 and I can't reproduce the option, choosing the "OEM" option at startup. Note that this is what I tested before mergintg the changes.
Both have /target/var/log/…
This is indeed hardcoded alongside other paths in ubiquity which have /target hardcoded.

Anything I'm missing? Do you proceed differently to get to that broken status?

Changed in ubiquity (Ubuntu):
status: Triaged → Incomplete
Changed in ubiquity (Ubuntu Bionic):
status: Triaged → Incomplete
Revision history for this message
Adam Smith (adamsmith) wrote :

There are two stages to an OEM install; preparing the image for shipping and the user first boot.

Preparing for shipping is fine, but when ubiquity runs on the user first boot there is no /target as far as I'm aware. This is when ubiquity creates a /target folder with the telemetry file in it.

Changed in ubiquity (Ubuntu):
status: Incomplete → Confirmed
Changed in ubiquity (Ubuntu Bionic):
status: Incomplete → Confirmed
Revision history for this message
Adam Smith (adamsmith) wrote :

I see now my initial description was probably not the clearest since there is an OEM user account. What I was referring to was the end user setup.

Revision history for this message
Jean-Baptiste Lallement (jibel) wrote :

@didrocks, put differently after the end user setup there are 2 telemetry files: /target/var/log/installer/telemetry and /var/log/installer/telemetry

The former must not be created.

Revision history for this message
Didier Roche-Tolomelli (didrocks) wrote :

Thanks to both of you! That's clear, and I never checked/noticed the second one. I'll have a look at how to differentiate it (probably tomorrow). Thanks!

Didier Roche-Tolomelli (didrocks)
description: updated
Changed in ubiquity (Ubuntu Bionic):
assignee: nobody → Didier Roche (didrocks)
importance: Undecided → High
Revision history for this message
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: Confirmed → Fix Released
Revision history for this message
Brian Murray (brian-murray) wrote : Please test proposed package

Hello Adam, 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: Confirmed → Fix Committed
tags: added: verification-needed verification-needed-bionic
Revision history for this message
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
Revision history for this message
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
Revision history for this message
Łukasz Zemczak (sil2100) wrote : Update 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  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

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