Installing UEFI boot entry on Hyper-V gen 2 corrupts VM configuration, making the VM unuseable

Bug #1272664 reported by Jan Henke on 2014-01-25
This bug affects 4 people
Affects Status Importance Assigned to Milestone
efibootmgr (Debian)
Fix Released
efibootmgr (Ubuntu)
Colin Watson

Bug Description

Installing Ubuntu on a generation 2 Hyper-V VM corrupts the configuration of said VM, so the VM cannot be loaded by the VM manager any more and the VMs settings are no longer accessable.

I narrowed the cause of the bug down to the creation of the boot loader entry in the VMs UEFI.

Steps to repoduce:
* Create a new generation 2 VM in Hyper-V
* Use a Alpha 2 (or newer) image of 14.04 to install (X-)Ubuntu (Kernel 3.13 or newer is required for the generation 2)
* After the successful installation try to access the VMs settings menu -> No longer accessaible, Hyper-V returns an error
* Check the Hyper-V Manager -> The corrupted VM is no longer in the list of VMs.

Additional it can be confirmed afterwards by doing:
* Create a new generation 2 VM using the same virtual hard drive file (*.vhdx) used before.
* Boot into the live session.
* Create the UEFI boot entry again
-> VM is again corrupted and shows the same symptoms as above.

This bug breaks Ubuntu on Hyper-V generation 2. That is a serious issue, as the generation 2 offers a lot of improvements over the generation 1.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: grub-efi-amd64-signed 1.27+2.00-22
ProcVersionSignature: Ubuntu 3.13.0-5.20-generic 3.13.0
Uname: Linux 3.13.0-5-generic x86_64
ApportVersion: 2.13.1-0ubuntu1
Architecture: amd64
CasperVersion: 1.336ubuntu1
Date: Sat Jan 25 12:25:12 2014
LiveMediaBuild: Xubuntu 14.04 LTS "Trusty Tahr" - Alpha amd64 (20140121.1)
 PATH=(custom, no user)
SourcePackage: grub2-signed
UpgradeStatus: No upgrade log present (probably fresh install)

Related branches

Jan Henke (jhe) wrote :
affects: grub2-signed (Ubuntu) → efibootmgr (Ubuntu)
Launchpad Janitor (janitor) wrote :

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

Changed in efibootmgr (Ubuntu):
status: New → Confirmed
Dimitri John Ledkov (xnox) wrote :

Colin, maybe you can look at this bug? Although installing efibootmgr is not causing dataloss, the Virtual Machines configuration is corrupted and thus hypervisor stops recognising those VMs.

Changed in efibootmgr (Ubuntu):
importance: Undecided → High
assignee: nobody → Colin Watson (cjwatson)
Jan Henke (jhe) wrote :

I tried again with the current daily image (2014-02-07). The boot entry itself is created and Ubuntu boots after the installation, but it is of little help as the VM configuration is still corrupted and not longer visible in the Hyper-V manager. This bug needs to be fixed!

Attached you find the content of /var/log/installer in case that is of any help.

Jan Henke (jhe) wrote :

I tried again with the daily build ISO from today (March 1st) and can confirm it is really the boot entry, which is corrupting the configuration file.
Once the boot entry was created by the installer, the configuration was no longer readable by Hyper-V, removing hte ubuntu entry from UEFi with efibootmgr restored the configuration files again.

So we must find out how the UEFI boot entry can be created without breaking Hyper-V.

Abhishek Gupta (abgupta) wrote :

There are two bugs here:

a) The UEFI boot entry seems to be created incorrectly. It appears that there are 6 extra zeroes in the Hard Drive Media Device Path as shown in Red (See attached picture). We suspect that the structure related to the hard drive media device path is not packed because of which it's size is coming out to be 0x30 bytes instead of the expected 0x2A as per UEFI specifications.

As of now we are examining the files in the Linux kernel that may be relevant to the hard drive media device path and will shortly post the names of the files that might be containing this issue.

b) Hyper-V is unable to deal with improperly formatted hard drive media device paths. The problem has been reported to the Hyper-V team and will be addressed in future.

I have added the relevant Ubuntu people to this issue. Please take note and fix the problem.

Abhishek Gupta (abgupta) wrote :

The problem appears to be in the following UEFI structures:

typedef struct {

    UINT8 Type; ///< 0x01 Hardware Device Path.

    ///< 0x02 ACPI Device Path.

    ///< 0x03 Messaging Device Path.

    ///< 0x04 Media Device Path.

    ///< 0x05 BIOS Boot Specification Device Path.

    ///< 0x7F End of Hardware Device Path.

    UINT8 SubType; ///< Varies by Type

    ///< 0xFF End Entire Device Path, or

    ///< 0x01 End This Instance of a Device Path and start a new

    ///< Device Path.

    UINT8 Length[2]; ///< Specific Device Path data. Type and Sub-Type define

    ///< type of data. Size of data is included in Length.


typedef struct {



    /// Describes the entry in a partition table, starting with entry 1.

    /// Partition number zero represents the entire device. Valid

    /// partition numbers for a MBR partition are [1, 4]. Valid

    /// partition numbers for a GPT partition are [1, NumberOfPartitionEntries].


    UINT32 PartitionNumber;


    /// Starting LBA of the partition on the hard drive.


    UINT64 PartitionStart;


    /// Size of the partition in units of Logical Blocks.


    UINT64 PartitionSize;


    /// Signature unique to this partition:

    /// If SignatureType is 0, this field has to be initialized with 16 zeros.

    /// If SignatureType is 1, the MBR signature is stored in the first 4 bytes of this field.

    /// The other 12 bytes are initialized with zeros.

    /// If SignatureType is 2, this field contains a 16 byte signature.


    UINT8 Signature[16];


    /// Partition Format: (Unused values reserved).

    /// 0x01 - PC-AT compatible legacy MBR.

    /// 0x02 - GUID Partition Table.


    UINT8 MBRType;


    /// Type of Disk Signature: (Unused values reserved).

    /// 0x00 - No Disk Signature.

    /// 0x01 - 32-bit signature from address 0x1b8 of the type 0x01 MBR.

    /// 0x02 - GUID signature.


    UINT8 SignatureType;


It is our guess that HARDDRIVE_DEVICE_PATH is not packed in the Ubuntu source tree. Please confirm.

Jan Henke (jhe) wrote :

Comparing the Debian sources for efibootmgr (;a=blob;f=src/include/efi.h;h=be667ae9cbe92bf7a24009a37a2c484bd73ec782;hb=HEAD#l298) and the source tree upstream (at least I think that is the current upstream: reveals that in the Debian tree the structure is packed, but a 6 byte padding is applied unconditionally. Upstream the padding just applies to the IA64 arch.

Where should this be patched, in Debian or in Ubuntu?

Jan Henke (jhe) wrote :

I reported it as a Debian bug as well. The Debian bug has a patch attached, which removes the extra padding for all architectures except IA64.

Changed in efibootmgr (Debian):
status: Unknown → New
Colin Watson (cjwatson) wrote :

Thanks, I'll apply this patch now.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package efibootmgr - 0.5.4-7ubuntu1

efibootmgr (0.5.4-7ubuntu1) trusty; urgency=medium

  * Remove device path padding on non-Itanium (LP: #1272664).
 -- Colin Watson <email address hidden> Tue, 11 Mar 2014 13:48:08 +0000

Changed in efibootmgr (Ubuntu):
status: Confirmed → Fix Released
Chris Valean (chvale) wrote :

Will this be included in the daily build for tomorrow - March 12?

Changed in efibootmgr (Debian):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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