[Bug 1677027] Re: installer silently assumed EFI using removable drive's partition, breaking grub isoboot

[Simon Quigley]

** Changed in: ubiquity (Ubuntu)
       Status: New => Won't Fix

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to ubiquity in Ubuntu.
https://bugs.launchpad.net/bugs/1677027

Title:
  installer silently assumed EFI using removable drive's partition,
  breaking grub isoboot

Status in ubiquity package in Ubuntu:
  Won't Fix

Bug description:
  This issue was seen with the Ubuntu 16.04.1 and .2 desktop amd64 ISOs.

  When the installer boots in EFI mode on a legacy BIOS system, it
  normally presents the user with the choice of installing in legacy
  mode or creating a new EFI partition, etc.

  However, if any existing EFI partition is found, this question is
  skipped and it is silently assumed that the installed system should
  boot EFI, using that partition, even if that partition is on a
  removable (USB, /dev/sdb) drive. This means that:

  1) The target's /etc/fstab contains an entry to mount the removable
  EFI partition at /boot/efi

  2) The Ubuntu EFI files are installed into that partition

  3) Unless manual partitioning has been used (as in the attached log),
  the bootloader is also installed to the removable drive instead of the
  hard drive (observed in a previous install).

  For me, this resulted in a target system that booted perfectly fine,
  as long as that removable drive is present. Discovered in time, it was
  easy to fix by installing the grub-pc-bin package, running grub-
  install --target=i386-pc /dev/sda, and rebooting. The problem also
  does not occur if the installer boots in BIOS mode, regardless of the
  presence of that EFI partition. (So forcing BIOS boot, if possible, is
  also a good workaround, assuming one is aware of the problem in
  advance.)

  Why does this matter, and why do I have a removable drive with an EFI
  partition on it? Well, that is actually the drive I'm installing from,
  using the extremely useful ability of grub (and casper) to boot an ISO
  file directly from a filesystem, like this:

  menuentry "Ubuntu 16.04.1 Live Desktop amd64" --class ubuntu {
    set isoname="ubuntu-16.04.1-desktop-amd64.iso"
    set isofile="${isopath}/ubuntu/${isoname}"
    echo "Using ${isoname}..."
    loopback loop $isofile
    linux (loop)/casper/vmlinuz.efi boot=casper iso-scan/filename=${isofile} quiet splash
    initrd (loop)/casper/initrd.lz
  }

  Everything is on the removable drive: grub, the grub config, the ISO
  file itself, and of course the EFI partition.

  Note that casper seems to have special support for this: it mounts the
  partition containing the .iso file at /isodevice, then loopback mounts
  /isodevice/whatever/ubuntu-16.04.1-desktop-amd64.iso at /cdrom before
  the installation commences. All that works perfectly; the only issue
  is this EFI thing (and another very minor issue which I will file
  separately.)

  I'm not sure there's a clear solution to this, unless the installer
  can determine that an EFI partition is the same one it itself used to
  boot. We can't just ignore all partitions on the same drive as
  /isodevice, because grub isoboot is also useful to boot from an ISO
  file on a hard drive partition (in which case, the behavior is more or
  less correct.) It might simply be incorrect for the installer to
  assume anything about EFI partitions outside of the drives chosen to
  install to.

  I'm attaching the output of 'ubuntu-bug --save ubiquity' from the end
  of the installation; I can't seem to directly submit the file now that
  I've booted the system and ubiquity is no longer installed.
  Unfortunately it didn't seem to include all the active mountpoints,
  but the issue is easy enough to reproduce.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1677027/+subscriptions