How to add the "Windows Boot Loader" to the GRUB2 list?

@computersavvy, how might one ascertain whether they do? (One of those URIs is 404.) I ask because my brother’s GRUB2 contains it, but mine doesn’t.

Hey @rokejulianlockhart - This might not fully answer your question but my guess is that dead link probably pointed to something like what is now this Fedora doc on using Grub2:

Regarding how to check for multiple EFI partitions, you might be able to just get away with running something like:

sudo blkid

or

lsblk

And looking for mount points with EFI in their names or EFI mentioned in their labels. There’s probably a more concrete way of identifying them, but maybe this helps you.

2 Likes

You could try sudo fdisk -l | grep "EFI System"

I think fdisk uses the type code in the GPT partition table to determine the type it reports - so when it sees C12A7328-F81F-11D2-BA4B-00A0C93EC93B it tells you you have an “EFI System” partition, which is also how the UEFI firmware should identify them.

1 Like

You also can run lsblk -f which will show something like this.

NAME                  FSTYPE            FSVER    LABEL      UUID                                   FSAVAIL FSUSE% MOUNTPOINTS

├─nvme0n1p1           vfat              FAT16               52B5-5EC4                               315.5M     6% /boot/efi

The FSTYPE vfat and FSVER of fat16 with the UUID as XXXX-XXXX should imply it is an ESP.

I don’t think that is correct. The UUID should be unique (both partition UUID and file system UUID), especially when there are multiple ESPs on a single system. Fdisk does clearly show the EFI System partition.

As I say, this is the type code of the partition, not the thing that we usually call “partition UUID”.

In the terminology of the GPT spec, I’m talking about the PartitionTypeGUID, not the UniquePartitionGUID.

That’s a reasonable heuristic, but not guaranteed. It’s unusual these days to use FAT16 partitions for purposes other than the ESP, but nothing in principle stops you having a FAT16 partition for regular file storage, in which case its GPT type code would be something other than C12A7328-F81F-11D2-BA4B-00A0C93EC93B and the UEFI firmware wouldn’t treat it as an EFI system partition.

2 Likes

@pg-tips, via that method, I appear to solely have one.

Because you’re all obviously very knowledgeable about this (and the title), could someone point me to the official and/or most accurate documentation on how to restore the Windows Boot Loader entry to GRUB2’s TUI when solely one EFI partition exists?

I understand how to rebuild the EFI entry:

However, GRUB2 doesn’t appear to locate it, despite me having enabled OSProber:

GRUB_TIMEOUT="15" # Original: GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT="saved"
GRUB_DISABLE_SUBMENU="true"
GRUB_TERMINAL_OUTPUT="gfxterm" # Original: GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="" # Original: GRUB_CMDLINE_LINUX="rhgb quiet"
GRUB_DISABLE_RECOVERY="false" # Original: GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG="true"
GRUB_GFXMODE="2560x1440,auto"
GRUB_DISABLE_OS_PROBER="false"

Perhaps, the undermentioned is relevant?

RokeJulianLockhart@Beedell:~$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg
[sudo] password for RokeJulianLockhart: 
Generating grub configuration file ...
error: ../grub-core/disk/diskfilter.c:530:invalid volume.
error: ../grub-core/disk/diskfilter.c:530:invalid volume.
error: ../grub-core/disk/diskfilter.c:530:invalid volume.
error: ../grub-core/disk/diskfilter.c:530:invalid volume.
error: ../grub-core/disk/diskfilter.c:530:invalid volume.
error: ../grub-core/disk/diskfilter.c:530:invalid volume.
Adding boot menu entry for UEFI Firmware Settings ...
done

If this is a little too off-topic, I’ll ask to have it split.

@rokejulianlockhart - Is this the section you need?

Adding other operating systems to the GRUB2 menu

In my experience, it automagically picks up Windows partitions and adds them as an entry. Just make sure you have os-prober available (which I think is default on Workstation).

My bad, I see you tried that already.

