Installer stops after pressing Cancel on Select a language screen during OEM install

Bug #1749289 reported by David Coronel on 2018-02-13
18
This bug affects 2 people
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)
Status tracked in Cosmic
Xenial
Undecided
Unassigned
Bionic
Undecided
Unassigned
Cosmic
Undecided
Unassigned

Bug Description

[Impact]

Pressing Cancel during Ubuntu 16.04.3 Server installation after OEM install and after running oem-config-prepare aborts the installation.

The behaviour is different from a regular Ubuntu 16.04.3 Server installation (without OEM) where the option at the bottom is "Go Back" which will send you back to steps menu. In the OEM mode, the options are "Ok" and "Cancel" and pressing Cancel will break the installation.

This is an issue with oem-config basically, which comes from ubiquity

The upload[1] fixes the bug by implementing do_reboot method in the debconf_ui wizard to prevent AttributeError caused by calling missing method.

[1] https://code.launchpad.net/~dgadomski/ubiquity/+git/ubiquity/+ref/lp1749289-b

[[missing: justification for backporting the fix to the stable release]]

[Test Case]

1.Download Ubuntu Server 16.04.3 from https://www.ubuntu.com/download/server
2.Boot VM with ubuntu-16.04.3-server-amd64.iso
3.Highlight "Install Ubuntu Server" and press F4 and choose "OEM install (for manufacturers)" and press Enter on "Install Ubuntu Server"
4.Accept all defaults and choose a password
5.Reboot at the end of the installation
6.Enter login prompt (username:oem and password you set)
7.sudo oem-config-prepare
8.Reboot
9.In "Select a language" screen, press Cancel
10.Installation aborts and OEM-config.service fails to start and hangs forever. The exact error message is: "Failed to start End-user configuration after initial OEM installation"

[[missing: steps to verify that the updated package fixes the problem]]

[Regression Potential]

If any automation was depending on current behavior (error code returned from the script when unimplemented methods has been called) it may now misbehave.

[Other Info]

The error after pressing Cancel in the OEM mode:
https://launchpadlibrarian.net/356907996/oem-error.png

The different options between OEM and regular installation:
https://launchpadlibrarian.net/356908005/oem-vs-regular.png

Related branches

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1749289/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

tags: added: bot-comment
affects: ubuntu → oem-config (Ubuntu)
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in oem-config (Ubuntu):
status: New → Confirmed
Dariusz Gadomski (dgadomski) wrote :

Seems that oem-config-firstboot ignores the question that should be presented to the user on unfinished installation, because of the following line in /usr/bin/ubiquity:
125: fcntl.ioctl(0, termios.TIOCSCTTY, 1)
It steals the terminal from the calling script, so the question is not presented nor any response is read.

So the bottom line is:
1. handling 'wizard.do_reboot()' should not be called for debconf_ui frontend
2. the ioctl call above should not be made

Fixing these 2 things should ensure the flow is as designed in the code.

David Coronel (davecore) wrote :

I tested the test package for Xenial in ppa:dgadomski/ubiquity-lp1749289 and it gives me a choice instead of failing now. After pressing Cancel on the first screen, I get:

Your system is not yet configured. Press 'a' to try again, 's' for a recovery shell, or 'r' to reboot.
[asr]

I did an OEM install and run these commands right before the oem-config-prepare step:

sudo add-apt-repository ppa:dgadomski/ubiquity-lp1749289
sudo apt-get update
sudo apt install ubiquity
sudo oem-config-prepare

Looks good to me.

Dimitri John Ledkov (xnox) wrote :

Committed the fix in git branches, for xenial/bionic/cosmic.

affects: oem-config (Ubuntu) → ubiquity (Ubuntu)
Changed in ubiquity (Ubuntu Xenial):
status: New → Fix Committed
status: Fix Committed → Confirmed
Changed in ubiquity (Ubuntu Bionic):
status: New → In Progress
Changed in ubiquity (Ubuntu Cosmic):
status: Confirmed → Fix Committed
Dariusz Gadomski (dgadomski) wrote :

xnox: sadly there was a misunderstanding - I didn't take any actions about it since the merge request was marked "on hold", but I hit some issues with the installer after removing fcntl.ioctl(0, termios.TIOCSCTTY, 1)
The terminal debconf tools were failing without it.

I came up with 2 other ways of mitigating this issue:
https://code.launchpad.net/~dgadomski/ubiquity/+git/ubiquity/+ref/lp1749289-a - preventing cancelling the first page of the installer

https://code.launchpad.net/~dgadomski/ubiquity/+git/ubiquity/+ref/lp1749289-b - implement do_reboot method in the debconf_ui wizard to prevent AttributeError caused by calling missing method.

Please consider using any of those instead (both branches include reverting the previous change).

Adam Conrad (adconrad) wrote :

I've taken your -b fix into trunk.

Phillip Susi (psusi) wrote :

How is this an ubiquity issue? Shouldn't it be d-i or subiquity?

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ubiquity - 18.10.7

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

  [ Dariusz Gadomski ]
  * Implement missing reboot and shutdown methods in debconf_ui (LP: #1749289)

  [ Michael Hudson-Doyle ]
  * Add systemd-resolved to oem-config.target's Wants (LP: #1777900)
  * Automatic update of included source packages: console-setup
    1.178ubuntu8, partman-jfs 53, partman-lvm 124.

 -- Michael Hudson-Doyle <email address hidden> Fri, 17 Aug 2018 10:23:14 +1200

Changed in ubiquity (Ubuntu Cosmic):
status: Fix Committed → Fix Released
Łukasz Zemczak (sil2100) wrote :

This is an issue with oem-config basically, which comes from ubiquity.

This bug is missing some SRU information which is a bit unfortunate. But seeing that the test case is present and the fix itself seems to have a low regression potential, I will conditionally accept is as is. But please provide some regression potential analysis and fill in the missing information before performing fix validation. Thank you.

Changed in ubiquity (Ubuntu Bionic):
status: In Progress → Fix Committed
tags: added: verification-needed verification-needed-bionic

Hello David, 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.7 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!

An upload of ubiquity to bionic-proposed has been rejected from the upload queue for the following reason: "should be re-uploaded with console-setup 1.178ubuntu2.7".

Hi,

Can someone update this bug description to follow the SRU template please?

David Coronel (davecore) on 2018-08-28
description: updated
description: updated

Hello David, 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.8 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!

Dariusz Gadomski (dgadomski) wrote :

Hello Łukasz, I was not able to verify this on bionic. The boot stucks even before I had the chance to install the -proposed version of ubiquity.

Steps I took:
1. Use the alternative iso with legacy installer.
2. F4 -> set OEM mode
3. Go through the initial setup.
4. Reboot to perform the OEM configuration.
5. Boot process is stuck without any errors/messages.

Looks like the OEM installation with ubiquity is broken on Bionic. I will report a separate bug about that.

Dariusz Gadomski (dgadomski) wrote :

Reported bug #1789920.

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

Other bug subscribers