efibootmgr not changing boot order permanently

So, here's the story...
 
An HP laptop with Windows 7 and Ubuntu 12.04 (Precise Pangolin) dual-booted by GRUB2 is the central character. My friend handed me over saying that one fine morning 'she' found it to boot directly to Windows 7 without offering the usual OS selection (Windows 7, Ubuntu 12.04) menu. Also she was confident that she did absolutely "nothing" which could the reason be. With my limited knowledge, unless at least a single bit changes on HD, it is impossible. Promising to try to fix it up, I turned the laptop on. To my desperation, I found it to be one with stupid UEFI firmware. Pressing F9 leads to one firmware menu listing out EFI boot images. Ubuntu was present there. Selecting that one could boot Ubuntu as usual. From within Ubuntu, I tried using fdisk -l and was reported that fdisk was unable to read GPT partition table. So, I used GParted instead. There was one EFI partition of ~400MB as usual. That partition gets automatically mounted under /boot. Examining the contents inside, I found nothing unusual. AFAICR, it should be a VFAT filesystem. Also first 446 bytes of MBR was zero-filled. I googled and found something 'magical' called efibootmgr, the magic wand to play with EFI system. Now, the pain begins.
 
efibootmgr -v prints out the EFI boot images where both Windows 7 and Ubuntu were there alongwith other options, as expected.
efibootmgr -n switch is supposed to change the default boot loader for the next boot ONLY. I set BootNext field to Ubuntu and GRUB2 menu appeared in the next boot!
efibootmgr -o X, Y switch is supposed to change the default boot loader permanently. Delighted with the previous success, I changed the boot order Ubuntu follwed by Windows 7. efibootmgr -v confirmed that the changes took place as expected. But, to my surprise, laptop booted to Windows 7 directly on next boot!!!
 
Thereafter, I did a lot of tinkering with the laptop with no success. I tried using bcdedit, EasyBCD etc. and even more which I am too lazy to type unless asked specifically. All the attempts were in vain. Suddenly, I got this google hit
 

Issue #1 On HP laptop I cannot change the default boot OS in the BIOS, But when I used the F9 option at boot I can boot to ubuntu.

Issue #2 When I use efibootmgr -o command as seen below to change the boot order. During boot the laptop revert back to the the old boot order before the change. interstingly the -n option works (i,e modify boot order for the next boot only). I would like to avoid placing efibootmgr -n ... in my rc.local.

.

Any idea how to make efibootmgr change the boot order permanently? Since the laptop was dual-booting earlier, so there must be "something" to bypass this quirk.

From this thread (linked in one of the posts in the thread you posted):

http://h30434.www3.h...tu/td-p/2503733

http://h30434.www3.h...ht/true#M142143

it seems like *somehow* that stupid^2 (that is stupid to the power of two, being EFI and HP) setup is "hardcoded" to load bootmgfw.efi.

The idea of renaming grubx64.efi to bootmgfw.efi is not that bad IMHO (at least to see if this is the issue).

Wonko

I tried using bcdedit,

bcdedit /enum firmware

bcdedit /set {bootmgr} path \EFI\ubuntu\grubx64.efi

Hi

The great project Boot Repair Disk will auto fix both Legacy GRUB and GRUB EFI (even if "Secureboot" enabled ). You should give it a try.

http://sourceforge.n...ts/boot-repair/

There is IMNSHO a word for describing a 520 Mb .iso which is meant to repair a boot setup of GRUB2, the word is "bloat", to which you can add as attributes "huge, senseless"

Cannot say if it is "great", but surely it is "large".

I wonder why exactly they have not made downloadable files for just the boot-repair tool, which should run alright under Ubuntu and force people to download the big .iso.

Wonko

 

 

I wonder why exactly they have not made downloadable files for just the boot-repair tool, which should run alright under Ubuntu   and force people to download the big .iso. 

Indeed you can install it under Ubuntu.Here is how - https://help.ubuntu....ity/Boot-Repair

It saved my ass a couple of times and certainly it is not a bloat. Perhaps, advanced users like you may not find any use of it but average users like me who don't have advanced Linux command line skills will surely call it great. 

Here's the output for a series of commands:.

Also, what surprising is, every time I boot into Windows, one more entry for Ubuntu gets added. Already you can see three such entries are there which I marked RED. Below is the F9 menu corresponding to efibootmgr -v command's output.

it seems like *somehow* that stupid^2 (that is stupid to the power of two, being EFI and HP) setup is "hardcoded" to load bootmgfw.efi.

The idea of renaming grubx64.efi to bootmgfw.efi is not that bad IMHO (at least to see if this is the issue).

It works. I found this solution even before posting. But I wonder whether this laptop, with its earlier *working* configuration, had a copy of grubx64 .efi renamed as bootmgfw.efi which, got somehow got replaced by Windows 7 boot loader transparently.

Now, the problem is I can't boot into Windows from F9 menu as it points to renamed bootmgfw.efi internally.

Indeed you can install it under Ubuntu.Here is how - https://help.ubuntu....ity/Boot-Repair

