error: cannot find EFI directory.

Bug #1803031 reported by Vinicius Adriano Metz
92
This bug affects 12 people
Affects Status Importance Assigned to Milestone
grub-installer (Ubuntu)
Confirmed
Undecided
Unassigned
Disco
Won't Fix
Undecided
Unassigned
partman-efi (Ubuntu)
Fix Released
Undecided
Unassigned
Bionic
Fix Released
Undecided
Unassigned
Cosmic
Fix Released
Undecided
Unassigned
Disco
Fix Released
Undecided
Unassigned

Bug Description

[Impact]
Any user installing Ubuntu on UEFI systems and picking manual partitioning. This leads to an installation config that cannot be completed due to the missing partition not being detected until grub-installer runs at the end of the install process

[Test case]
The exact behavior will differ depending on the precise set of features enabled in the system's firmware:

== In each firmware mode (BIOS, UEFI, UEFI w/ CSM), using automatic partitioning (full disk) ==

1) Boot to an install media
2) At the partitioning screen, pick "Erase disk and install Ubuntu" or "Use entire disk - Guided partitioning".
3) Confirm all changes and begin the installation.

The user should see no user prompt, and system is bootable after installation.

== System in UEFI, with or without CSM enabled ==

1) Boot to an install media
2) At the partitioning screen, pick "Something else" or "Manual partitioning".
3) Create a single partition for /.
4) Confirm all changes and begin the installation.

The installer should immediately warn the user that there is no EFI System partition and offer to go back to the partitioning screen. Once the EFI System partition is present, the user is not shown the prompt and the installation completes successfully. The system is bootable.

Without the fix, the installation process happily continues and ends in a crash in grub-installer.

== System in BIOS mode, manual partitioning without ESP ==

1) Boot to an install media
2) At the partitioning screen, pick "Something else" or "Manual partitioning".
3) Create a single partition for /.
4) Confirm all changes and begin the installation.

Install should complete successfully, without prompting the user (an ESP is not strictly required for booting).

[Regression potential]
There may be unforseen cases in which users really do not want to create an ESP despite using an installation medium that was booted in UEFI mode. In these cases, users will now have an additional dialog warning them that the ESP does not exist, and have the option to hit "Continue" after reading the message.

As in some cases the partitioning logic is run twice (for instance, when in the ubiquity installer); there is some risk of additional warning when going forward and back in the installer steps and the partitioning screens. Any step in which the partitionning prompts unduly or refuses to install should be investigated, they may be regressions if the setup was previously allowed and lead to a succesfully completed installation.

---

Não instalou por erro no GRUB.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: ubiquity 18.04.14
ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17
Uname: Linux 4.15.0-20-generic x86_64
ApportVersion: 2.20.9-0ubuntu7
Architecture: amd64
CasperVersion: 1.394
CurrentDesktop: ubuntu:GNOME
Date: Tue Nov 13 00:11:42 2018
InstallCmdLine: BOOT_IMAGE=/casper/vmlinuz file=/cdrom/preseed/ubuntu.seed boot=casper only-ubiquity quiet splash ---
LiveMediaBuild: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
ProcEnviron:
 LANGUAGE=pt_BR.UTF-8
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=pt_BR.UTF-8
 LC_NUMERIC=C.UTF-8
SourcePackage: grub-installer
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Vinicius Adriano Metz (metzvinicius) wrote :
summary: - Instalação mal sucedida
+ erro: cannot find EFI directory.
Revision history for this message
Launchpad Janitor (janitor) wrote : Re: erro: cannot find EFI directory.

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

Changed in grub-installer (Ubuntu):
status: New → Confirmed
tags: added: rls-bb-incoming
Revision history for this message
Brian Murray (brian-murray) wrote :

Here is the error message from UbiquitySyslog.txt:

