EFI booting Ubuntu image to grub removes existing boot entries and makes system unbootable

Bug #1560973 reported by Iain Lane
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
grub2 (Ubuntu)
Triaged
Undecided
Steve Langasek

Bug Description

I'm using xenial image 20160323 on an XPS 13 2015 (9343). Booting (to grub) with the image on a USB stick is enough to make my previously installed system unbootable!

1. Have the system in EFI mode and an installed Ubuntu system. I have Secure Boot on too. Make sure the installation boots properly.
2. Burn image to USB drive. I used dd, but doubt that matters.
3. Insert USB drive into "target" system.
4. (Re)boot it, select to boot from the USB drive if it doesn't do that for you.
5. See the grub menu from the image.
6. Don't choose anything. Turn the system off.
7. Take the USB stick out.
8. Turn the system back on.
9. See "No bootable devices fdund."

Obviously at "9" it should instead boot into your previous installation, since you didn't change anything.

You can repair the system by entering setup (F2) and re-adding the boot entry. Settings -> General -> Boot Sequence -> Add Boot Option. Click the "…" next to File Name and pick EFI/ubuntu/shimx64.efi. Then exit setup and it should reboot and work again.

Tags: iso-testing
Iain Lane (laney)
summary: - EFI booting Ubuntu image to grub removes existing boot entries
+ EFI booting Ubuntu image to grub removes existing boot entries and makes
+ system unbootable
description: updated
Iain Lane (laney)
affects: ubuntu → grub2 (Ubuntu)
Iain Lane (laney)
description: updated
description: updated
Revision history for this message
Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1560973

tags: added: iso-testing
Revision history for this message
Dave Morley (davmor2) wrote :

This only effects ubuntu on ubuntu installs

I have confirmed that fedora 23 ubuntu 16.04 side by side works as expected.

I believe the cause is that all ubuntu installs share a common path to file ie /boot/EFI/ubuntu/shim..... where as Fedora is at /boot/EFI/fedora/shim......

Changed in grub2 (Ubuntu):
status: New → Confirmed
Revision history for this message
Dave Morley (davmor2) wrote :

I am aslo assuming that windows would be safe too as that is located in another directory too

Revision history for this message
Iain Lane (laney) wrote :

Are you saying this:

 - Have both Ubuntu and Fedora installed on the same system.
 - Have a menu to select between the two at boot.
 - Insert a USB stick containing 20160323
 - Reboot
 - Look at the grub menu from the USB stick
 - Reboot
 - Both menu items (Ubuntu and Fedora) are still displayed

?

Revision history for this message
Iain Lane (laney) wrote :

> - Look at the grub menu from the USB stick

Remove USB stick

> - Reboot

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

To debug this, I would like to see the results from:
 - from your existing system, run 'efibootmgr -v' and paste the output.
 - boot to the installer
 - from a terminal, run 'efibootmgr -v' and paste the output.
 - remove the USB stick.
 - reboot.
 - if your boot options come up, reboot again until you reproduce the bug.
 - insert the USB stick and reboot.
 - if at all possible, boot the USB stick without adding the stick to the firmware's boot options. I.e., if the grub on the USB stick comes up automatically, boot it; if you have an option to boot from a file *without* doing 'add boot option', do that.
 - once booted, get the output of 'efibootmgr -v' again.

Changed in grub2 (Ubuntu):
assignee: nobody → Steve Langasek (vorlon)
status: Confirmed → Incomplete
Revision history for this message
Dave Morley (davmor2) wrote :

Right okay so the setup was this:

On kvm I install fedora on a full qcow2 hdd.
I then repartition it to create some free space as I didn't realise that fedora uses lvm by default
In the free space I then install ubuntu

In EFI menu of uefi I now can boot from fedora or from ubuntu

When I look at /boot/EFI I now see separate folders for Fedora and Ubuntu each Folder has the similarly named files in for shim etc in order to boot.

Revision history for this message
Dave Morley (davmor2) wrote :

The Ubuntu install has the grub auto detect os on it so has entries for Ubuntu and Fedora. But fedora didn't run that so in the fedora efi session it only has to option to boot fedora in grub.

Revision history for this message
Iain Lane (laney) wrote :
Revision history for this message
Iain Lane (laney) wrote :
Revision history for this message
Iain Lane (laney) wrote :
Revision history for this message
Iain Lane (laney) wrote :

The "SanDisk Cruzer Blade" is a USB stick with a single ext4 partition that I used to transfer the log files out, FWIW.

And I'm running bios A05. I note that there's an A07 available. I could upgrade to that if you think that's useful, but -ENOTIME today. Could try tomorrow.

Revision history for this message
Iain Lane (laney) wrote :

> The "SanDisk Cruzer Blade" is a USB stick with a single ext4 partition that I used to transfer the log files out, FWIW.

That might be blatant lies. The drive I booted from is also the same make. :)

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

I think this confirms that what we're seeing is a firmware bug. It is possible to work around this particular firmware bug with the use of shim's fallback.efi, which we have not yet integrated into Ubuntu. Marking this as a duplicate of bug #1366546.

Changed in grub2 (Ubuntu):
status: Incomplete → Triaged
Revision history for this message
Dave Morley (davmor2) wrote :

Laney do you have an entry in /boot/efi/EFI/boot/bootx64.efi there is a bug in the efi firmware which means if this file is missing it effectively can not see your partition. when you manually add an entry it will stay till the boot partition is triggered like on the usb pendrive.

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.