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

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

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.

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.

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.

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.
Thanks,
Abhishek

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.

} EFI_DEVICE_PATH_PROTOCOL;

typedef struct {

    EFI_DEVICE_PATH_PROTOCOL Header;

    ///

    /// 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;

} HARDDRIVE_DEVICE_PATH;

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

Comparing the Debian sources for efibootmgr (http://anonscm.debian.org/gitweb/?p=collab-maint/efibootmgr.git;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: https://github.com/vathpela/efibootmgr/blob/master/src/include/efi.h) 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?

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.

Thanks, I'll apply this patch now.

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

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

Should be, yes.