Which is very good , still I don't understand why it is not by itself on the Sourceforge page and "common" users are "forced" to download (senselessly) a 520 Mb .iso (the bloat is referred to the .iso not to the tool in itself).

IMNSHO if this is a "generic" tool, it is good to have it easily installable in "generic" Linuxes, if it is a "self-standing recovery tool", it should be part of a VERY MINIMAL .iso.

@Holmes.Sherlock

Sure, the point is whether you are doing archeological or forensic research or if the goal is to have the stupid HP working now (no matter how it worked before and what exactly changed this behaviour).

If the former, that's good.

Is it possible that one of the automagic updates of WIndows 7 have replaced bootmgfw.efi?

Is it possible that when the Ubuntu was originally installed the same workaround has been used (either manually or by the Ubuntu setup)?

Can' tyou ask your friend what she remembers of the original Ubuntu install?

What happens if you image that PC, and then re-install Ubuntu?

Wonko

Sure, the point is whether you are doing archeological or forensic research...

 
Actually it's like that...
 

Can' t you ask your friend what she remembers of the original Ubuntu install?

Girl- Which computer do you have?
 
Boy- I have a computer with Intel core i7 processor at 3.3 ghz, Windows 7, 64 bit, 8GB RAM & Nvidia GTX 560 graphics card.
 
Boy- Which computer do you have???
 
Girl- A PINK ONE !!

What happens if you image that PC, and then re-install Ubuntu?

 
I don't have HD to store ~500 GB of image data.

But, I found something interesting once again. When I am trying to boot Windows from GRUB2 menu (Not from F9 menu offered by the firmware), GRUB2 is not being able to find the drivemap command and the boot fails. Exactly the same problem as described here.

Let's analyse first.

Run

bcdedit /enum firmware

Post the output.

Does firmware list displayorder {bootmgr} first?

Here's the output.

Here's the output.

BCDedit.exe /delete {254abf35-5f3a-11e3-bec6-806e6f6e6963} /cleanup /f
BCDedit.exe /delete {254abf36-5f3a-11e3-bec6-806e6f6e6963} /cleanup /f
BCDedit.exe /delete {2f9b67c2-5995-11e3-bec4-bc8556cd5fc6} /cleanup /f
BCDedit.exe /delete {2f9b67c3-5995-11e3-bec4-bc8556cd5fc6} /cleanup /f
BCDedit.exe /delete {3bcdfe9a-598c-11e3-bebb-806e6f6e6963} /cleanup /f
BCDedit.exe /delete {3bcdfe9b-598c-11e3-bebb-806e6f6e6963} /cleanup /f
BCDedit.exe /delete {b77ea3c8-5e57-11e3-bec5-806e6f6e6963} /cleanup /f
BCDedit.exe /delete {b77ea3c9-5e57-11e3-bec5-806e6f6e6963} /cleanup /f

When I am trying to boot Windows from GRUB2 menu (Not from F9 menu offered by the firmware), GRUB2 is not being able to find the drivemap command and the boot fails.

mountvol.exe S: /s
start notepad.exe S:\EFI\ubuntu\grub.cfg

menuentry "Windows" {
  chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}

Is it possible that one of the automagic updates of WIndows 7 have replaced bootmgfw.efi?

Is it possible that when the Ubuntu was originally installed the same workaround has been used (either manually or by the Ubuntu setup)?

Probably you are right. There are plenty of threads over Internet saying that Ubuntu overwriting Microsoft boot files to workaround bugs in some UEFI implementations. Here is the output of find /boot.efi -name *.efi -ls | sort --key=7,7. Can you find something interesting?

bootmgfwU.efi is renamed grubx64.efi.

It's strange currently.

Some cleanup to delete double entries

BCDedit.exe /delete {254abf35-5f3a-11e3-bec6-806e6f6e6963} /cleanup /f
BCDedit.exe /delete {254abf36-5f3a-11e3-bec6-806e6f6e6963} /cleanup /f
BCDedit.exe /delete {2f9b67c2-5995-11e3-bec4-bc8556cd5fc6} /cleanup /f
BCDedit.exe /delete {2f9b67c3-5995-11e3-bec4-bc8556cd5fc6} /cleanup /f
BCDedit.exe /delete {3bcdfe9a-598c-11e3-bebb-806e6f6e6963} /cleanup /f
BCDedit.exe /delete {3bcdfe9b-598c-11e3-bebb-806e6f6e6963} /cleanup /f
BCDedit.exe /delete {b77ea3c8-5e57-11e3-bec5-806e6f6e6963} /cleanup /f
BCDedit.exe /delete {b77ea3c9-5e57-11e3-bec5-806e6f6e6963} /cleanup /f

 
Actually it corresponds to the problem as stated here. Already there are 16 such entries got added. Is there any means to rebuild BCD? bootrec /rebuildbcd does not work from elevated command prompt.
 

Also, what surprising is, every time I boot into Windows, one more entry for Ubuntu gets added. Already you can see three such entries are there which I marked RED. Below is the F9 menu corresponding to efibootmgr -v command's output.

Which files matches the filenames
\EFI\Microsoft\Boot\bootmgfw.efi
\EFI\ubuntu\grubx64.efi
The original ones, or renamed ones?

 
To solve the problem, I did as follows:

• Renamed \EFI\Microsoft\Boot\bootmgfw.efi to \EFI\Microsoft\Boot\bootmgfw_old.efi
• Copied \EFI\ubuntu\grubx64. as \EFI\Microsoft\Boot\bootmgfw.efi

This is what my ESP (EFI System Partition) contains at present.
 

Which grub.cfg do you use?

At evelated permissions

mountvol.exe S: /s
start notepad.exe S:\EFI\ubuntu\grub.cfg

\EFI\ubuntu\grub.cfg contains the following:

search.fs_uuid c629b400-fdfe-4c3e-bd68-81bbb2a917c0 root 
set prefix=($root)/boot/grub
configfile $prefix/grub.cfg

Also let me extract out relevant entries from /boot/grub/grub.cfg after running update-grub:
 

### BEGIN /etc/grub.d/25_custom ###
menuentry "Windows UEFI bkpbootmgfw.efi" {
search --fs-uuid --no-floppy --set=root D692-2CA0
chainloader (${root})/EFI/Microsoft/Boot/bkpbootmgfw.efi
}
 
menuentry "Windows Boot UEFI loader" {
search --fs-uuid --no-floppy --set=root D692-2CA0
chainloader (${root})/EFI/Boot/bkpbootx64.efi
}
 
menuentry "Windows - (hd0,gpt2)" {
chainloader (hd0,gpt2)/efi/Microsoft/Boot/bkpbootmgfw.efi
}
### END /etc/grub.d/25_custom ###
 
### BEGIN /etc/grub.d/30_os-prober ###
menuentry "Windows 8 (loader) (on /dev/sda4)" --class windows --class os {
insmod part_gpt
insmod ntfs
set root='(hd0,gpt4)'
search --no-floppy --fs-uuid --set=root 38707C48707C0F3E
drivemap -s (hd0) ${root}
chainloader +1
}
### END /etc/grub.d/30_os-prober ###

 
GREEN entries are added by update-grub boot fine.
PURPLE entry is the one which I added myself and does NOT boot. It complains about not being able to find \EFI\Microsoft\Boot\BCD with error# 0xc0000001. Why?
RED entry is added by update-grub and does NOT boot. Most probably it's because of Bug#1024383.
 
Now some additional information which can be helpful in finding reason behind error# 0xc000001:
 
Output of ls -l /dev/disk/by-uuid/

Also there is bootx64.efi.grb file (zero bytes) lying in ESP.

 
PURPLE entry is the one which I added myself and does NOT boot. It complains about not being able to find \EFI\Microsoft\Boot\BCD with error# 0xc0000001. Why?

 

The 0xc000001 error is very likely caused by the fact that not the right boot drive and partition number is passed to the loader.

Try this:

menuentry "Windows - (search root)" {
search --fs-uuid --no-floppy --set=root D692-2CA0
chainloader (${root})/efi/Microsoft/Boot/bkpbootmgfw.efi
}

menuentry "Windows - (hd0,gpt2)" {
set root='(hd0,gpt2)'
chainloader (hd0,gpt2)/efi/Microsoft/Boot/bkpbootmgfw.efi
}

 

The 0xc000001 error is very likely caused by the fact that not the right boot drive and partition number is passed to the loader.

I understand, that's why GREEN entries work. But my ESP is (hd0,gpt2) partition. That's why I surprise that why hard-coding the same doesn't work.

I understand, that's why GREEN entries work. But my ESP is (hd0,gpt2) partition. That's why I surprise that why hard-coding the same doesn't work.

You didn't set the root with:

set root='(hd0,gpt2)'

 

You didn't set the root with:

set root='(hd0,gpt2)'

I have set root in the entry

 

 

menuentry "Windows - (hd0,gpt2)" {
set root='(hd0,gpt2)'
chainloader (hd0,gpt2)/efi/Microsoft/Boot/bkpbootmgfw.efi
}

Although it often works, its user interface is intentionally very simple, and it therefore often does more than is necessary.

The main problem with this approach is that it's blind. Many EFI boot problems are not caused by buggy firmware that can't remember NVRAM settings. In such cases, adding three extra boot loader files to the ESP just adds clutter that makes it harder for a human to figure out what's going on.

PURPLE entry is the one which I added myself and does NOT boot. It complains about not being able to find \EFI\Microsoft\Boot\BCD with error# 0xc0000001. Why?

Already there are 16 such entries got added.

menuentry "Windows - (search root)" {
search --fs-uuid --no-floppy --set=root D692-2CA0
chainloader (${root})/efi/Microsoft/Boot/bootmgfw.efi
}

@ECHO OFF
Rem add UEFI grub2

bcdedit /set {bootmgr} path \EFI\Microsoft\Boot\bootmgfw.efi

for /f "tokens=2 delims={}" %%a in ('BCDedit.exe /copy {bootmgr} /d "Grub2"') do set guid={%%a}
BCDedit.exe /set %guid% path \EFI\ubuntu\grubx64.efi

BCDedit.exe /enum firmware

bcdedit /set {fwbootmgr} displayorder {guid1} {bootmgr} {guid2} {guid3}