Thursday, 3 November 2016

Weird UEFI-boot behaviour from my Asus Z87A mainboard

I was trying to boot a UEFI grub2 payload yesterday when I discovered something odd.

I was using an IODD 2531 Hard disk enclosure fitted with an SSD. I had loaded the grub2 menu system .imgPTN file using Switch_E2B.exe so it had the grub2 .EFI boot files present.

I then connected the drive to my Lenovo IdeaPad 300 and pressed F12 to get the Boot Selection menu. A UEFI boot entry was then displayed, so I selected that option and it booted to the grub2 menu - no problem!

Next, I did the same thing but using my Asus Z87A PC. To my surprise, the BIOS refused to list the IODD 2531 as a UEFI-bootable drive! There was an MBR-bootable option for the USB drive, but there was no UEFI boot option listed. This was very strange because I had UEFI-booted in this way dozens of times before from the same PC in the same way.

When I examined the Master Boot Record using RMPrepUSB - Drive Info - 0, I found that I had these partitions:

ptn #1 : FAT32 with EFI boot files
ptn #2 : NTFS with payload files
ptn #3 : Type 0x83 ext3 partition
ptn #4 : (empty)

Now ptn #3 was not supposed to be there. It was only there because it was left over from a previous experiment and because the grub2 .imgPTN file was switched in, it left partitions 2 and 3 alone, so that both were still present.

So I deleted ptn #3 and tried it again in the Z87A PC. This time the BIOS listed a bootable UEFI option for the IODD 2531 and it could now UEFI-boot.

So it seems that the mere presence of the Type 0x83 ext3 partition prevents the Z87A firmware from detecting the USB drive as UEFI-bootable!

Weird!

Footnote:
It seems that most UEFI BIOSes do not like MBR partitions which are out of order.
If a non-zero partition type is present and the Start Sector value is lower then the previous partition table entry, then it regards the whole disk MBR as invalid.

So in the above case, the start sector of partition 3 was before the start sector of partition 2.
Changing the partition 3 type to 0x00 fixed the issue and linux could still access the ext partition.




No comments:

Post a Comment