# UEFI 2.3.1 INSYDE Corp. ignores boot order attempts MBR

## ManDay

Despite the recent interest in the other UEFI Thread, I think I should open this as a seperate one for it not only concerns a different problem but it also leaves the other thread with the discussion there.

On a different system than the one mentioned in the other thread, I've ran into the following problem:

The UEFI-Implementation is UEFI 2.3.1 by INSYDE Corp. I thus use Tianocore's UEFI-Shell 2.0 implementation and efibootmgr.

I installed an EFI Stub Kernel as /EFI/BOOT/BOOTX64.EFI. In fact is it acknowledged by the default location in which it sits and shows up in the "F12" Boot-Override Menu as "EFI HDD" and can be booted by explicitly choosing it.

However, all attempts to establish it as the primary, default boot device have failed. What happens when I boot is that I get an error in the like of "No bootable device found, enter boot device and press any key", which I interpret as it trying to boot from MBR.

I've tried all possible combinations of efibootmgr and also manually tampered with the UEFI-Vars through the UEFI-Shell's commands. In either case I can change the Boot Order to give priority to the (already registered) EFI-Entry, or even create my own EFI-Entry and give that precedence. But after I reboot, I will always get the error and next time I check, the HDD has again taken precedence.

My current, little satisfying workarround is to change the "Nextboot" Entry with a local.d stopping script, because the device appears to heed the "Nextboot" entry.

I'm wondering whether this is one of the bugs that were mentioned in the other thread, though, obviously, it would be more than a slight flaw; it practically renders EFI useless without a workarround.

PS: I noticed, among others, an entry "LegacyBootOrder" in /sys/firmware/efi/vars, which doesn't show up in the UEFI-Shell's dmpstore. I wonder whether it perhaps has to do with the problem and whether it can be accessed (I did not find any tool to directly write to /sys/firmware/efi in a more or less convenient fashion).

----------

## srs5694

 *ManDay wrote:*   

> Despite the recent interest in the other UEFI Thread, I think I should open this as a seperate one for it not only concerns a different problem but it also leaves the other thread with the discussion there.

 

Opening a new thread for a new problem is almost always the best course of action. Be aware, however, that there are currently several threads on (U)EFI issues on this forum, so I have no idea to which specific "other thread" you refer. (It doesn't really matter; I just wanted to point this out so that you know to provide an explicit link if you post something in the future that references another thread in a way that does matter.)

 *Quote:*   

> The UEFI-Implementation is UEFI 2.3.1 by INSYDE Corp. I thus use Tianocore's UEFI-Shell 2.0 implementation and efibootmgr.
> 
> I installed an EFI Stub Kernel as /EFI/BOOT/BOOTX64.EFI. In fact is it acknowledged by the default location in which it sits and shows up in the "F12" Boot-Override Menu as "EFI HDD" and can be booted by explicitly choosing it.
> 
> However, all attempts to establish it as the primary, default boot device have failed. What happens when I boot is that I get an error in the like of "No bootable device found, enter boot device and press any key", which I interpret as it trying to boot from MBR.

 

This is a new one to me. I've got one EFI implementation (Gigabyte's wretched "Hybrid EFI") that seems to erase its boot order information on every reboot, but it does at least boot the EFI/BOOT/BOOTX64.EFI file. I have three shot-in-the-dark suggestions and then some requests for additional information if those suggestions don't work. First, the suggestions:

Update your firmware to the latest version. (This is always a good starting point when dealing with firmware weirdness.)

Try varying the case of the EFI/BOOT/BOOTX64.EFI filename. You've presented it in all-uppercase, and in theory the case shouldn't matter; but in Gigabyte's Hybrid EFI, there's a case-sensitivity bug that causes the firmware to do some comparisons in a case-sensitive way. AFAIK, all EFI implementations share a good deal of code, so it's conceivable that this bug is shared with other systems, perhaps including yours. If your filename is really in all-caps, I'd start dropping to lowercase in stages beginning with the .efi extension and moving back the chain -- so EFI/BOOT/BOOTX64.efi, EFI/BOOT/bootx64.efi, EFI/Boot/bootx64.efi, EFI/boot/bootx64.efi, and efi/boot/bootx64.efi. Of course, it's possible that there's some other "magic" combination that would work; there are 32,768 possible case combinations for that filename, so it's impractical to test them all.

