Why is there a 'Windows Boot Manager" entry in the GRUB menu?

English Install/Boot/Login
1

Direct after deiivery of a system, I installed openSUSE Leap 15.3 using Custom Partitioning. The only partition that was not touched is the EFI one, I removed all others an created the needed ones for openSUSE.

beneden:/boot/grub2 # fdisk -l
Disk /dev/nvme0n1: 476.94 GiB, 512110190592 bytes, 1000215216 sectors
Disk model: SK hynix BC711 HFM512GD3JX013N          
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 6F88824E-A52B-45B3-8830-DEAE7B982AE0

Device             Start       End   Sectors  Size Type
/dev/nvme0n1p1      2048    534527    532480  260M EFI System
/dev/nvme0n1p2    534528  34088959  33554432   16G Linux swap
/dev/nvme0n1p3  34088960  80226303  46137344   22G Linux filesystem
/dev/nvme0n1p4  80226304 583542783 503316480  240G Linux filesystem
/dev/nvme0n1p5 583542784 730343423 146800640   70G Linux filesystem
beneden:/boot/grub2 # 

beneden:/boot/grub2 # lsblk -f
NAME        FSTYPE FSVER LABEL  UUID                                 FSAVAIL FSUSE% MOUNTPOINT
nvme0n1                                                                             
├─nvme0n1p1 vfat   FAT32 SYSTEM 24BE-8D20                             186.4M    27% /boot/efi
├─nvme0n1p2 swap   1            93214ac3-dde1-4a5f-9669-b64525558210                [SWAP]
├─nvme0n1p3 ext4   1.0          088ce6ce-7745-40e7-ba1b-1bb63b50c2dd   13.9G    30% /
├─nvme0n1p4 ext4   1.0          23b55c5c-6d95-44f2-9cd3-505e1700534c  166.2G    24% /home
└─nvme0n1p5 ext4   1.0          dd927211-3773-4f73-8419-c5417db9d78c                
beneden:/boot/grub2 #

Besides the “normal” entries, the Grub menu shows me one for Windows Boot manager.

