Public bug reported:
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.
** Affects: ubiquity (Ubuntu)
Importance: Undecided
Status: New
** Attachment added: "ubiquity.bug"
https://bugs.launchpad.net/bugs/1677027/+attachment/4849191/+files/ubiquity.bug
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1677027
Title:
installer silently assumed EFI using removable drive's partition
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1677027/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