Change the filename from EFI/BOOT/BOOTX64.EFI to EFI/Microsoft/Boot/bootmgfw.efi. The latter is Microsoft's default boot loader filename, and some EFI implementations are hard-coded to recognize it instead of or in addition to EFI/boot/bootx64.efi.

If none of these things help, then I suggest you post some additional information that may give me (or somebody else) a useful clue:

Show us your partition table, as in "parted -l". (This also tells us the filesystem on your ESP; but if you use gdisk rather than parted, tell us if you're using FAT16 or FAT32.) Please post this and the next two items inside code blocks to preserve the formatting.

Show us the output of "efibootmgr -v".

Show us the output of "od -N 512 -x /dev/sda". This will reveal whether you've got a BIOS-mode boot loader in your MBR. (If you've got more than one disk, repeat this for each one.)

Go into your firmware's setup utility, locate any options that relate to boot order or preferences, and report them to us, including alternatives. For instance, you might say you've got something called "UEFI/Legacy Boot" that's set to "Enable Both" and that includes additional options of "Disable UEFI" and "Disable Legacy". An option like this specific example suggests obvious changes, but some options might be more obscure.

----------

## ManDay

 *srs5694 wrote:*   

>  *ManDay wrote:*   Despite the recent interest in the other UEFI Thread, I think I should open this as a seperate one for it not only concerns a different problem but it also leaves the other thread with the discussion there. 
> 
> Opening a new thread for a new problem is almost always the best course of action. Be aware, however, that there are currently several threads on (U)EFI issues on this forum, so I have no idea to which specific "other thread" you refer. (It doesn't really matter; I just wanted to point this out so that you know to provide an explicit link if you post something in the future that references another thread in a way that does matter.)
> 
>  *Quote:*   The UEFI-Implementation is UEFI 2.3.1 by INSYDE Corp. I thus use Tianocore's UEFI-Shell 2.0 implementation and efibootmgr.
> ...

 

To be clear: It recognizes the BOOTX64.EFI file in that it shows "EFI HDD" as one possible option in the "F12"-Menu. The thing is, that it cannot be made the default and does have to be chosen explicitly in order to boot it (or set as Nextboot-entry).

 *Quote:*   

> Update your firmware to the latest version. (This is always a good starting point when dealing with firmware weirdness.)

 

It took me a while, thus the late reply, but I managed to update to what's called 1.06 in the list of available updates

```
    BIOS    Acer    BIOS (UEFI for Windows 8)    2.04    6.8 MB    2012/10/02

   BIOS    Acer    BIOS    1.06    10.2 MB    2012/09/24

   BIOS    Acer    BIOS    1.05    12.0 MB    2012/08/13
```

The first listed entry, v 2.04 does not provide any DOS installer so I had no way of flashing it.

I'll go trough the other suggestions you made, asap - that just for now.

----------

## ManDay

 *srs5694 wrote:*   

> If none of these things help, then I suggest you post some additional information that may give me (or somebody else) a useful clue:
> 
> Show us your partition table, as in "parted -l". (This also tells us the filesystem on your ESP; but if you use gdisk rather than parted, tell us if you're using FAT16 or FAT32.) Please post this and the next two items inside code blocks to preserve the formatting.
> 
> Show us the output of "efibootmgr -v".
> ...

 

Well then:

Here are three exerpts from efibootmgr -v:

1: Before everything, created one entry for EFI:

```
BootCurrent: 0000

BootOrder: 0000

Boot0000* Windows Boot Manager  HD(1,800,f4000,acb56b8b-cbd3-4723-8547-751455cc3086)File(\EFI\Microsoft\Boot\bootmgfw.efi)RC
```

2: After one boot, I find:

```
BootCurrent: 0000

BootOrder: 0001,0000

Boot0000* Windows Boot Manager  HD(1,800,f4000,acb56b8b-cbd3-4723-8547-751455cc3086)File(\EFI\Microsoft\Boot\bootmgfw.efi)RC

Boot0001* Hitachi HTS545050A7E380               BIOS(2,500,00)................-...........A..........................................
```

3: After adjusting the bootorder and rebooting, I find again:

```
BootCurrent: 0000

BootOrder: 0001,0000

Boot0000* Windows Boot Manager HD(1,800,f4000,acb56b8b-cbd3-4723-8547-751455cc3086)File(\EFI\Microsoft\Boot\bootmgfw.efi)RC

Boot0001* Hitachi HTS545050A7E380          BIOS(2,500,00)................-...........A..........................................
```

```
Model: ATA Hitachi HTS54505 (scsi)

Disk /dev/sda: 500GB

Sector size (logical/physical): 512B/4096B

Partition Table: gpt

Disk Flags:

Number  Start   End     Size    File system     Name     Flags

1      1049kB  513MB   512MB   fat32           primary  boot

2      513MB   66.0GB  65.5GB  ext3            primary

3      66.0GB  68.1GB  2048MB  linux-swap(v1)  primary

4      68.1GB  70.1GB  2048MB  ext3            primary

5      70.1GB  72.2GB  2049MB  ext2            primary

6      72.2GB  500GB   428GB   ext3            primary
```

```
0000000 0000 0000 0000 0000 0000 0000 0000 0000

*

0000660 0000 0000 0000 0000 13b1 1d96 c9cf 0000

0000700 0001 feee 807f 0001 0000 602f 3a38 0000

0000720 0000 0000 0000 0000 0000 0000 0000 0000

*

0000760 0000 0000 0000 0000 0000 0000 0000 aa55

0001000
```

And there are no such option in my Firmware's interface.

To all things considered, the problem is in its core that the MBR Boot keeps taking precedence. If it isn't already, it's created with top priority in the EFI's boot list.

By the way, I just got word from Acer's "customer care" service: They don't know what's wrong and therefore closed my ticked as "solved". Lovely.

----------

## srs5694

I agree with your interpretation: Your firmware is unnecessarily switching to BIOS boot mode after every reboot. There's no sign of a BIOS boot loader in your MBR, and your partition table uses GPT and a FAT32 ESP, so there's really no reason for it to misbehave in this way. It's a bug. I have a number of suggestions at this point:

Review your firmware options one more time. It's conceivable that you missed something. Note that the examples I posted were merely examples -- there's no standardization in EFI firmware option names, so whatever affects EFI vs. BIOS booting could have another name on your system. It could also be missing entirely.

Return the computer for a refund and exchange it with another model. This is obviously only practical if it's reasonably new, and it'll be a pain. If your firmware is as defective as it's starting to seem to be, though, it may be the least painful course of action in the long run. It's also the one that's most likely to get the attention of the manufacturer and successfully deliver the message "don't give me a cruddy firmware!" (Be sure to reference the trouble ticket they closed, and tell them that prematurely closing the trouble ticket is part of why you returned the hardware.)

Find a way to flash that "2.04" firmware. You might be able to do this by extracting files from a self-extracting archive using a suitable utility or even by doing a temporary installation of Windows to flash the firmware.

Rely on the shutdown script you say you've written. In fact, you could change this to a startup script; that might help matters in the event of a system crash.

Stop fighting it and install a BIOS-mode boot loader. GRUB 2 can boot fine from GPT disks in BIOS mode, although it prefers to have a BIOS Boot Partition (which can usually be under 1MiB, although I've heard claims that 2MiB is sometimes required).

----------

## ManDay

 *srs5694 wrote:*   

> I agree with your interpretation: Your firmware is unnecessarily switching to BIOS boot mode after every reboot. There's no sign of a BIOS boot loader in your MBR, and your partition table uses GPT and a FAT32 ESP, so there's really no reason for it to misbehave in this way. It's a bug. I have a number of suggestions at this point:
> 
> [list]
> 
> [*]Review your firmware options one more time. It's conceivable that you missed something. Note that the examples I posted were merely examples -- there's no standardization in EFI firmware option names, so whatever affects EFI vs. BIOS booting could have another name on your system. It could also be missing entirely.[/quit]

 

There is absolutely nothing. As usual with (supposedly) EFI firmwares, the options are only a few. Six or seven, at most. The "Boot" Submenu only allows to rearrange a set of existing entries, among which "Network boot" and "CDROM" and the "HDD", but no mention of EFI whatsoever.

 *Quote:*   

> Return the computer for a refund and exchange it with another model. This is obviously only practical if it's reasonably new, and it'll be a pain. If your firmware is as defective as it's starting to seem to be, though, it may be the least painful course of action in the long run. It's also the one that's most likely to get the attention of the manufacturer and successfully deliver the message "don't give me a cruddy firmware!" (Be sure to reference the trouble ticket they closed, and tell them that prematurely closing the trouble ticket is part of why you returned the hardware.)

 

After I just noticed that only one EFI Entry is actually accounted for and all other are unavailable in the F12-Menu (which, in turn, is the only way to boot any EFI), I will do exactly that. I can still return the device without giving any reason and get my money back. But even if not, a defective EFI would surely be a reason to force a refund by German law.

It's kind of frustrating, though, this is the 3rd unsatisfactory device I've ordered and returned within approximately one month. :-(

 *Quote:*   

> Find a way to flash that "2.04" firmware. You might be able to do this by extracting files from a self-extracting archive using a suitable utility or even by doing a temporary installation of Windows to flash the firmware.
> 
> Rely on the shutdown script you say you've written. In fact, you could change this to a startup script; that might help matters in the event of a system crash.
> 
> Stop fighting it and install a BIOS-mode boot loader. GRUB 2 can boot fine from GPT disks in BIOS mode, although it prefers to have a BIOS Boot Partition (which can usually be under 1MiB, although I've heard claims that 2MiB is sometimes required).
> ...

 

Thanks for your help, although we couldn't solve the problem, I greatly appreciate it.

----------

## srs5694

 *ManDay wrote:*   

> There is absolutely nothing. As usual with (supposedly) EFI firmwares, the options are only a few. Six or seven, at most. The "Boot" Submenu only allows to rearrange a set of existing entries, among which "Network boot" and "CDROM" and the "HDD", but no mention of EFI whatsoever.

 

I'm sorry I couldn't suggest anything that would work. FWIW, your minimal EFI implementation is typical of the firmware in name-brand computers, whether they use a new UEFI or an old BIOS. To get a more complete set of setup options in your firmware, you often have to go the route of a build-it-yourself computer, building it from a motherboard, RAM, and other components yourself. If you don't want to do this yourself, some smaller computer sellers (like little specialist storefront sellers) build computers this way, often to your own specifications. You're still not guaranteed to get a lot of options, but you might. You can usually download the motherboard's manual in PDF form before you buy and search it for the string "EFI".

FWIW, I recently built a system from an ASUS P8H77-I motherboard, and it's got some moderately good EFI boot options.

----------

## ManDay

 *srs5694 wrote:*   

>  *ManDay wrote:*   There is absolutely nothing. As usual with (supposedly) EFI firmwares, the options are only a few. Six or seven, at most. The "Boot" Submenu only allows to rearrange a set of existing entries, among which "Network boot" and "CDROM" and the "HDD", but no mention of EFI whatsoever. 
> 
> I'm sorry I couldn't suggest anything that would work. FWIW, your minimal EFI implementation is typical of the firmware in name-brand computers, whether they use a new UEFI or an old BIOS. To get a more complete set of setup options in your firmware, you often have to go the route of a build-it-yourself computer, building it from a motherboard, RAM, and other components yourself. If you don't want to do this yourself, some smaller computer sellers (like little specialist storefront sellers) build computers this way, often to your own specifications. You're still not guaranteed to get a lot of options, but you might. You can usually download the motherboard's manual in PDF form before you buy and search it for the string "EFI".
> 
> FWIW, I recently built a system from an ASUS P8H77-I motherboard, and it's got some moderately good EFI boot options.

 

Well, there is one more route we could try, but I'd have to read up. After all, the "EFI Boot options" in the firmware's interface are practically superflous. EFI isn't oblidged to provide any such interface - all should be doable by the NVRAM EFI Vars. That's in fact the route I could still attempt to take. Unfortunally I couldn't find any utility which allows me to freely edit the EFI Vars - I'm suprised that something like that doesn't exist. From what I understood, to write to EFI Vars, one preferably uses the sysfs nodes and writes Structs to them - so I'd have to create a program which does this - then I could attempt to edit any of

```
AcpiGlobalVariable-c020489e-6db2-4ef2-9aa5-ca06fc11d36a    MTC-eb704011-1402-11d3-8e77-00a0c969723b AuthVarKeyDatabase-515fa686-b06e-4550-9112-382bf1067bfb    new_var BackupPlatformLang-8be4df61-93ca-11d2-aa0d-00e098032b8c    OEM_IGPU_VGA_INFO-8be4df61-93ca-11d2-aa0d-00e098032b8c Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c              PchInit-e6c2f70a-b604-4877-85ba-deec89e117eb Boot0001-8be4df61-93ca-11d2-aa0d-00e098032b8c              PchS3Peim-e6c2f70a-b604-4877-85ba-deec89e117eb BootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c           PlatformLang-8be4df61-93ca-11d2-aa0d-00e098032b8c BootDevice-0a4cd120-ea2d-4aef-a4b0-b0c08cbbdbbe            PlatformLangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c             ReadyToBootFlag-62c4782b-5492-4cf9-807a-5100efd27d1f ConIn-8be4df61-93ca-11d2-aa0d-00e098032b8c                 S3RestoreDataVariable-14ef381c-9721-434e-be09-192ab97e781f ConInCandidateDev-8be4df61-93ca-11d2-aa0d-00e098032b8c     SaPegData-c4975200-64f1-4fb6-9773-f6a9f89d985e ConInDev-8be4df61-93ca-11d2-aa0d-00e098032b8c              SaveHddPassword-86bbf7e3-b772-4d22-80a9-e7c58c3c7ff0 ConOut-8be4df61-93ca-11d2-aa0d-00e098032b8c                SaveHddPasswordInfo-a17d3ac5-4897-47b5-9912-21a9697ebdde ConOutCandidateDev-8be4df61-93ca-11d2-aa0d-00e098032b8c    SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c ConOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c             Setup-a04a27f4-df00-4d42-b552-39511302113d Custom-a04a27f4-df00-4d42-b552-39511302113d                SetupMode-8be4df61-93ca-11d2-aa0d-00e098032b8c del_var                                                    SignatureSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c ErrOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c             SmbiosPolicy-41a3ee4e-6d57-418b-8f8e-c366a5b70c4b LegacyDevOrder-a56074db-65fe-45f7-bd21-2d2bdd8e9652        SpdData-70a9c11d-f710-42f8-89c1-bde841dc9b45 MeBiosExtensionSetup-1bad711c-d451-4241-b1f3-8537812e0c70  VBiosInfo-bbd1fd65-5668-4fb2-8999-231095717a07 MrcS3RestoreVariable-14ef381c-9721-434e-be09-192ab97e781f
```

Note, for instance, LegacyBootOrder. Perhaps any of those will help. Do you think it's worth a try?

PS: I've contacted INSYDE with reference to this topic. Since they do not usually provide end-customer support the chances are slim that they will help with it, but perhaps they take it as a matter of honour to prove their EFI :>

----------

## ManDay

http://www.youtube.com/watch?v=ehs_7I8qMm0 @20:40

----------

## Jimmy Jazz

 *ManDay wrote:*   

> 
> 
> ```
> Model: ATA Hitachi HTS54505 (scsi)
> 
> ...

 

I do not have EFI but an embedded  gpt partition... created w/ parted. The disk is a 512B physical/ 4kb logical. It has just after the MBR signature 55 AA the word UEFI in it. Perhaps it is missing in your configuration. 

As a suggestion, change the logical size of your sd to 4096. You have a 4k disk. Why not optimize it. Also you need to backup your data first.

```

00001a00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

*

001001c0  01 00 ee fe ff ff 01 00  00 00 1f 57 38 3a 00 00  |...........W8:..|

001001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

*

001001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|

00100200  45 46 49 20 50 41 52 54  00 00 01 00 5c 00 00 00  |EFI PART....\...|

00100210  11 17 07 b8 00 00 00 00  01 00 00 00 00 00 00 00  |................|

00100220  1f 57 38 3a 00 00 00 00  22 00 00 00 00 00 00 00  |.W8:....".......|

00100230  fe 56 38 3a 00 00 00 00  11 a7 99 ce 78 09 62 4d  |.V8:........x.bM|

00100240  bb e1 89 a6 58 1a ec bc  02 00 00 00 00 00 00 00  |....X...........|

00100250  80 00 00 00 80 00 00 00  4e 27 7a 7e 00 00 00 00  |........N'z~....|

00100260  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

*

00100400  48 61 68 21 49 64 6f 6e  74 4e 65 65 64 45 46 49  |Hah!IdontNeedEFI|

00100410  bb e1 f1 cb 6a 8e 23 40  b3 30 79 2b 12 75 9f ba  |....j.#@.0y+.u..|

00100420  28 00 00 00 00 00 00 00  28 01 00 00 00 00 00 00  |(.......(.......|

00100430  00 00 00 00 00 00 00 00  62 00 6f 00 6f 00 74 00  |........b.o.o.t.|

00100440  6c 00 6f 00 61 00 64 00  65 00 72 00 00 00 00 00  |l.o.a.d.e.r.....|

00100450  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

*

```

----------

## ManDay

 *Jimmy Jazz wrote:*   

>  *ManDay wrote:*   
> 
> ```
> Model: ATA Hitachi HTS54505 (scsi)
> 
> ...

 

Thanks, but I can't quite tell what of this is supposed to be placeholder-nonsense and what is actually supposed to go in there. Are you saying I should overwrite the 4 next bytes to, literally "EFI PART"?! You do realize that it says "U??EFI PART" there? Could you please explain this again? Thanks in advance.

----------

## srs5694

 *Jimmy Jazz wrote:*   

> I do not have EFI but an embedded  gpt partition... created w/ parted. The disk is a 512B physical/ 4kb logical. It has just after the MBR signature 55 AA the word UEFI in it. Perhaps it is missing in your configuration. 

 

No, that is most emphatically not ManDay's problem. ManDay is attempting to boot in EFI mode, so BIOS-mode booting, even on a GPT disk, isn't directly relevant. Some GPT data structure damage could theoretically be causing problems, but there's no evidence of that in the various program outputs that ManDay posted, and parted, at least, is likely to complain or misbehave when such damage is present.

 *Quote:*   

> As a suggestion, change the logical size of your sd to 4096. You have a 4k disk. Why not optimize it. Also you need to backup your data first.

 

Based on a Google of the model number reported by parted, the disk appears to be a standard spinning disk, not an SSD. (I'm not sure if that's what you meant to imply by "sd.") I didn't dig deep enough to figure out if it's an Advanced Format disk with 4KiB physical sector size and 512-byte logical sector size, but even if it is, attempting to set the logical sector size to 4096 bytes (4KiB) will either have no effect or (more likely) will damage data on the disk. The proper way to treat Advanced Format disks is to align partitions on 8-sector boundaries. Most modern disk utilities do this by default, but it's a good idea to verify that it's being done. See this article I wrote on the topic for details. Note that an improperly aligned disk will not cause the problems ManDay has reported, so this issue is, at most, of peripheral relevance to the main topic of this thread.

It's unclear to me why you posted a hex dump of some GPT data. Unless a person is an expert, I strongly advise against hex-editing GPT data structures. Except for the protective MBR, GPT data structures include CRC values that must be recomputed after any change, and that's a pain to do manually. Disk partitioning tools do the job automatically, and keep other details straight, too. The libparted library (and hence GNU Parted, GParted, Palimpsest, and other utilities based on libparted) tends to abstract away some details that can be important, but GPT fdisk (gdisk, cgdisk, and sgdisk) doesn't; it provides close to direct access to the GPT data structures as they exist on the disk. Thus, if you need to muck with some sort of low-level or obscure GPT data structure, using gdisk rather than something based on libparted is the way to go. (There are some non-Linux tools, such as the "gpt" tool in FreeBSD and OS X, that can do some of this, too.)

 *ManDay wrote:*   

> Are you saying I should overwrite the 4 next bytes to, literally "EFI PART"?! You do realize that it says "U??EFI PART" there?

 

The part of the hex dump to which you refer is a part of the protective MBR and GPT header data. More specifically, the hex code 55 AA ("U" and an upper-byte value in ASCII) identifies the protective MBR as an MBR. (It's the last two bytes in the first sector.) The "EFI PART" string identifies the start of the GPT header. None of these bytes should be modified with a hex editor, and if any of them were missing or damaged, parted would have complained and probably refused to display any partition data. They are not the cause of your problem! (Trust me on this -- I wrote GPT fdisk from scratch and currently maintain rEFInd, so I understand GPT and EFI boot issues better than most.) If you're interested in low-level GPT data structures, the Wikipedia article on GPT provides the details, although the EFI/UEFI specification is technically more authoritative.

----------

## Jimmy Jazz

 *srs5694 wrote:*   

> 
> 
> Trust me on this -- I wrote GPT fdisk from scratch and currently maintain rEFInd, so I understand GPT and EFI boot issues better than most.
> 
> 

 

better not try to modify disk sectors directly.

The reason of the hexdump published was in response to the 55AA hexdump published above and an assumption  the 'efi bios' recognizes the mbr of a gpt partition because it has missed the right magic number.

I still believe, the setup of the disk isn't optimal.

----------

## srs5694

 *Jimmy Jazz wrote:*   

> The reason of the hexdump published was in response to the 55AA hexdump published above and an assumption  the 'efi bios' recognizes the mbr of a gpt partition because it has missed the right magic number.

 

No, it's correct; it's just that the "od" utility I suggested using and the "hexdump" utility that (I think) you used delivered the bytes in a different order. I also asked for only the first sector, so the "EFI PART" string that begins the next sector didn't appear in ManDay's output.

 *Quote:*   

> I still believe, the setup of the disk isn't optimal.

 

ManDay's problem is that the system is switching from an EFI-mode boot to a BIOS-mode boot on every reboot. I've not noticed anything in the data he's provided that explains this peculiarity, and he's provided (as requested) the data that's most diagnostic to similar problems I've encountered in the past. This is why I think it's a firmware bug. There are many ways in which a disk configuration can be non-optimal (improperly-aligned partitions, partitions sized or arranged in an inefficient manner, etc.) I don't see anything glaringly wrong in ManDay's configuration along those lines, but as the thread isn't about optimizing an otherwise properly-working system, I haven't asked for relevant diagnostic data. IMHO, it's best to stick to the problem at hand rather than looking for additional problems, at least at this point.

----------