beneden:/boot/grub2 # grep '^menuentry' grub.cfg 
menuentry 'openSUSE Leap 15.3'  --class opensuse --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-088ce6ce-7745-40e7-ba1b-1bb63b50c2dd' {
menuentry 'Windows Boot Manager (on /dev/nvme0n1p1)' --class windows --class os $menuentry_id_option 'osprober-efi-24BE-8D20' {
beneden:/boot/grub2 #

The complete grub.cfg listing is at https://paste.opensuse.org/2570165

I did not dare to try it (maybe I am to afraid of anything MS).
Is this due to

beneden:/boot/grub2 # efibootmgr
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0000,0002,0005,0001,0003,0004
Boot0000* opensuse-secureboot
Boot0001* UEFI:CD/DVD Drive
Boot0002* Windows Boot Manager
Boot0003* UEFI:Removable Device
Boot0004* UEFI:Network Device
Boot0005* opensuse
beneden:/boot/grub2 #

Questions:

  1. Is the entry indeed because Grub finds it in the EFI partition?
  2. Why is it in the EFI partition? No windows anywhere.
  3. Can I remove this by using efibootmgr and will grub pickup this?
2

Hi
Remove and see what happens… it may get auto re-added by the BIOS, check probe foreign os is unchecked in YaST2 bootloader. Could also auto add (BIOS?) based on /boot/efi/EFI/boot entry…

3

You mean with

efibootmgr -B 0002

?

There is not boot there, but:

beneden:/boot/efi/EFI # l
total 24
drwxr-xr-x 6 root root 4096 Jul  6 17:36 ./
drwxr-xr-x 4 root root 4096 Jan  1  1970 ../
drwxr-xr-x 2 root root 4096 Feb 21 04:25 Boot/
drwxr-xr-x 5 root root 4096 Feb 21 04:54 HP/
drwxr-xr-x 4 root root 4096 Feb 21 04:25 Microsoft/
drwxr-xr-x 2 root root 4096 Jul  6 17:36 opensuse/
beneden:/boot/efi/EFI # l *
Boot:
total 1984
drwxr-xr-x 2 root root    4096 Feb 21 04:25 ./
drwxr-xr-x 6 root root    4096 Jul  6 17:36 ../
-rwxr-xr-x 1 root root 2019656 Jun  5  2021 bootx64.efi*

HP:
total 24
drwxr-xr-x 5 root root 4096 Feb 21 04:54 ./
drwxr-xr-x 6 root root 4096 Jul  6 17:36 ../
drwxr-xr-x 5 root root 4096 Feb 21 04:54 BIOS/
drwxr-xr-x 2 root root 4096 Feb 21 04:54 BIOSUpdate/
-rwxr-xr-x 1 root root  425 Feb 21 04:54 DI.efi*
drwxr-xr-x 2 root root 4096 Feb 21 04:54 SystemDiags/

Microsoft:
total 20
drwxr-xr-x  4 root root 4096 Feb 21 04:25 ./
drwxr-xr-x  6 root root 4096 Jul  6 17:36 ../
drwxr-xr-x 41 root root 8192 Feb 21 04:25 Boot/
drwxr-xr-x  2 root root 4096 Feb 21 04:25 Recovery/

opensuse:
total 3096
drwxr-xr-x 2 root root    4096 Jul  6 17:36 ./
drwxr-xr-x 6 root root    4096 Jul  6 17:36 ../
-rwxr-xr-x 1 root root  846240 Jul  6 16:36 MokManager.efi*
-rwxr-xr-x 1 root root      58 Jul  6 16:36 boot.csv*
-rwxr-xr-x 1 root root     125 Jul  6 16:36 grub.cfg*
-rwxr-xr-x 1 root root 1222656 Jul  6 16:36 grub.efi*
-rwxr-xr-x 1 root root  143360 Jul  6 16:36 grubx64.efi*
-rwxr-xr-x 1 root root  934680 Jul  6 16:36 shim.efi*
beneden:/boot/efi/EFI #
4

Hi
Yes, remove via;


efibootmgr -b 0002 -B 0002

That’s a fallback AFAIK for UEFI systems that insist on a /boot directory… You can always move the file out, and see what happens…

5

Host erlangen had multiple boots which had been created once or again and again for unknown reasons. I stopped this behaviour by creating a pristine ESP and deleting all boots. grub2-install created consistent new ones:

**erlangen:~ #** efibootmgr -v           
BootCurrent: 0000 
Timeout: 1 seconds 
Boot0000* tumbleweed-nvme0n1p2  HD(1,GPT,3a18dd5f-a978-45d0-b579-3c64b6927861,0x800,0x100000)/File(\EFI	umbleweed-nvme0n1p2\grubx64.efi) 
Boot0001* tumbleweed-test       HD(1,GPT,3a18dd5f-a978-45d0-b579-3c64b6927861,0x800,0x100000)/File(\EFI	umbleweed-test\grubx64.efi) 
**erlangen:~ #** find /boot/efi/ -type f 
/boot/efi/EFI/tumbleweed-test/grubx64.efi 
/boot/efi/EFI/tumbleweed-nvme0n1p2/grubx64.efi 
**erlangen:~ #** efivar -l|grep Boot     
8be4df61-93ca-11d2-aa0d-00e098032b8c-**Boot**Current 
8be4df61-93ca-11d2-aa0d-00e098032b8c-**Boot**OptionSupport 
8be4df61-93ca-11d2-aa0d-00e098032b8c-Secure**Boot**
7b59104a-c00d-4158-87ff-f04d6396a915-Secure**Boot**Setup 
8be4df61-93ca-11d2-aa0d-00e098032b8c-**Boot**0001 
8be4df61-93ca-11d2-aa0d-00e098032b8c-**Boot**0000 
de8ab926-efda-4c23-bbc4-98fd29aa0069-Fixed**Boot**
45cf35f6-0d6e-4d04-856a-0370a5b16f53-Default**Boot**Order 
**erlangen:~ #**

**erlangen:~ #** fdisk -l /dev/nvme0n1 
**Disk /dev/nvme0n1: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors**
Disk model: Samsung SSD 970 EVO Plus 2TB             
Units: sectors of 1 * 512 = 512 bytes 
Sector size (logical/physical): 512 bytes / 512 bytes 
I/O size (minimum/optimal): 512 bytes / 512 bytes 
Disklabel type: gpt 
Disk identifier: F5B232D0-7A67-461D-8E7D-B86A5B4C6C10 

**Device        ****     Start****       End****   Sectors**** Size****Type**
/dev/nvme0n1p1       2048    1050623    1048576  512M EFI System 
/dev/nvme0n1p2    1050624 3702228991 3701178368  1.7T Linux filesystem 
/dev/nvme0n1p3 3804628992 3907029134  102400143 48.8G Linux filesystem 
/dev/nvme0n1p4 3702228992 3804628991  102400000 48.8G Linux filesystem 

Partition table entries are not in disk order. 
**erlangen:~ #**
6

Yes, it is because “grub2-mkconfig” finds it in the EFI partition.

It was presumably put in the EFI partition, perhaps by the hardware vendor, as part of an earlier Windows install.

No, removing the entry with “efibootmgr” probably won’t help. It is the UEFI boot file in the EFI partition. Simplest would be:

rm -rf /boot/efi/EFI/Microsoft

and then the entry should disappear when you next run “grub2-mlconfig”.

7

Did as you suggested. The Mircrosoft directory is gone. I run grub2-mkconfig (mind your typo :wink: ), but forgot to check.

Shutdown Reboot: the entry is still there. I tried to use it. Grub now complains that the Microsoft directory is not there and after a few seconds falls back to the main menu. I then used the first boot item: 15.3.

Yes, Microsoft is gone:

beneden:/boot/efi/EFI # l
total 20
drwxr-xr-x 5 root root 4096 Jul 13 16:59 ./
drwxr-xr-x 4 root root 4096 Jan  1  1970 ../
drwxr-xr-x 2 root root 4096 Feb 21 04:25 Boot/
drwxr-xr-x 5 root root 4096 Feb 21 04:54 HP/
drwxr-xr-x 2 root root 4096 Jul  6 17:36 opensuse/
beneden:/boot/efi/EFI #

But I still have:

beneden:/boot/grub2 # grep '^menuentry' grub.cfg
menuentry 'openSUSE Leap 15.3'  --class opensuse --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-088ce6ce-7745-40e7-ba1b-1bb63b50c2dd' {
menuentry 'Windows Boot Manager (on /dev/nvme0n1p1)' --class windows --class os $menuentry_id_option 'osprober-efi-24BE-8D20' {
beneden:/boot/grub2 #

beneden:/boot/grub2 # efibootmgr
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0000,0002,0005,0001,0003,0004
Boot0000* opensuse-secureboot
Boot0001* UEFI:CD/DVD Drive
Boot0002* Windows Boot Manager
Boot0003* UEFI:Removable Device
Boot0004* UEFI:Network Device
Boot0005* opensuse
beneden:/boot/grub2 #
8

Hm, it looks as if grub2-mkconfig did not replace grub-cfg:

beneden:/boot/grub2 # l
total 48
drwxr-xr-x 6 root root  4096 Jul 13 14:08 ./
drwxr-xr-x 4 root root  4096 Jul  6 16:22 ../
drwxr-xr-x 2 root root  4096 Jul  6 15:36 fonts/
-rw------- 1 root root  8935 Jul  6 16:36 grub.cfg
-rw-r--r-- 1 root root  1024 Jul  6 16:36 grubenv
drwxr-xr-x 2 root root  4096 Jul  6 16:36 locale/
drwxr-xr-x 3 root root  4096 Jul  6 15:34 themes/
drwxr-xr-x 2 root root 12288 Jul  6 16:36 x86_64-efi/
beneden:/boot/grub2 #

Time stamp is still that of the installation.

9

OK, it seems that you have to redirect the output of grub-mkconfig. Did that and will ask my wife if I may again run down her system :wink:

10

You need:


grub2-mkconfig -o /boot/grub2/grub.cfg
11

Hurray, success.

Thanks a lot and sorry for the misunderstanding on how grub2-mkconfig works.

It is of course only a cosmetic issue, but I really do not like to see the word Microsoft every time I boot on a system where it is erased. lol!

Thanks to all who contributed. I learned something more about EFI booting and GRUB (it triggered me to read a few Wikipedia articles about the subjects)

12

Yes, that is probably the best thing to do. As I did all config text appeared at the terminal, I did a shell redirect (and thus only a few to stderr messages remained). I then move the old cfg to a save place and move the new one in place. As said above: success.

13

No, it is not. It is normal entry that is created during Windows installation (and may be update).

No, it is not (as your own example quite clearly demonstrates). The best thing on openSUSE is to use update-bootloader which automatically does the right thing for the currently configured bootloader (and will continue to do the right thing when grub2 will be replaced by something else, assuming openSUSE still exists at this point). Running low level bootloader utilities manually (without fully understanding bootloader setup and what these utilities do) often creates subtle problems that are rather hard to troubleshoot in retrospect.

14

Hi
As with linux there are so many ways to deal with issues… more will come in the future…

15

The we do not need these forums at all. LinuxQuestions is sufficient.