OEM installs telemetry file to target folder

[Adam Smith]

[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.

[Jean-Baptiste Lallement (jibel)]

Thanks for your report.

Confirmed with Ubuntu Cosmic desktop 20180528

[Didier Roche-Tolomelli (didrocks)]

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?

[Adam Smith (adamsmith)]

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.

[Adam Smith (adamsmith)]

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.

[Jean-Baptiste Lallement (jibel)]

@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.

[Didier Roche-Tolomelli (didrocks)]

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!

[Launchpad Janitor (janitor)]

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

[Brian Murray (brian-murray)]

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!

[Jean-Baptiste Lallement (jibel)]

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

[Launchpad Janitor (janitor)]

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

[Łukasz Zemczak (sil2100)]

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.