First, I'll explain my situation

  • Device: ASUS x205ta with 32GB eMMC (Windows 8.1+Bing installed). Lets call this /dev/mmcblk0
  • usb flash drive: 64GB Sandisk ultra. installed Ubuntu 14.04. Lets call this /dev/sda

check out result of parted -l

root@chkwag-X205TA:/home/chkwag# parted -l
Model: SanDisk SanDisk Ultra (scsi)
Disk /dev/sda: 31.6GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system     Name  Flags
 1      1049kB  2048MB  2047MB  linux-swap(v1)
 2      2048MB  2147MB  99.6MB  fat32                 boot
 3      2147MB  31.6GB  29.5GB  ext4

Error: /dev/mmcblk0rpmb: unrecognised disk label                          

Error: /dev/mmcblk0boot0: unrecognised disk label                         

Error: /dev/mmcblk0boot1: unrecognised disk label                         

Model: MMC SDW32G (sd/mmc)
Disk /dev/mmcblk0: 31.3GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name                          Flags
 1      1049kB  106MB   105MB   fat32        EFI system partition          boot
 2      106MB   240MB   134MB                Microsoft reserved partition  msftres
 3      240MB   20.5GB  20.3GB  ntfs         Basic data partition          msftdata
 4      20.5GB  31.3GB  10.7GB  ntfs         Basic data partition          hidden, diag

eMMC and flash drive each has a ESP (format: FAT32). Currently, I'm loading Ubuntu through GRUB2(named bootia32.efi) in the ESP of usb flash drive by adding a UEFI menu entry pointing to this bootia32.efi file.(entry grub-stable below)

check out UEFI menu entries:

root@chkwag-X205TA:/home/chkwag# efibootmgr -v
BootCurrent: 0004
Timeout: 2 seconds
BootOrder: 0005,0007,0006,000C,0000,0001,0002,0003
Boot0000* Windows Boot Manager  HD(1,800,32000,321f056d-350b-44ac-ac85-b19a4fac6b77)File(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.}...e................
Boot0001* UEFI:CD/DVD Drive BIOS(81,0,00)
Boot0002* UEFI:Removable Device BIOS(82,0,00)
Boot0003* UEFI:Network Device   BIOS(83,0,00)
Boot0005* grub_stable   HD(2,3d0800,2f800,97a32bdd-cbf7-4583-a071-d205f5134f43)File(\EFI\BOOT\bootia32.efi)
Boot0006* fakeMS    HD(1,800,32000,321f056d-350b-44ac-ac85-b19a4fac6b77)File(\EFI\FAKE_MS\BOOT\BOOTMGFW.EFI)
Boot0007* grub1 HD(1,800,32000,321f056d-350b-44ac-ac85-b19a4fac6b77)File(\EFI\GRUB32.EFI)
Boot000C* UEFI: SanDisk SanDisk Ultra PMAP  ACPI(a0341d0,0)PCI(14,0)USB(2,0)USB(2,0)HD(2,3d0800,2f800,97a32bdd-cbf7-4583-a071-d205f5134f43)..BO

In sense of building a dual-boot system, this does suffice but I wanted to take this further and get the UEFI firmware to load GRUB2 from ESP of eMMC (Just a personal quest). To do this, I just copied bootia32.efi that I used before in ESP of eMMC, and made a UEFI menu entry loading this file explicitly. (entry named grub1. grub32.efi is just a renamed version of bootia32.efi)

Theoretically, I believe this is correct. However, when I use this UEFI menu entry, I will not work and just execute the original windows boot manager also located in the same ESP.

I did everything I could such as renaming bootia32.efi to something else or replacing the original windows boot manager(bootmgfw.efi) with bootia32.efi with the same name. But all attemps failed.

As I said, if everything is set correctly according to THEORY, then what am I missing? What else is there that can somehow ignore my UEFI menu entry that loads GRUB2 and just decides to load windows boot manager? Or as another possibility, bootia32.efi in eMMC's ESP is somehow magically not working?

boot order should not be an issue here since if my menu entry is correct, then there is no need to move on to the next boot order. Besides, I've confirmed that loading bootia32.efi alone should still get me a command line interfaced GRUB2 if grub.cfg is not found nearby.


To verify the possibility of customized EFI firmware that prevents me from what I want to do, I asked ASUS techincal support on this matter. I received a reply saying that they cannot answer to such attempts that require firmware modification.

Although this answer doesn't clarify the cause of the problem, but it does add to the possibility that the firmware is rigged. Reverse engineering on BIOS firmware is necessary for further investigation but due to the depth and technical difficulty of such an approach, it would be appropriate to end this question here.

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.