Nov 13 03:10:12 ubuntu ubiquity: Setting up shim (15+1533136590.3beb971-0ubuntu1) ...
Nov 13 03:10:13 ubuntu ubiquity: Setting up grub-efi-amd64-signed (1.93.8+2.02-2ubuntu8.7) ...
Nov 13 03:10:14 ubuntu ubiquity: Instalando para a plataforma x86_64-efi.
Nov 13 03:10:14 ubuntu ubiquity: grub-install: erro: cannot find EFI directory.
Nov 13 03:10:14 ubuntu ubiquity: dpkg: error processing package grub-efi-amd64-signed (--configure):
Nov 13 03:10:14 ubuntu ubiquity: installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 1
Nov 13 03:10:14 ubuntu ubiquity: dpkg: dependency problems prevent configuration of shim-signed:
Nov 13 03:10:14 ubuntu ubiquity: shim-signed depends on grub-efi-amd64-signed; however:
Nov 13 03:10:14 ubuntu ubiquity: Package grub-efi-amd64-signed is not configured yet.

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Indeed, but we should really be catching these errors earlier, when the installer is running and the user is partitioning.

Adding a task for partman-efi.

description: updated
Revision history for this message
Steve Langasek (vorlon) wrote :

I would like to see a more complete set of test cases here for SRU verification.

 - system booted in UEFI mode; manual partitioning w/o ESP; user correctly stopped and given the opportunity to fix; install successful after fixing.
 - system booted with UEFI but with CSM enabled; manual partitioning w/o ESP; should the user be stopped or not?
 - system booted in BIOS mode; manual partitioning w/o ESP; install completes successfully despite our having configured grub-installer to install both EFI and BIOS versions of grub by default. (If this is not the case, then I think a change is needed to grub-installer instead of to partman-efi, but we should identify this.)
 - system booted in UEFI mode; full disk automatically partitioned; no error prompts shown and system is bootable after install.
 - system booted with UEFI but with CSM enabled; idem.
 - system booted in BIOS mode; idem.

We need to make sure that each of these cases is validated for 18.04.2 - whether as part of this SRU or as part of ISO testing is not important, but I want to be sure these don't get missed.

Revision history for this message
Steve Langasek (vorlon) wrote : Please test proposed package

Hello Vinicius, or anyone else affected,

Accepted partman-efi into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/partman-efi/71ubuntu2.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 for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in partman-efi (Ubuntu Bionic):
status: New → Fix Committed
tags: added: verification-needed verification-needed-bionic
description: updated
description: updated
Revision history for this message
Adam Conrad (adconrad) wrote :

Hello Vinicius, 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.12 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 for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

summary: - erro: cannot find EFI directory.
+ error: cannot find EFI directory.
Revision history for this message
Sebastien Bacher (seb128) wrote :

Thanks for working on that one! Some questions

- what's the best way to test on an iso? Is booting a bionic daily and installing the new ubiquity deb enough?

- you wrote

'The installer should immediately warn the user that there is no EFI System partition and offer to go back to the partitioning screen. Once the EFI System partition is present'

It's not clear from the description how the EFI partition needs to be created. Is the user bounced back to the manually partitioning screen and then needs to figure out how to do that? or is it done for them?

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

yes, you install using a recent daily. That should be enough, but otherwise you can upgrade to the new ubiquity from -proposed.

The user needs to figure it out. We do have guided partitioning for that reason; and the warning clearly says it's "missing an EFI System Partition", which is one of the options given for the type of partition when using manual partitioning.

Considering the differences between ubiquity and d-i, this was currently the best that could be done at short notice.

Revision history for this message
Sebastien Bacher (seb128) wrote :

Thanks Mathieu, that's indeed an improvement ("go create an EFI" doesn't seem like something obvious/that non technical users would figure out but it's already better than saying nothing and failing install later on)

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Verification done with ubiquity 18.04.14.12 / partman-efi 71ubuntu2.2:

I've tried the various permutations of installing in BIOS mode, in UEFI mode, or with UEFI with CSM enabled. All work as appropriate: when installing in UEFI with or without CSM and no ESP is created, the user is prompted; in BIOS mode the user is never prompted.

All of the above work without prompting in automated partitioning, as expected.

tags: added: verification-done-bionic
removed: verification-needed verification-needed-bionic
tags: removed: rls-bb-incoming
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package partman-efi - 71ubuntu2.2

