ubi-prepare failed with exit code 255

Bug #1567445 reported by Cameron Hart on 2016-04-07
This bug affects 4 people
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)
Mathieu Trudel-Lapierre

Bug Description

I've tried installing 16.04 with the Beta 2 and an earlier version and ran into this problem both times. I tried installing with the options download updates, install third party drivers and disabling secure boot.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: ubiquity 2.21.51
ProcVersionSignature: Ubuntu 4.4.0-15.31-generic 4.4.6
Uname: Linux 4.4.0-15-generic x86_64
ApportVersion: 2.20-0ubuntu3
Architecture: amd64
CasperVersion: 1.368
CurrentDesktop: Unity
Date: Thu Apr 7 13:03:32 2016
InstallCmdLine: BOOT_IMAGE=/casper/vmlinuz.efi file=/cdrom/preseed/ubuntu.seed boot=casper quiet splash ---
LiveMediaBuild: Ubuntu 16.04 LTS "Xenial Xerus" - Beta amd64 (20160323)
 PATH=(custom, no user)
SourcePackage: ubiquity
UpgradeStatus: No upgrade log present (probably fresh install)

Related branches

Cameron Hart (bitshifternz) wrote :
Cameron Hart (bitshifternz) wrote :

I tried running the installer again and determined that this only happens if I tick the "disable secure boot" option.

Launchpad Janitor (janitor) wrote :

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

Changed in ubiquity (Ubuntu):
status: New → Confirmed
Morten Frisch (fmfrisch) wrote :

I have the same issue, although checking or unchecking secure boot has no effect

Morten Frisch (fmfrisch) wrote :

However choosing to not enable third-party repos and not download along side installation seems to have solved the issue

Changed in ubiquity (Ubuntu):
importance: Undecided → Critical

I have this issue too with 16.04 beta 2

Initially I tried the 'disable SecureBoot' option, but after trying again with this option unchecked I still see the error.

I see this line in syslog:

ubuntu ubiquity: Failed to request new SB state

Incidentally the wording around this SecureBoot disabling stuff is very "now or never" -- makes it sound like you'll never be able to install the proprietary drivers unless you do this NOW, which is slightly scary. Is that actually the case or can you do this later if you want?

Cameron Hart (bitshifternz) wrote :

I'd also like to know how "now or never" this actually is. I've been trying to find documentation about this feature but haven't succeeded so far.

@matthew-wilson: once I had the error I'd always get it on retry no matter what options I chose. On reboot (or maybe just restarting ubiquity, can't remember) if I didn't choose disable secure boot then I didn't get an error.

Should have said, but this was on a Dell XPS 15 9550, with Windows 10 already pre-installed.

Workaround for me was to disable SecureBoot manually in the BIOS before booting the 16.04 installer.

Cameron Hart (bitshifternz) wrote :

@matthew-wilson - were you able to successfully install and dual boot win 10 doing that?

I am, yes. The only change I made was to disable secure boot, I didn't enable legacy ROMs and I left UEFI (?) turned on.

There's a couple of issues here, not just the one with mokutil -- looks like your system is also failing to download all the right packages for your third-party drivers.

I'll fix the failure because of mokutil now; this is simply because mokutil and the kernel tend to disagree about the result of asking for disabling validation, and mokutils happens to really do successfully set things up, regardless of the message shown.

To answer the earlier questions; you can certainly change the Secure Boot validation status later. This message is intended to convey the message that if you want to use third-party drivers, you really ought to disable Secure Boot validation as proposed; otherwise these *drivers* might not work when you reboot. This is important since drivers may keep you from getting online (for some wifi drivers), or from starting Unity (assuming for some reason fallback to the free drivers completely fails, except it usually doesn't). In other words, you might not get 3D graphics or wifi if you really depend on the third-party drivers for those to work.

To make changes later, you can run mokutil:

To re-enable Secure Boot validation:
sudo mokutil --enable-validation

To disable Secure Boot validation (which we do not recommend unless you need third-party drivers):
sudo mokutil --disable-validation

This is substancially different from disabling Secure Boot altogether. If you disable Secure Boot, you get no validation at all of the boot sequence. If you leave it on but disable validation in shim using mokutil, you will get validation up to Grub, and then the kernel and modules will not be validated for a good signature by Canonical.

This also means you need to disable validation if you want to use custom kernels.

For now, we're toggling validation in shim. In the future, we'll work on making it easy to sign your own built kernels and modules, so that disabling validation is not required (and then you can more easily make sure the full boot sequence has not been tampered with).

Changed in ubiquity (Ubuntu):
status: Confirmed → In Progress
assignee: nobody → Mathieu Trudel-Lapierre (cyphermox)
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ubiquity - 2.21.57

ubiquity (2.21.57) xenial; urgency=medium

  [ Mathieu Trudel-Lapierre ]
  * Automatic update of included source packages: localechooser
    2.65ubuntu4. (LP: #1551285)
  * scripts/simple-plugins: better handle passing the MokPW key to mokutil
    and the result from the command -- we explicitly can ignore errors here.
    (LP: #1567445)
  * plugin-viewer-gtk.py: fix plugin-viewer-gtk to allow showing most plugins
    correctly; useful for debugging.
  * ubiquity/plugins/ubi-prepare.py: rework password validation behavior for
    MokPW without changing user-visible strings: we only need to show feedback
    for a "good" password (of the allowable lengths), and correct the behavior
    for mismatched passwords. Also make it obvious if the chosen password is
    too short. (LP: #1560940)

  [ Shih-Yuan Lee (FourDollars) ]
  * Really make oem-config-prepare quiet when started by a non-priviledged

 -- Mathieu Trudel-Lapierre <email address hidden> Wed, 13 Apr 2016 14:36:37 -0400

Changed in ubiquity (Ubuntu):
status: In Progress → Fix Released
Cameron Hart (bitshifternz) wrote :

@cyphermox what's the best way of trying the fix? Can I just get updated packages with the beta2 or should I wait for this to get into a nightly build (and if so when do the nightlies get made)?


Cameron Hart (bitshifternz) wrote :

I tried the latest nightly with fix and didn't get this error. Thanks!

hasno (c1248408) wrote :

Currently installing 16.04 final and I still got "ubi-prepare failed with exit code 255", so I disabled secure boot. Will I have to reinstall once this gets fixed so I can use secure boot. Or is it really enough to run "sudo mokutil --disable-validation" and then enable secure boot in BIOS ?

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

Other bug subscribers