So you already have windows installed?
What is the result of running `sudo ls -R /boot/efi ?
If that shows /boot/efi/EFI/Microsoft then windows “should” be found by grub and bootable.

If not then you may need to do a windows recovery process which should install the necessary efi parts for windows.

The drawback is that doing so probably will wipe out the fedora efi pieces so it likely will be necessary to

  1. backup your fedora efi data (/boot/efi/EFI/)
  2. perform the windows recovery
  3. restore the fedora efi data
  4. boot to a live media then with chroot restore grub booting.

It may be possible to use efibootmgr for part of that.

1 Like

@computersavvy, it might: I don’t see either of those terms verbatim, but I’d say that “System Volume Information” would indicate Windows:

/boot/efi:
 EFI   mach_kernel   System  'System Volume Information'

/boot/efi/EFI:
BOOT  fedora

/boot/efi/EFI/BOOT:
BOOTIA32.EFI  BOOTX64.EFI  fbia32.efi  fbx64.efi

/boot/efi/EFI/fedora:
BOOTIA32.CSV  BOOTX64.CSV  gcdia32.efi  gcdx64.efi  grub.cfg  grubia32.efi  grubx64.efi  mmia32.efi  mmx64.efi  shim.efi  shimia32.efi  shimx64.efi

/boot/efi/System:
Library

/boot/efi/System/Library:
CoreServices

/boot/efi/System/Library/CoreServices:
SystemVersion.plist

'/boot/efi/System Volume Information':
/boot/efi/
├── EFI
│   ├── BOOT
│   │   ├── BOOTIA32.EFI
│   │   ├── BOOTX64.EFI
│   │   ├── fbia32.efi
│   │   └── fbx64.efi
│   └── fedora
│       ├── BOOTIA32.CSV
│       ├── BOOTX64.CSV
│       ├── gcdia32.efi
│       ├── gcdx64.efi
│       ├── grub.cfg
│       ├── grubia32.efi
│       ├── grubx64.efi
│       ├── mmia32.efi
│       ├── mmx64.efi
│       ├── shim.efi
│       ├── shimia32.efi
│       └── shimx64.efi
├── mach_kernel
├── System
│   └── Library
│       └── CoreServices
│           └── SystemVersion.plist
└── System Volume Information

8 directories, 18 files

I believe that what you refer to is what I’ve aforecited. No relevant component, accessible from cmd, should be lower-level than it.

When /boot/efi/EFI/Microsoft is missing it means you MUST perform the recovery procedure for windows. I believe that will require a windows boot/install media.

Yes, the System Volume Information seems to mean that windows was there at some point.

My laptop shows this

$ sudo ls -R /boot/efi
/boot/efi:
 EFI   mach_kernel   System  'System Volume Information'

/boot/efi/EFI:
Boot  fedora  Microsoft

/boot/efi/EFI/Boot:
BOOTIA32.EFI  bootx64.efi  fbia32.efi  fbx64.efi

/boot/efi/EFI/fedora:
BOOTIA32.CSV  gcdia32.efi  grub.cfg	     grubenv.rpmsave  grubx64.efi  mmx64.efi  shimia32.efi
BOOTX64.CSV   gcdx64.efi   grub.cfg.rpmsave  grubia32.efi     mmia32.efi   shim.efi   shimx64.efi

/boot/efi/EFI/Microsoft:
Boot  Recovery

/boot/efi/EFI/Microsoft/Boot:
BCD	      BOOTSTAT.DAT  en-US  fr-FR	   kd_02_1137.dll  kd_07_1415.dll	memtest.efi  Resources		     sv-SE
BCD.LOG       boot.stl	    es-ES  hr-HR	   kd_02_14e4.dll  kd_0C_8086.dll	nb-NO	     ro-RO		     tr-TR
BCD.LOG1      cs-CZ	    es-MX  hu-HU	   kd_02_15b3.dll  kdnet_uart16550.dll	nl-NL	     ru-RU		     uk-UA
BCD.LOG2      da-DK	    et-EE  it-IT	   kd_02_1969.dll  kdstub.dll		pl-PL	     SecureBootRecovery.efi  winsipolicy.p7b
bg-BG	      de-DE	    fi-FI  ja-JP	   kd_02_19a2.dll  ko-KR		pt-BR	     sk-SK		     zh-CN
bootmgfw.efi  el-GR	    Fonts  kd_02_10df.dll  kd_02_1af4.dll  lt-LT		pt-PT	     sl-SI		     zh-TW
bootmgr.efi   en-GB	    fr-CA  kd_02_10ec.dll  kd_02_8086.dll  lv-LV		qps-ploc     sr-Latn-RS

/boot/efi/EFI/Microsoft/Boot/bg-BG:
bootmgfw.efi.mui  bootmgr.efi.mui

/boot/efi/EFI/Microsoft/Boot/cs-CZ:
bootmgfw.efi.mui  bootmgr.efi.mui  memtest.efi.mui

/boot/efi/EFI/Microsoft/Boot/da-DK:
bootmgfw.efi.mui  bootmgr.efi.mui  memtest.efi.mui

/boot/efi/EFI/Microsoft/Boot/de-DE:
bootmgfw.efi.mui  bootmgr.efi.mui  memtest.efi.mui

/boot/efi/EFI/Microsoft/Boot/el-GR:
bootmgfw.efi.mui  bootmgr.efi.mui  memtest.efi.mui

/boot/efi/EFI/Microsoft/Boot/en-GB:
bootmgfw.efi.mui  bootmgr.efi.mui

/boot/efi/EFI/Microsoft/Boot/en-US:
bootmgfw.efi.mui  bootmgr.efi.mui  memtest.efi.mui

/boot/efi/EFI/Microsoft/Boot/es-ES:
bootmgfw.efi.mui  bootmgr.efi.mui  memtest.efi.mui

/boot/efi/EFI/Microsoft/Boot/es-MX:
bootmgfw.efi.mui  bootmgr.efi.mui

/boot/efi/EFI/Microsoft/Boot/et-EE:
bootmgfw.efi.mui  bootmgr.efi.mui

/boot/efi/EFI/Microsoft/Boot/fi-FI:
bootmgfw.efi.mui  bootmgr.efi.mui  memtest.efi.mui

/boot/efi/EFI/Microsoft/Boot/Fonts:
chs_boot.ttf  jpn_boot.ttf  malgun_boot.ttf   meiryo_boot.ttf	msjh_boot.ttf	msyh_boot.ttf	segmono_boot.ttf   segoe_slboot.ttf
cht_boot.ttf  kor_boot.ttf  malgunn_boot.ttf  meiryon_boot.ttf	msjhn_boot.ttf	msyhn_boot.ttf	segoen_slboot.ttf  wgl4_boot.ttf

/boot/efi/EFI/Microsoft/Boot/fr-CA:
bootmgfw.efi.mui  bootmgr.efi.mui

/boot/efi/EFI/Microsoft/Boot/fr-FR:
bootmgfw.efi.mui  bootmgr.efi.mui  memtest.efi.mui

/boot/efi/EFI/Microsoft/Boot/hr-HR:
bootmgfw.efi.mui  bootmgr.efi.mui

/boot/efi/EFI/Microsoft/Boot/hu-HU:
bootmgfw.efi.mui  bootmgr.efi.mui  memtest.efi.mui

/boot/efi/EFI/Microsoft/Boot/it-IT:
bootmgfw.efi.mui  bootmgr.efi.mui  memtest.efi.mui

/boot/efi/EFI/Microsoft/Boot/ja-JP:
bootmgfw.efi.mui  bootmgr.efi.mui  memtest.efi.mui

/boot/efi/EFI/Microsoft/Boot/ko-KR:
bootmgfw.efi.mui  bootmgr.efi.mui  memtest.efi.mui

/boot/efi/EFI/Microsoft/Boot/lt-LT:
bootmgfw.efi.mui  bootmgr.efi.mui

/boot/efi/EFI/Microsoft/Boot/lv-LV:
bootmgfw.efi.mui  bootmgr.efi.mui

/boot/efi/EFI/Microsoft/Boot/nb-NO:
bootmgfw.efi.mui  bootmgr.efi.mui  memtest.efi.mui

/boot/efi/EFI/Microsoft/Boot/nl-NL:
bootmgfw.efi.mui  bootmgr.efi.mui  memtest.efi.mui

/boot/efi/EFI/Microsoft/Boot/pl-PL:
bootmgfw.efi.mui  bootmgr.efi.mui  memtest.efi.mui

/boot/efi/EFI/Microsoft/Boot/pt-BR:
bootmgfw.efi.mui  bootmgr.efi.mui  memtest.efi.mui

/boot/efi/EFI/Microsoft/Boot/pt-PT:
bootmgfw.efi.mui  bootmgr.efi.mui  memtest.efi.mui

/boot/efi/EFI/Microsoft/Boot/qps-ploc:
memtest.efi.mui

/boot/efi/EFI/Microsoft/Boot/Resources:
bootres.dll  en-US  es-ES  fr-FR

/boot/efi/EFI/Microsoft/Boot/Resources/en-US:
bootres.dll.mui

/boot/efi/EFI/Microsoft/Boot/Resources/es-ES:
bootres.dll.mui

/boot/efi/EFI/Microsoft/Boot/Resources/fr-FR:
bootres.dll.mui

/boot/efi/EFI/Microsoft/Boot/ro-RO:
bootmgfw.efi.mui  bootmgr.efi.mui

/boot/efi/EFI/Microsoft/Boot/ru-RU:
bootmgfw.efi.mui  bootmgr.efi.mui  memtest.efi.mui

/boot/efi/EFI/Microsoft/Boot/sk-SK:
bootmgfw.efi.mui  bootmgr.efi.mui

/boot/efi/EFI/Microsoft/Boot/sl-SI:
bootmgfw.efi.mui  bootmgr.efi.mui

/boot/efi/EFI/Microsoft/Boot/sr-Latn-RS:
bootmgfw.efi.mui  bootmgr.efi.mui

/boot/efi/EFI/Microsoft/Boot/sv-SE:
bootmgfw.efi.mui  bootmgr.efi.mui  memtest.efi.mui

/boot/efi/EFI/Microsoft/Boot/tr-TR:
bootmgfw.efi.mui  bootmgr.efi.mui  memtest.efi.mui

/boot/efi/EFI/Microsoft/Boot/uk-UA:
bootmgfw.efi.mui  bootmgr.efi.mui

/boot/efi/EFI/Microsoft/Boot/zh-CN:
bootmgfw.efi.mui  bootmgr.efi.mui  memtest.efi.mui

/boot/efi/EFI/Microsoft/Boot/zh-TW:
bootmgfw.efi.mui  bootmgr.efi.mui  memtest.efi.mui

/boot/efi/EFI/Microsoft/Recovery:
BCD  BCD.LOG  BCD.LOG1	BCD.LOG2

/boot/efi/System:
Library

/boot/efi/System/Library:
CoreServices

/boot/efi/System/Library/CoreServices:
SystemVersion.plist

'/boot/efi/System Volume Information':
AadRecoveryPasswordDelete  ClientRecoveryPasswordRotation

'/boot/efi/System Volume Information/AadRecoveryPasswordDelete':

'/boot/efi/System Volume Information/ClientRecoveryPasswordRotation':

This is the key part that shows windows is installed, and you are missing Microsoft from that

/boot/efi/EFI:
Boot  fedora  Microsoft

@computersavvy, I do not see why I need to re-invoke bcdedit bcdboot, if that’s what you mean – the EFI entrant exists in the firmware’s GUI bootloader, so it must exist. I have Windows installed, and accessible. Merely not from GRUB2.

I’m sorry, I understood that windows would not boot.

Do you have another ESP beyond the one that fedora uses?

1 Like

To find which partition a given boot entry is loading from:

Run efibootmgr

Boot0001* Fedora        HD(1,GPT,4c4142d9-4e81-476a-93b5-dbdad8bb5f5a,0x800,0x400000)/\EFI\FEDORA\SHIMX64.EFI
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Notice the partition UUID which is 4c4142d9-4e81-476a-93b5-dbdad8bb5f5a. Find the disk partition for this
by running lsblk -p -o +PARTUUID |grep 4c4142d9-4e81-476a-93b5-dbdad8bb5f5a
which gives

├─/dev/nvme0n1p1 259:1    0     2G  0 part /boot/efi                               4c4142d9-4e81-476a-93b5-dbdad8bb5f5a

So this entry is booting from /dev/nvme0n1p1.

You can then mount this partition if it not already mounted and examine its contents.

Running bcdedit won’t help if the Windows boot loader isn’t found in the ESP
unless bcdedit can also populate the ESP with the Windows boot loader files.

1 Like

@computersavvy, not that I know of. I was under the assumption that what we did previously was to determine that. Some documentation online demonstrates that GRUB2 and the Windows Bootloader can share an ESP, but IDK whether Anaconda or Windows’s installer do so: [1]


@vekruse, I meant bcdboot. Apologies. Was late at night.

That process indeed returns a storage device, which is no surprise:

RokeJulianLockhart@Beedell:~$ efibootmgr
BootCurrent: 0002
Timeout: 1 seconds
BootOrder: 0002,0001
Boot0001* Windows Boot Manager  HD(3,GPT,dc82be70-547f-4de3-916a-1dddd961cd43,0x1d025800,0x19f000)/\EFI\Microsoft\Boot\bootmgfw.efi57494e444f5753000100000088000000780000004200430044004f0042004a004500430054003d007b00390064006500610038003600320063002d0035006300640064002d0034006500370030002d0061006300630031002d006600330032006200330034003400640034003700390035007d00000000000100000010000000040000007fff0400
Boot0002* Fedora        HD(1,GPT,cead81bf-5334-49fa-94eb-7878bdb2b032,0x800,0x12c000)/\EFI\fedora\shimx64.efi0000424f
RokeJulianLockhart@Beedell:~$ lsblk -p -o +PARTUUID |grep dc82be70-547f-4de3-916a-1dddd961cd43
└─/dev/nvme3n1p3 259:10   0   830M  0 part                                         dc82be70-547f-4de3-916a-1dddd961cd43

However, I knew which storage device Windows was installed on. Should I be searching for something specific? Otherwise, I don’t see much how this helps to get this into GRUB.


  1. unix.stackexchange.com/revisions/49269/2 ↩︎

Interesting. What does fdisk -l say the type of /dev/nvme3n1p3 is ?

Anaconda does this if you select an existing EFI partition for /boot/efi and don’t reformat the partition.

1 Like

@pg-tips, very, very weirdly, my disk label type is “DOS” (presumably, for MBR): [1]

  1. sudo fdisk -l /dev/nvme3n1p3
    
  2. Disk /dev/nvme3n1p3: 830 MiB, 870318080 bytes, 1699840 sectors
    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: dos
    Disk identifier: 0x73736572
    
    Device           Boot      Start        End    Sectors   Size Id Type
    /dev/nvme3n1p3p1      1920221984 3736432267 1816210284   866G 72 unknown
    /dev/nvme3n1p3p2      1936028192 3889681299 1953653108 931.6G 6c unknown
    /dev/nvme3n1p3p3               0          0          0     0B  0 Empty
    /dev/nvme3n1p3p4        27722122   27722568        447 223.5K  0 Empty
    
    Partition table entries are not in disk order.
    

I haven’t done anything weird, like enable CSM. fdisk must be incorrect.

Ah. I don’t think I did that. I’ve always selected “I would like to make additional space available”, then “Delete all”. What should I retain, instead?


  1. unix.stackexchange.com/revisions/205739/2 ↩︎

What I do (not necessarily the only way): choose “Manual Partitioning”, and select the existing EFI partition as the thing that will be mounted as /boot/efi, then make sure it’s not set to be reformatted.

This is using the Everything ISO, so with the old-style Anaconda installer. I guess it’s visually a bit different on the browser-based installer for F42 Workstation.

The fact that you’ve got “sub-partitions” inside /dev/nvme3n1p3 makes me wonder if it’s an extended partition on an MBR disk, with multiple logical partitions inside. It is possible to have a UEFI partition on an MBR disk but it’s a pretty edge-case legacy thing and I’m not sure how you’d end up with this on Windows 11, especially without CSM enabled.

I don’t know for sure, but it wouldn’t surprise me if os-prober just doesn’t support this case.

1 Like

btw, if you mount /dev/nvme3n1p3p1 and examine the contents, do you see an EFI/Microsoft directory with contents like @computersavvy’s in How to add Windows 11 to GRUB? - #8 ?

1 Like

You should mount /dev/nvme3n1p3 and examine its contents.

1 Like

@ph-tips, I’ve tried sudo mkdir /mnt/nvme3n1p3 && sudo mount -o ro /dev/nvme3n1p3p1 /mnt/nvme3n1p3, [1] but it returns:

mount: /mnt/nvme3n1p3: fsconfig system call failed: /dev/nvme3n1p3p1: Can't lookup blockdev.
       dmesg(1) may have more information after failed mount system call.

I believe that this means I need to specify -t, [1:1] but IDK what FS an ESP is.

Tangential

  1. @pg-tips, if I can confirm it is, I’ll file github.com/MaddieM4/os-prober/issues/new.

  2. BTW, /boot/loader/entries [2] just had Linux kernels in it (to confirm).


  1. github.com/files-community/Files/issues/17251#issue-3203800786 ↩︎ ↩︎

  2. ↩︎