---------------
partman-efi (71ubuntu2.2) bionic; urgency=medium

  * check.d/efi: Make sure we block on a missing EFI partition no matter what
    architecture, not just for ia64. One could attempt to install on EFI x86
    and will need an ESP to be able to install GRUB. (LP: #1803031)
  * check.d/efi: Drop duplicate ignore_uefi check.
  * debian/partman-efi.templates: Make the no_efi template clearer, so that it
    clearly explains why an EFI System partition is important.

 -- Mathieu Trudel-Lapierre <email address hidden> Thu, 31 Jan 2019 10:19:50 -0500

Changed in partman-efi (Ubuntu Bionic):
status: Fix Committed → Fix Released
Revision history for this message
Adam Conrad (adconrad) wrote : Update Released

The verification of the Stable Release Update for partman-efi 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.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package partman-efi - 71ubuntu5

---------------
partman-efi (71ubuntu5) disco; urgency=medium

  * check.d/efi: Make sure we block on a missing EFI partition no matter what
    architecture, not just for ia64. One could attempt to install on EFI x86
    and will need an ESP to be able to install GRUB. (LP: #1803031)
  * debian/partman-efi.templates: Make the no_efi template clearer, so that it
    clearly explains why an EFI System partition is important.

 -- Mathieu Trudel-Lapierre <email address hidden> Fri, 08 Feb 2019 17:04:09 -0500

Changed in partman-efi (Ubuntu Disco):
status: New → Fix Released
Revision history for this message
Steve Langasek (vorlon) wrote : Please test proposed package

Hello Vinicius, or anyone else affected,

Accepted partman-efi into cosmic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/partman-efi/71ubuntu4.1 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-cosmic to verification-done-cosmic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-cosmic. 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 for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in partman-efi (Ubuntu Cosmic):
status: New → Fix Committed
tags: added: verification-needed verification-needed-cosmic
Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Verification-done on cosmic with partman-efi/71ubuntu4.1:

Starting a d-i install with proposed enabled; with partman-efi installed in the d-i environment; I could verify that using manual partitioning and omitting to create an ESP in UEFI mode leads to showing the error message and blocking the user from continuing with the install. If the user creates their own ESP; then the install continues with no messages. This behaves the same in CSM mode or without CSM.

When installing in Guided Partitioning, in UEFI or BIOS mode; the user sees no warning and the install completes successfully.

In BIOS mode, the install just completes successfully with manual partitioning since an ESP is not required.

tags: added: verification-done-cosmic
removed: verification-needed verification-needed-cosmic
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package partman-efi - 71ubuntu4.1

---------------
partman-efi (71ubuntu4.1) cosmic; urgency=medium

  * check.d/efi: Make sure we block on a missing EFI partition no matter what
    architecture, not just for ia64. One could attempt to install on EFI x86
    and will need an ESP to be able to install GRUB. (LP: #1803031)
  * debian/partman-efi.templates: Make the no_efi template clearer, so that it
    clearly explains why an EFI System partition is important.

 -- Mathieu Trudel-Lapierre <email address hidden> Fri, 08 Feb 2019 17:06:18 -0500

Changed in partman-efi (Ubuntu Cosmic):
status: Fix Committed → Fix Released
Revision history for this message
John Pilkington (j-pilk) wrote :

I have spent far too long trying to install kubuntu 18.04.3 on an old HP box that has a recent installation of Windows 10: i7, 16 GB ram, 1TB HDD, SSD. C: has been shrunk to ~500 GB and new partitions created for /, swap and /home. Installation fails while copying files at ~83%. Sometimes 276 packages have been updated, although not by the installer. Installation media both DVD (verified) and Rufus-USB.

'ubuntu-bug ubiquity' is not available because keyboard and mouse become inactive; only the power-button works.

At no stage have I told the installer about the pre-existing Windows EFI partition, which I do not want to damage.

I have seen a suggestion (for CentOS) that it should be mounted (without reformatting) at /boot/efi, but would like confirmation that that would be appropriate here.

Revision history for this message
John Pilkington (j-pilk) wrote :

Eventually I abandoned this. The installer always made encouraging 'nearly there' comments before hard-crashing with around 85% files copied. The check of install media found no problems, with either release or daily images, and I had tried shrinking the windows partitions by different amounts before reformatting /, swap and /home, and with or without a second efi partition and nomodeset.

Steve Langasek (vorlon)
Changed in grub-installer (Ubuntu Disco):
status: Confirmed → Won't Fix
Revision history for this message
Aex Rauch (centaurie) wrote :

same happend for me in groovy (bios mode/Disklabel type: dos).
) Even I verrified live-session was boot in bios mode.

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

Other bug subscribers

Remote bug watches

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